如何避免GitHub / BitBucket上的merge-commit地狱 [英] How to avoid merge-commit hell on GitHub/BitBucket
问题描述
合并分支的'主'bitbucket .org:user / repo
每当开发人员将他/她的本地叉子同步到顶端
有没有办法避免这个合并提交地狱混乱所有的回购日志?如果在我的本地虚拟机中完成这项工作,我知道我可以做git rebase,有没有任何等价的方法可以解决这个问题?
在GitHub / BitBucket用户界面?你们是如何做到的? 解决方案
>
合并前的Rebase Feature Branches
如果您想避免合并提交,您需要确保所有提交都是快进。你可以通过确保你的特性分支在合并之前干净地粘贴到你的开发线上来这样做:
git checkout master
git checkout -b功能/ foo
#进行一些提交
git rebase master
git checkout master
git merge --ff-只有feature / foo
Rebase也有很多标志,包括 -i
标志,但如果你想尽可能保持简单并希望保留所有的分支历史记录,你可能不需要这样做。
使用 - 仅ff-only
标记
-ff-only
标志将确保只允许快进提交。如果它是一个合并提交,则不会进行提交。 git-merge(1)手册页说:
- 仅ff
拒绝合并并以非零状态退出,除非当前的
HEAD已经是最新的,或者合并可以被解析为
快进。
We're ending up with a lot of commits like this in our repo:
Merge branch 'master' of bitbucket.org:user/repo
This happens every time a developer syncs his/hers local fork to the top-level repo.
Is there anyway to avoid this merge-commit hell from cluttering all the repo log? Can one avoid them when initiating the pull-requests in some way?
I know I can do git rebase if this is done in my local VM only, is there any equivalence in the GitHub/BitBucket UI?
How do you guys do it?
Rebase Feature Branches Before Merging
If you want to avoid merge commits, you need to ensure all commits are fast-forwards. You do this by making sure your feature branch rebases cleanly onto your line of development before a merge like so:
git checkout master
git checkout -b feature/foo
# make some commits
git rebase master
git checkout master
git merge --ff-only feature/foo
Rebase also has a lot of flags, including interactive rebasing with the -i
flag, but you may not need that if you're keeping things as simple as possible and want to preserve all of your branch history on a merge.
Use the --ff-only
Flag
Aside from rebasing, the use of the --ff-only
flag will ensure that only fast-forward commits are allowed. A commit will not be made if it would be a merge commit instead. The git-merge(1) manual page says:
--ff-only
Refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward.
这篇关于如何避免GitHub / BitBucket上的merge-commit地狱的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!