我想知道是否先通过将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
在实践中,我经常遇到那些似乎完全合并回master的存储库。我的方法有什么缺点吗?我为什么不应该这样做?
这是一个相当主观的问题,但我会通过,因为我认为我可以提出一个相当客观的答案。
在合并之前,将master合并回您的分支是一个好习惯。如果其他人所做的某些事情破坏了您刚刚实现的功能(如您所指出的),该怎么办?或者,如果有人修改了您所做的相同代码,并导致可能的合并冲突,该怎么办?我实际上建议非常频繁地将master合并回您的分支。这不仅使您不必花一天半的时间解决合并冲突(尽管这可能表明您的分支机构太大,但这是另一回事了),而且还可以使您在项目更改时保持一致并进化。
也许有人会说,你应该重订上主的顶部您的提交。我的简短版本是:我鼓励人们在开发过程的早期就打开请求请求,即使没有完成某项功能。这意味着您可能会将代码推送到远程服务器(例如GitHub)。为了重新建立提交,您必须使用重写的git历史记录进行推送,然后强制推送。强制推送是一个糟糕的工作流程决策,应避免使用它,因为它可能会(几乎)永久损坏您的提交历史记录。
因此,是的,请在查找合并之前就从master合并回来,否则请尽可能多地合并。如果您使用GitHub,我什至鼓励在合并之前使用新的Protected Branches功能强制与master一起更新分支:
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句