为什么我将“远程分支”的起源/发展融入到“发展”？
我是我组织中唯一一个提交以下消息的人：
将远程追踪分支的“起源/开发”合并为开发
不知道我在做什么来造成他们，但我想停下来。
我发出了什么命令来创build这个提交，我应该使用什么命令来产生它？
谢谢，
〜Ĵ
git pull可能是创build提交。 如果你做了一个本地提交，然后在其他人将一个提交到存储库之后运行git pull ，那么Git会下载其他开发者的提交，然后将它合并到你的本地分支。
如何在将来避免这些合并提交
你可以使用git pull --rebase来防止这种情况在将来发生，但是rebasing有其危险， 我build议完全避免pull 。
相反，我鼓励你遵循这种使用模式：
# download the latest commits git remote update -p # update the local branch git merge --ff-only @{u} # if the above fails with a complaint that the local branch has # diverged: git rebase -p @{u}
说明
-
git remote update -p下载远程仓库中的所有提交，并更新远程跟踪分支（例如，origin/master）。 它不会触及你的工作目录，索引或本地分支。-p参数修剪已删除的上游分支。 因此，如果foo分支在origin存储库中被删除，git remote update -p会自动删除你的origin/fooref。 -
git merge --ff-only @{u}告诉Git将上游分支（@{u}参数）合并到你的本地分支，但是只有当你的本地分支可以“快速转发”到上游分支（换句话说，如果没有分歧）。 -
git rebase -p @{u}有效地移动了你所做的提交，但还没有推到上游分支之上，这就消除了创build你试图避免的愚蠢的合并提交的需要。 这提高了开发历史的线性度，使其更容易查看。-p选项告诉Git保留合并。 这可以防止Git线性化提交的提交。 例如，如果您将某个function分支合并到master，这一点非常重要。 没有-p，function分支上的每个提交都会在master上复制，作为git rebase完成的线性化的一部分。 这会让开发历史难以审查，并不容易。当心 ：
git rebase可能不会达到您期望的效果，因此请在推送之前查看结果。 例如：git log --graph --oneline --decorate --date-order --color --boundary @{u}..
我比较喜欢git pull --rebase这个方法，原因如下：
- 它允许您在修改历史logging之前查看传入的上游提交 。
- 它允许你将
-p（–--preserve-merges）选项传递给git rebase，以防需要重新绑定一个有意的合并（例如，将已经推送的特性分支合并到master）。
速记： git up而不是git pull
为了方便上述操作，我build议创build一个名为up的别名：
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
现在，只需要将分支更新为现在就可以运行：
git up
而不是git pull 。 如果因为你的本地分支已经偏离了上游分支而出现错误，那么这是你的基础。
为什么不git pull --rebase ？
运行git pull --rebase相当于运行git fetch然后是git rebase 。 这试图快速转发到新的上游提交，但如果这是不可能的，那么它会将您的本地提交重新绑定到新的上游提交。 这通常是可以的，但要小心：
- Rebase是一个高级话题，你应该了解rebasing之前的含义。
-
git pull --rebase并没有给你一个机会来审查提交之前，他们。 根据上游的变化，很可能rebase是错误的操作 –rebase --ontomerge，reset或push -f可能比简单的rebase更合适。 - 当前不可能将
--preserve-merges传递给rebase操作，因此特征分支的任何有意合并将被线性化，重放（并因此复制）所有的function分支提交。
修复由git pull创build的现有合并提交
如果你还没有推送由git pull创build的合并提交，你可以重新合并提交。 假设你没有做任何有意的合并（例如，把一个已经推入的特性分支合并到你当前的分支中），下面应该这样做：
git rebase @{u}
上面的命令告诉Git从HEAD （当前提交）中select所有可到达的非合并提交，减去所有可从@{u}到达的提交（这是“上游分支”的简写，即origin/master if HEAD是master ），在上游分支顶部重播（cherry-pick）它们，然后移动当前分支引用以指向重放提交的结果。 这有效地将非合并提交移动到最近的上游提交，这消除了由git pull创build的合并。
如果你有一个有意的合并提交，你不想运行git rebase @{u}因为它会重播其他分支的所有内容。 处理这种情况要复杂得多，这就是为什么使用git up并避免git pull的好处。 你可能不得不使用reset来撤消由pull创build的合并，然后做git rebase -p @{u} 。 git rebase的-p参数对于我来说并不可靠，所以你最终可能不得不使用reset来撤消有意的合并，把你的本地分支更新到@{u} ，然后重做有意合并（这是一个痛苦，如果有很多毛的合并冲突）。
git fetch git rebase origin/master
这应该做到这一点。 或者如果你想继续使用拉
git pull --rebase
您也可以在您的configuration中设置该分支自动重新绑定，或者自动设置为您创build的任何其他跟踪分支。 那么你可以回去使用
git pull
更多关于这个在这个页面的“拉和rebase而不是合并”部分：
