用于修补程序的 git 合并分支

Question

We have 3 branches (master, acpt, devl) and corresponding environments: production, acpt and devl. Our team has multiple developers. Trying to figure out how best development model to use to address the following scenario

devl has the following commits: A,B,C
acpt has: A
master has: A

I have a hotfix commit that needs to be pushed to master. I have created a new branch called hotfix using master, made the changes with commit D.

Should I merge the hotfix branch to master, acpt and devl? I guess the merge into acpt and master will work fine. But since devl has already moved ahead to C, will devl have A,D,B,C or A,B,C,D ? Trying to figure out the best practice.

Answer 1

Note: Raymond Chen's"stop cherry-picking, start merging" describes this better than I can in the space I have here.

I believe the "right" work-flow for this is to merge fixes that are made at the point the bug is introduced .

You have described three groups that have access to a common repository as having access to a total of three commits. That's not a very realistic scenario: a typical Git repository will by this point have hundreds or thousands of commits. It does suffice to draw the problem, but I think it's better to draw, say, six or more commits. I've drawn eight below to start with.

(I also won't use your branch names; in fact, I'll just use one, to start with.)

Let's draw what we might have:

                   I--J--K   <-- develop
                  /
...--D--E--F--G--H   <-- tag:v1.0

The tag v1.0 is the particular commit that has been released as version 1.0. Meanwhile, developers continued developing and have made three new commits.

A customer now calls support and says that some particular command or feature has some particular bug. This bug is now logged as bug #1234. The support and/or developer folks analyze the bug and find that the bug was introduced in commit F . Here is what they should do:

                  I--J--K   <-- develop
                 /
             G--H   <-- tag:v1.0
            /
...--D--E--F   <-- fixes/bug-1234

That is, we now have a new branch name in the fixes/ name-space, with the bug ID in it. We now come up with a fix for the bug and commit it, making a new commit with its new and unique hash ID. Meanwhile the development group has already added a new commit L :

                  I--J--K--L   <-- develop
                 /
             G--H   <-- tag:v1.0
            /
...--D--E--F--F1   <-- fixes/bug-1234

We test the fix, perhaps by merging it into commit H under a new release candidate branch ( rc/1.1 ), and giving the resulting merge commit to the testing group:

                    I--J--K--L   <-- develop
                   /
               G--H   <-- tag:v1.0
              /    \
             /   _--M   <-- rc/1.1
            /   /
...--D--E--F--F1   <-- fixes/bug-1234

If all goes well, release candidate 1.1 becomes the release tagged 1.1 (perhaps after also adding more fixes but these are not drawn here):

                 I--J--K--L   <-- develop
                /
               G--H   <-- tag:v1.0
              /    \
             /   _--M   <-- rc/1.1, tag:v1.1
            /   /
...--D--E--F--F1   <-- fixes/bug-1234

(At this point the release candidate branch name can be deleted—it's no longer doing any good. It was just there to test M and maybe other merges as well.)

It is now time to merge commit F1 , the fix for the bug, into the mainline development as well. This is hard to draw! Here is an attempt:

                 I--J--K--L------__
                /                  \
               G--H   <-- tag:v1.0  \
              /    \                 \
             /   _--M   <-- tag:v1.1  \
            /   /_____-----------------N   <-- develop
...--D--E--F--F1   <-- fixes/bug-1234

If a bug is discovered in commit D or E or G , we can label that commit with fixes/bug-1235 , fix it, and merge the fix into a release candidate and/or the develop branch as well. The drawing will get very messy, but Git will do the best possible job of merging, automatically, in each case.

It is also relatively easy to automatically identify which tags and/or branches have a fix merged into them. Commit F1 is now in the ancestry of develop , so it is merged there. It is in the ancestry tag v1.1 , and not in the ancestry of tag v1.0 , so customers with v1.0 who have bug #1234 should upgrade to v1.1.