Git:将分支合并为master,或者master转换为分支

Question

我想知道我是否犯了一个错误,首先将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"

现在我想合并.通常,我更喜欢先将master合并到x中,然后将x合并到master中:

            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 

实际上,我经常会遇到似乎完全合并回主人的存储库.我的方法有什么缺点吗？我不应该这样做的任何理由？

Answer 1

这是一个非常主观的问题,但我会给它一个通行证,因为我认为我可以提出一个相当客观的答案.

在合并之前将master重新合并到您的分支中是一种很好的做法.如果其他人犯下了破坏您刚刚实施的功能的内容(正如您所指出的),该怎么办？或者如果有人修改了您所做的相同代码,并导致可能的合并冲突怎么办？我实际上建议非常频繁地将主人合并到你的分支中.这不仅可以防止您花费一天半的时间来解决合并冲突(尽管这可能表明您的分支机构太大,但这是另一个故事),但它也会让您在项目更改时保持一致演变.

也许有人会说,你应该重订上主的顶部您的提交.我的简短版本是:我鼓励人们在开发过程的早期就开启拉取请求,即使没有完成某项功能.这意味着您可能会将代码推送到远程服务器(例如GitHub).为了重新提交你的提交,你必须推送重写的git历史记录,并强制推送.强制推送是一个糟糕的工作流决策,应该避免,因为它可能会导致(几乎)永久性损坏您的提交历史记录.

所以是的,在您查看合并之前从主服务器合并,并且尽可能经常.如果您使用GitHub,我甚至鼓励使用新的受保护分支功能在合并之前强制更新master分支: