我在一个由3人组成的团队中工作，我们通常不会编辑相同的文件。当我有更改要发送时，我会提交并推送。通常这是有效的。
然而，有时，我们在争分夺秒。如果有人在我之前推，我会得到失败的推
$ git push
X11 forwarding request failed on channel 0
To git@gitlab.ku.edu:crmdaprojects/Ticket-631.git
! [rejected] reports2016 -> reports2016 (fetch first)
error: failed to push some refs to
'git@gitlab.ku.edu:crmdaprojects/Ticket-631.git'
hint: Updates were rejected because the remote contains work
that you do
hint: not have locally. This is usually caused by another
repository pushing
hint: to the same ref. You may want to first integrate the
remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help'
for details.
我是唯一一个编辑过我提交的文件的人。如果我的修改通过了，不会对项目造成损害。我没有编辑队友们输入的任何文件。不幸的是，他们在一个完全不同的目录中更改了一些内容。天啊，我真希望我的承诺能在没有分心的情况下进入遥控器。
不过，我知道git不想这么做。所以我遵循的提示
$ git pull
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 3), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From gitlab.ku.edu:crmdaprojects/Ticket-631
04cb4c6..05b2c2f reports2016 -> origin/reports2016
Merge made by the 'recursive' strategy.
WI/R/import.R | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
这个拉动导致合并，编辑器弹出，我被要求解释我为什么导致合并。我键入的只是"我运行了git pull，我不知道正在合并哪些冲突"，因为从vi会话的内部来看，我甚至无法判断git更改了哪些文件。在我保护提交消息后，我看到它只是编辑了一个文件，"import.R"
这个文件"import.R"，不是我工作的一个。它是由一个队友在周末更改的，他在我有机会之前推送了它。据我所见，更新没有害处。拉动并不危险。
然而，这种工作流程并不方便。每次我想推动这个更大项目的我的部分时，推动都会失败，我必须拉动，然后试着了解发生了什么。如果我每天工作8个小时，我会浪费20或30分钟来找出推送失败或拉取导致合并错误的原因。
我想知道是否有一个不那么令人恼火的工作流程。当一个项目中有10个程序员，并且他们一直在做更改时，程序员如何保持理智？有没有一种很好的方法可以知道我正在编辑的文件是否在远程更改了？如果不是，那么我不介意拉，我只是继续前进，就像上面的情况一样。我可能想快速了解一下发生了什么变化，但这不是我现在的首要任务。我最关心的是对我现在正在修改的文件进行修改。
从git手册中，我可以看到很长的路要走：
$ git fetch
$ git diff
然后我费力地完成了一些输出。有没有更好的方法将其融入我的日常工作流程？
我认为您的沮丧源于您还不太习惯git这一事实。拉和推应该需要大约30秒，通常更短。
git并不关心您是否正在接触同一个文件。事实上，你也不应该在意。如果有人更改了项目中的文件，很可能他们刚刚破坏了你正在处理的代码。代码并不是与它所写的文件隔离的。你通常应该总是拉、构建、测试、推送。
但是，如果在同一文件的同一行上对进行了更改，则会出现真正的冲突，需要解决。如果你不想每次拉合并提交，你需要运行以下程序来全局配置它：
git config --global --add merge.ff true
或者对于当前拉力：
git pull --ff-only
这将阻止创建合并提交。然而，git通常会预先填充合并提交注释，因此您很可能可以保持配置不变，在合并时只需点击"OK"（假设没有冲突）。
最后，人们通常在自己的分支上工作，只有在功能完成后才能合并回dev/master（也就是说，每个功能只合并一次，除非进行修复等）。这样，您就不会发生冲突，也不必提取更改