我什么时候需要在"git add,git commit"之前或之后做"git pull"？

Question

什么是正确的方法？

git add foo.js
git commit foo.js -m "commit"
git pull
git push

要么

git pull
git add foo.js
git commit foo.js -m "commit"
git push

要么

git add foo.js
git pull
git commit foo.js -m "commit"
git push

UPD:

我忘了提及,在这种情况下,我使用的git add,要进行一次跟踪和修改的文件.不要将全新文件包含到存储库中.这会改变命令的顺序吗？

Answer 1

我认为最好的方法是:

存储您的本地更改:

git stash

将分支更新为最新代码

git pull

将您的本地更改合并到最新代码中:

git stash apply

添加,提交和推送您的更改

git add
git commit
git push

根据我的经验,这是使用Git最少阻力的路径(无论如何在命令行上).

也许这太轶事了,但我总是发现这种方法(在命令行而不是像sourcetree这样的东西)要容易得多.在大型团队中工作时执行提交然后拉动总是导致大的合并冲突,因为git不太善于将我的更改合并到带有传入的文件.通过存储,它允许我提取新的更改,然后使用更新的代码作为添加我的更改的基础.处理冲突更容易,因为它们对我来说更清楚(因为我现在的变化是冲突).事后看来,对我的情况来说可能更容易. (5认同)
您能解释一下*为什么*这更好吗？这样可以避免什么问题？特别是为什么这比简单的commit> pull> push更好？（我觉得这可能是最好的答案，但目前没有足够的信息甚至不能被认为是一个好的答案。） (3认同)
所以这听起来像是“你怎么吃大象？一次咬一口”这样的事情。即，将过程分解为更多的步骤以简化合并，从而减少并可能更清晰的更改。说得通。 (2认同)
@AaronFranke 然后开始使用 `git stash`。 (2认同)

Answer 2

pull = fetch + merge.

你需要在合并之前提交你所做的事情.

提交后拉.

这是否意味着你最终为每个提交做出额外的提交并使repo马虎？此外,您的初始提交消息最后会出现合并注释.如果是这样,我倾向于使用@johnjo下面提到的存储方法. (7认同)
@DanielM是的,合并有一个额外的提交(带有显式的默认提交消息).这是一件非常好的事情,因为它允许您检查上次提交或同事的上次提交或合并提交.如果你想避免它,如果你想在你的同事提交之后提交你的提交,你可以`rebase`而不是`merge`.您可以使用`git commit && git rebase`或`git pull --rebase`来完成. (3认同)

Answer 3

我建议尽可能多地从远程分支中取出,以便最大限度地减少大型合并和可能的冲突.

话虽如此,我会选择第一个选项:

git add foo.js
git commit foo.js -m "commit"
git pull
git push

在拉动之前提交您的更改,以便在提取期间将提交与远程更改合并.这可能会导致您可以开始处理的冲突,知道您的代码已经提交,如果出现任何问题,您必须因任何原因中止合并.

我敢肯定有人会不同意我的观点,我认为没有任何正确的方法来做这个合并流程,只有最适合人们的方法.

Answer 4

我认为git pull --rebase是将您本地最近的提交设置在您在某个时候没有的远程提交之上的最干净的方法。

因此，这样您就不必每次想要开始进行更改时都拉动。