我只需要澄清我对某件事的怀疑。假设我的同事和我正在同一个名为 dev 的分支上编写一些代码。在没有任何冲突的情况下提取他的代码的正确方法是什么？
这是我做的，我做了以下
git add .
git commit -m " First Commit"
git pull origin branch dev
运行后，它会自动与我现有的代码合并，没有任何冲突。这些步骤正确吗？
谢谢。
【问题讨论】：
标签： git bitbucket git-push git-pull
在没有任何冲突的情况下提取他的代码的正确方法是什么
让我们说清楚。提交拉推是共享工作的标准正确程序。但是，如果您认为有一种方法可以保证拉动时不会发生冲突，请多考虑一下。没有这样的方法。任何时候两个人处理同一个文件，都可能导致冲突。我的建议是克服你对冲突的恐惧。
【讨论】：
如前所述，Git 不能保证“没有任何冲突”。
只有您和您的同事之间的良好沟通才能保证您不会处理相同文件的相同部分，从而消除任何冲突的机会。
但是关于您集成同事更改的方式，我建议在您的存储库中使用 (since Git 2.6)：
git config pull.rebase true
git config rebase.autoStash true
那么您的 git pull 实际上会在更新的 dev 分支之上重新定位（重放）您的本地提交（您尚未推送）。
这将使历史更加线性和清晰。
【讨论】：
这里的一些答案可能会对你有所帮助，但我认为有些事情应该更清楚。
您唯一能做的就是尽量减少发生冲突的可能性，如果发生冲突，您可以简化处理它们的过程。
当两个人更改相同的行时，通常会发生冲突 在一个文件中，或者如果一个开发者删除了一个文件，而另一个开发者 正在修改它。在这些情况下，Git 无法自动确定 什么是正确的。
引用自Atlassian Git-Merge。git pull 也存在冲突，但很明显：
git pull 将下载远程内容并立即尝试 更改本地状态以匹配该内容。这可能无意中 导致本地存储库处于冲突状态。
引用自Atlassian Git-Pull
除了对冲突的枯燥定义之外，您的工作文化还应该使冲突最小化。
它基本上归结为避免处理相同的文件，如果这样做，请确保您没有更改相同功能的实现，这将最大限度地减少您解决冲突的机会。
首先，尽量不要在同一个分支上工作，并将你的工作分开到不同的特性分支，所以现在你合并到特性/发布分支，而不是拉同一个分支，取决于你的 gitflow。
“但我们正在开发相同的功能”
太好了，把它分开做不同的任务，如果你发现自己在做同一个任务，你可能做错了什么。
尝试将您的功能拆分为较小的任务并为每个任务打开一个分支，以便您可以单独工作。
“但我们不能分开工作，因为我的工作依赖于他”
没问题，当你的队友完成他的任务时，你就去做；如果你把你的工作分成更小的任务，你不会等到他完成的时候，如果遇到一种情况，你真的在很短的时间间隔内在分支之间乒乓球，也许你们中的一个人应该照顾整个功能，另一个在其他方面工作。
即使您安全地工作，最终每个人都会有冲突。
如果您选择 merge 一个分支到另一个分支，git 将检查源分支和目标分支之间的整体差异，因此如果您有多个冲突，您将一起收到它们并被要求修复它们。
另一种方法是使用rebase，它使您的 git 树更平坦，而不是使整个分支不同，而是从目标分支开始，并从分支相同的最后一点开始应用源分支的提交，一个之后另一个直到它在目标分支上提交源分支的最后一次提交。
这样（rebase），如果您有任何冲突，您将在导致冲突的提交上解决它，能够更改特定的提交更改；因此，如果您有来自不同提交的多个冲突，您将分别处理它们。
这也有缺点：
使用 Git Rebase 时要考虑的一个警告是合并冲突 在变基工作流程期间可能会变得更加频繁。如果您发生这种情况 有一个长期存在的分支，它偏离了主人。最终你 将要针对 master 进行 rebase，那时它可能包含 您的分支更改可能与之冲突的许多新提交。这是 通过经常针对 master 重新定位您的分支，很容易解决，并且 进行更频繁的提交。
您可以阅读有关difference between git merge and git rebase 的更多信息。
您可以阅读有关gitflow workflow 的更多信息。
【讨论】：