git 工作流程：我应该在拉取之前提交吗？

Question

我阅读了以下内容post： How do you git fetch then merge? "Error: Your local changes to the following files would be overwritten by merge"

我和我的朋友在 git 的同一个分支上工作。当他对我们的项目进行更改并拉取项目时，他收到错误消息，他的本地更改将被覆盖。

这是一个可能的工作流程来推动他的新变化吗：

git commit 
git pull (or fetch and merge)
git push

或者 git stash 比 git commit

好吗

Answer 1

这很好（工作将被提交）：

git commit 
git pull (or fetch and merge)
git push

这样也可以（工作不会提交）：

git stash save
git pull (or fetch and merge)
git stash pop

Answer 2

通常只有在您拥有完整的变更集时才应该提交（这通常意味着它在没有警告的情况下编译，所有测试都通过，并且它实现了一些逻辑上的改进）。

如果您有这样的 "complete" 更改，无论如何，您应该提交它。如果没有，最好存储您的更改，从远程拉取，然后将存储的更改弹出回您的工作索引。

Answer 3

下面不提pull的使用；正如您所注意到的，它基本上是 fetch，然后是 merge（除非配置为不同的东西），因此您可以根据需要替换它。

两个人共享一个分支的最简单的工作流程可能是 commit、fetch、merge、push。将其视为默认值可能很好，认识到您会做一些不同的事情的原因：

首先，这确实假设您已经在本地达到了想要创建永久提交点的状态。你的标准是什么将是你的团队的讨论，但基本上你只是说这是你应该能够在未来 return 达到的一点。您可能不想让一堆部分完成的更改弄乱您的历史记录，并且出于调试目的，一些团队说每个永久提交都应该通过自动化测试。

这很重要，因为如果你在提交 O，你有你提交为 L 的本地更改，然后获取并合并远程提交 R，你最终得到类似

的东西

O -- L -- M <--(master)
 \       /
  -- R --

现在 L 基本上被锁定在您的历史记录中（尤其是在随后的 push 之后）。因此，例如，如果您随后进行一些更多的本地更改并提交给

O -- L -- M -- L2 <--(master)
 \       /
  -- R --

没有直接的方法将 L 和 L2 压缩在一起。

解决这个问题的最简单方法是 stash 您的本地更改而不是提交它们 如果它们还没有准备好提交 。当您弹出（或应用）存储时，您仍然必须解决任何冲突。结果将是

O -- R <--(master)

具有未提交（并且可能未暂存，具体取决于您处理存储的方式）的更改。

另一个常见的变体是 rebase 在新获取的提交之上进行本地更改。这可以使历史看起来更简单（取消提交以将本地更改与远程更改合并），并且由于它使您的本地更改保持在尖端，因此更容易修改它们（只要您没有推送它们）。但是，它还会创建尚未真正通过您可能拥有的任何自动测试的提交状态，因此如果您想要 'clean commit' 建议的策略，运行可能会发生冲突以上。

git 工作流程：我应该在拉取之前提交吗？

git workflow: should I commit before I pull?

git

git-stash

git-commit