The -force-with-lease option is the safest, because it will abort if there are any upstream changes ( If someone else pushed changes to the same branch, you probably want to avoid destroying those changes. (You can use -m if you want to wipe out the old message and use a new one.) PushingĪnd then when you push, do this: git push -force-with-lease This brings up the editor with the last commit message and lets you edit the message. Locate the faultbranch line and edit accordingly.If it is the most recent commit, you can simply do this: git commit -amend Or, on a per project level with: git config -add faultbranch mastressĪlternatively you could go and manually change the gitconfig file which-in windows-is stored with the programm in the etc folder. You can override a setting on a global, user, level with: git config -global -add faultbranch mistress You can check the value of the system setting with: git config -system faultbranch Select this and you can skip the step to name the initial branch during repo init. and you'd specified something else, for example the preset main, this will be the system wide default. If you select the option Override the default. If left to the default Let Git decide it will be master. It is important to point out that the only reason git creates an initial branch called master is due to the config setting faultbranch set during installation of git-scm. The "into branch Y" part, which uses the current branch, still seems quite marginal to me, though.) (If your branch names include the bug-reference-number, then these messages are useful. If you manually replace this with "merge fix for critical customer bug #1234", you get a useful message. At worst, it may be worse than useless since it might send you looking at the wrong "hot bug". The information being conveyed here is nearly useless-you need the date of the merge, not just the message, to find the right "hot bug". Then your repository will have the occasional "merge branch hotfix" commit, but each of these messages is for a different hotfix. To take a particular example, suppose you reserve the name hotfix for a temporary branch on which hot-fixes are made. Note that these autogenerated messages convey relatively little useful information, especially if you delete the feature branch after merging it. The end result of all of this is that you tend to get messages of the form merge branch feature when merging features into master/ main, and messages of the form merge branch feature into develop when merging features into other branches. This was hardcoded as master in the past, but is becoming configurable. Where X is the argument you gave to git merge-with a URL added when using git pull to run git merge-and Y is present, and is the name of the current branch, if the current branch is not the designated "special" branch. But that's outside your own Git.)ġThe git merge command does, however, generate a default merge message: merge branch X Īnd git pull generates a default merge message: merge branch X of 'url' (Other people remember branch names, in their brains, and may have saved some branch names in clones, so it's best to do all these name changes before anyone else gets hold of these names.
#Git change branch message free
Commits do not remember which branch was the current branch when they were made, 1 so you're free to change branch names at any time. There is no functional difference between creating the initial commit, then renaming the branch, vs changing the unborn branch name, then making the initial commit. You mention in your own answer that git branch -m main (or the same with -M) only works once you have an initial commit.Īlternatively, before creating any commits, use git checkout -b main to switch the name of the unborn branch to main.
#Git change branch message upgrade
Update: The -m and -M options to git branch were upgrade in Git 2.30 to allow renaming the not-yet-existing current branch name in special situations, such as when you're in a new, empty repository.
0 kommentar(er)
