Git将修补程序分支合并到功能分支，然后删除修补程序分支？

Question

I'm very new to Git, but am very impressed by the lightweight branching/merging it provides.

I have three branches in my repository:

master
1.1.0
1.0.x

I have made a quick fix in the 1.0.x branch, but I'm wondering if I should immediately merge those changes back into 1.1.0 ? Or is it advised to wait until the 1.1.0 branch is ready to be released as a minor version to merge the hotfixes back in?

And also, in this image:

I'm pretending that iss53 = 1.0.x and master = 1.1.0 for this example. Once the changes from my 1.0.x hotfix branch have been merged back into the 1.1.0 feature branch, can I continue working on the 1.0.x branch?

If I commit a change WHILE working on the 1.0.x branch, after the above merge, will it just create a new horizontal link (to picture it visually) from a hypothetical C7 commit, with a single parent C5 , or will it have two parents, C5 and C6 ?

This section of the git-book ( Git - Basic Branching and Merging ) also mentions deleting the branch once it is finished, but they unfortunately don't show what the graph would look like afterwards. Surely the commits are still there - is the label simply removed? ( iss53 in the above example.) And once that branch is removed, if you find that Issue 53 wasn't completely fixed, can you continue work from C5 , creating another iss53 branch, or do you have to give it a different name, like iss53_2 ?

Answer 1

I'd merge it as soon as you are certain the change is good and needs to go into that branch. Merging earlier is more likely to succeed without manual effort :)

The tree will stay exactly the same if you delete the branch, only the label for the branch vanishes. If you have commits that are no longer reachable from any label then they may eventually be deleted by the garbage collection but it keeps them around for a few weeks, and that's not the case here as all your commits still are reachable in some branch.

You can easily make the branch again, just do "git checkout -b iss53 xxxxxx" where xxxxx is the commit hex code for the commit you want to base it on. git reflog is useful for helping to find the commit you need as it shows all the recent history.