我想知道我是不是犯了一个错误,先把master合并到另一个分支,然后再把它合并回master。
假设我创建了以下分支,每个分支都有一个单独的提交:

            mkdir git_merging
            cd git_merging/
            git init
            touch on_master
            git add .
            git commit -m "Initial commit on master"

            git checkout -b x
            touch on_branch_x
            git add .
            git commit -m "Initial commit on branch x"

            git checkout master
            touch on_master_again
            git add .
            git commit -m "Commit on master after branching"

现在我想合并。通常,我宁愿先将主控形状合并为X,然后再将X合并为主控形状:
            git checkout x
            git merge -m "Merge master into x" master
            echo "test results"
            git checkout master
            git merge x

这样我就可以在合并回master之前测试东西,确保我始终拥有一个正常工作的master分支。据我所知,与将x直接合并到master中相比,没有功能差异:
            git merge -m "Merge x into master" x
            git checkout x
            git merge master

在实践中,我经常遇到似乎完全合并回master的存储库。我的方法有什么缺点吗?有什么理由不让我这么做吗?

最佳答案

这是一个很主观的问题,但我会通过的,因为我认为我可以得出一个相当客观的答案。
在合并之前将master合并回分支是一个很好的实践。如果有人提交了一些破坏您刚刚实现的特性的内容(如您所指出的),会怎么样?或者,如果有人修改了与您相同的代码,并导致了可能的合并冲突,该怎么办?实际上,我建议您经常将master合并回您的分支。这不仅可以防止您花费一天半的时间来解决合并冲突(尽管这可能是您的分支太大的迹象,但这是另一个情况),而且还可以使您在项目更改和发展时保持一致。
有些人可能会说,你应该把你的承诺放在主人的最前面。我的简短版本是:我鼓励人们在开发过程的早期打开拉请求,即使一个特性没有完成。这意味着您可能会将代码推送到远程服务器(如GitHub)。为了重新平衡您的提交,您必须使用重写的git历史进行推送,并强制推送。强制推送是一个糟糕的工作流决策,应该避免,因为它可能会(几乎)永久性地损坏提交历史记录。
所以,是的,在您寻找合并之前从master合并回来,并且尽可能频繁地进行合并。如果您使用github,我甚至鼓励您在合并之前使用新的受保护分支功能来强制使用master更新分支:
git - Git:将分支 merge 为master,或者master转换为分支-LMLPHP

08-27 03:21
查看更多