git 如何避免 GitHub/BitBucket 上的合并提交地狱
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/16358418/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
How to avoid merge-commit hell on GitHub/BitBucket
提问by Niklas9
We're ending up with a lot of commits like this in our repo:
我们最终在我们的 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?
我知道如果仅在我的本地 VM 中完成，我可以执行 git rebase，GitHub/BitBucket UI 中是否有任何等效项？
How do you guys do it?
你们是怎么做的？
回答by Todd A. Jacobs
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 -iflag, 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 也有很多标志，包括带有-i标志的交互式变基，但如果您尽可能保持简单并希望在合并时保留所有分支历史记录，则可能不需要这些。
Use the --ff-onlyFlag
使用--ff-only旗帜
Aside from rebasing, the use of the --ff-onlyflag 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标志将确保只允许快进提交。如果改为合并提交，则不会进行提交。git-merge(1) 手册页说：
--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.
--ff-only
拒绝合并并以非零状态退出，除非当前 HEAD 已经是最新的或者合并可以解决为快进。
回答by Kondal Kolipaka
"Todd A. Jacobs" already mentioned "rebase" is the concept here. This is just a more detailed way of doing things.
“Todd A. Jacobs”已经提到“rebase”是这里的概念。这只是一种更详细的做事方式。
Let's say you're on the master branch
假设你在 master 分支上
$ git branch
* master
You want to make a fix, so create a “fixbranch” which is branched from the master
你想要修复，所以创建一个从 master 分支的“fixbranch”
$ git checkout -b fixbranch
Maybe you would have worked for a couple of days on this branch and had a couple of commits.
也许你会在这个分支上工作几天并有几次提交。
The day you wanted to push your commits to central master repo! Checkout master and get the latest changes from the central master repo
您想将提交推送到中央主存储库的那一天！结帐 master 并从中央 master repo 获取最新更改
$ git checkout master
$ git pull origin master
Rebase your fixbranch with the master to have a clean history and resolve the conflicts if any in the local repo itself.
使用 master 重新定位您的 fixbranch 以拥有干净的历史记录并解决本地存储库本身中的冲突（如果有）。
$ git checkout fixbranch
$ git rebase master
Now fixbranch is uptodate to with the central master, let me merge fixbranch into the master branch
现在 fixbranch 已更新到中央主分支，让我将 fixbranch 合并到主分支
$ git checkout master
$ git merge fixbranch
I'm done! let me push local master to the central master
我受够了！让我把本地master推到中央master
$ git push origin master
