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

我读了以下帖子：

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

这是否是推动其新更改的可能工作流程：

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

或者是

git stash

优于

git commit

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

这也很好（并且工作不会被承诺）：

---

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

---

如果你有这样一个“完全”的改变，无论如何，你应该提交它。如果没有，可能最好隐藏您的更改，从远程拉取，然后将隐藏的更改弹出到您的工作索引中。

在下文中，我没有提到使用

拉取
；正如您所注意到的，它基本上是
fetch
，然后是
merge
（除非配置为不同的内容），因此您可以根据需要替换它

两个人共享一个分支的最简单工作流可能是
提交
，
获取
，
合并
，
推送
。将其视为默认设置可能是好的，认识到您要做不同事情的原因：

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

这一点很重要，因为如果您在提交
O
，您有本地更改，您将其提交为
L
，然后获取并合并远程提交
R
，您最终会得到如下结果

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

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

解决这一问题的最简单方法是
隐藏
您的本地更改，而不是在它们尚未准备好提交时提交它们。当您弹出（或应用）隐藏时，您仍然需要解决任何冲突。结果将是

O -- R <--(master)

O--R他需要在提取之前提交或隐藏更改。那么，如果我计算机上的数据丢失，我是否有可能在几天内不提交更改，并且这不会危及项目？这是一个合理的担忧。这就是为什么有些人做出几次承诺，然后将其压扁。就我个人而言，我认为最好的做法是尽量使你的“完全改变”足够小，你可以在一天内完成它们。最后，您可以自行决定风险级别（有多少未提交的代码）以及如何管理提交和分支。您甚至可以省略
保存
，因此
git stash
结果：
主控台上保存的工作目录和索引状态WIP:570f85b commit from..
。
O -- L -- M <--(master)
 \       /
  -- R --

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

O -- R <--(master)