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

Question

我看了以下帖子：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

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

如果你有这样一个“完全”的改变，你应该提交它。如果没有，最好隐藏您的更改，从远程拉出，并将隐藏的更改弹回到您的工作索引。

Answer 2

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

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

这也没关系（并且不会提交工作）：

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

Answer 3

在下面，我没有提到使用pull;如你所知，它基本上是fetch，后面是merge（除非配置为不同的东西），所以你可以适当地替换它。

可能两个人共享分支的最简单的工作流程是commit，fetch，merge，push。把它当作默认值可能很好，认识到为什么你会做一些不同的事情：

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

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

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

现在，L基本上被锁定在你的历史中（特别是在随后的push之后）。因此，例如，如果您再进行一些本地更改并提交它们

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

没有一种简单的方法可以将L和L2压在一起。

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

O -- R <--(master)

with uncommitted（可能是unstaged，取决于你如何处理stash）的变化。

另一个常见的变化是rebase本地更改在新提交的提交之上。这可以使历史记录看起来更简单（废除提交以将本地更改与远程更改合并），并且由于它保留了本地更改，因此更容易修改它们（只要您没有推送它们）。但是，它还会创建尚未真正通过您可能拥有的任何自动化测试的提交状态，因此如果您想要如上所述的“干净提交”策略，则可能会发生冲突。