问题描述
我们最终在我们的存储库中有很多这样的提交:
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.
有没有办法避免这种合并提交地狱弄乱所有 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?
我知道如果 git rebase 仅在本地 VM 中完成，我可以执行此操作，GitHub/BitBucket UI 中是否有任何等效项?
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?
你们是怎么做到的?
推荐答案
Rebase Feature Branchs Before Merging
如果你想避免合并提交，你需要确保所有提交都是快进的.您可以通过确保您的功能分支在合并之前干净地重新定位到您的开发线来做到这一点，如下所示:
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 也有很多标志，包括使用 -i 标志的交互式变基，但如果您尽可能地保持简单并希望保留所有合并时的分支历史记录.
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.
除了 rebase 之外，使用 --ff-only 标志将确保只允许快进提交.如果改为合并提交，则不会进行提交.git-merge(1) 手册页说:
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
拒绝合并并以非零状态退出，除非当前HEAD 已经是最新的，或者合并可以解决为快进.
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 上的合并提交地狱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！