我是组织中唯一一位正在提交以下消息的人：
将远程跟踪分支'origin / develop'合并到develop
我不知道我在做什么导致他们，但我想停止。
我发出了什么命令来创建这个提交，我应该用什么命令来生成它？
答案 0 :(得分：177)
git pull可能正在创建提交。如果您进行本地提交，然后在其他人将提交推送到存储库后运行git pull，Git将下载其他开发人员的提交，然后将其合并到您的本地分支。
您可以使用git pull --rebase来防止将来发生这种情况，但是变基有其危险，I recommend avoiding pull altogether。
相反，我建议您遵循以下使用模式：
# 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/foo参考号。
git merge --ff-only @{u}告诉Git将上游分支（@{u}参数）合并到您的本地分支中，但前提是您的本地分支可以“快速转发”到上游分支（在其他分支中）单词，如果没有分歧的话。）
git rebase -p @{u}有效地移动了您已经提交但尚未推送到上游分支的提交，这消除了创建您试图避免的愚蠢合并提交的需要。这样可以提高开发历史的线性度，使其更易于查看。
-p选项告诉Git保留合并。这可以防止Git线性化被重新提交的提交。例如，如果将要素分支合并到master中，则这很重要。如果没有-p，则master上的每个提交都会在git rebase上重复，这是git rebase完成线性化的一部分。这将使开发历史更难以审查，而不是更容易。
小心：git log --graph --oneline --decorate --date-order --color --boundary @{u}..
可能无法按预期执行操作，因此请在推送前查看结果。例如：
git pull --rebase我更喜欢这种方法而不是-p，原因如下：
--preserve-merges（git rebase）选项传递给master，以防您需要重新定义有意合并（例如，将已推送的功能分支合并到{ {1}}）。git up而不是git pull 为了便于执行上述操作，建议您创建一个名为up的别名：
git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'
现在，您需要做的就是让您的分支更新：
git up
而不是git pull。如果由于您的本地分支与上游分支不同而出现错误，那就是您对rebase的提示。
git pull --rebase？运行git pull --rebase相当于运行git fetch后跟git rebase。这会尝试快进到新的上游提交，但如果这不可能，那么它会将您的本地提交重新绑定到新的上游提交。这通常没问题，但要小心：
git pull --rebase在合并之前不会给您机会检查提交。根据上游改变的内容，rebase很可能是错误的操作 - rebase --onto，merge，reset或push -f可能比普通{rebase更合适1}}。--preserve-merges传递给rebase操作，因此任何有意合并的功能分支都将被线性化，重放（并因此复制）所有功能分支提交。git pull 如果您尚未推送git pull创建的合并提交，则可以重新定义合并提交。假设您没有进行任何有意合并（例如，将已推送的功能分支合并到当前分支中），则应执行以下操作：
git rebase @{u}
上面的命令告诉Git选择从HEAD（当前提交）可到达的所有非合并提交，减去从@{u}可到达的所有提交（这是“上游分支的简写”） “，即origin/master如果HEAD是master），在上游分支的顶部重放（挑选）它们，然后移动当前分支引用以指向结果重播提交。这有效地将非合并提交移动到最近的上游提交，这消除了由git pull创建的合并。
如果你有一个有意的合并提交，你不想运行git rebase @{u}，因为它会重播其他分支的所有内容。处理这种情况要复杂得多，这就是使用git up并完全避免git pull的原因。您可能必须使用reset撤消pull创建的合并，然后执行git rebase -p @{u}。 -p的{{1}}参数对我来说无法可靠地工作，因此您可能最终必须使用git rebase撤消故意合并，将您的本地分支更新为reset ，然后重做故意合并（如果有很多毛茸茸的合并冲突，那就太痛苦了。）
答案 1 :(得分：16)
git fetch
git rebase origin/master
应该这样做。或者如果你想继续使用pull
git pull --rebase
您还可以在配置中将该分支设置为自动重新绑定，或者为您以后的任何其他跟踪分支自动设置。然后你可以回到使用
git pull
有关此内容的详情，请参阅本页“使用rebase而不是merge”部分：
答案 2 :(得分：0)
将远程跟踪分支'origin/develop'合并到develop
这是一个将 origin/develop（远程更改）合并到 develop（本地更改）中的 git pull，因此我们遇到了很多问题，丢失了代码等等。
所以现在我们的工作流程可以防止 git pull 合并出现任何问题并保持简单。基本上它就像一个 rebase 但通过合并分支，在最基本的 gui 中很容易实现。其他更改始终合并到您的更改中，因此在发生冲突时，您只需修复影响您更改的行的内容！并且只有您的更改会出现在最终提交中。
是的，它看起来有点麻烦，更换树枝，拉动等等。但是，如果您查看 rebase 文档，他们会警告不要在共享分支中使用它。因此，您最终将创建相同的 X 分支，然后 git fetch origin develop 和 git rebase origin/develop 并且您仍然需要将重新定位的 X 分支合并回共享分支 develop，因此工作量相同。
通常情况下，如果在第 5 步有远程更改，特别是如果在第 6 步发生冲突。您需要再次测试并且需要时间，所以这就是您返回第 4 步的原因。第 8 步存在竞争条件和 9，但这真的是一个极端情况，有人在你之前推动。