logo标签列表

我需要在"git add, git commit"之前还是之后执行"git pull"命令？

git
150

什么是正确的方式？

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

更新：

我忘了提到在这种情况下我使用git add来暂存已被跟踪并且已修改的文件，而不是将全新的文件添加到仓库中。这是否会改变命令的顺序？

相关问题：https://dev59.com/PXRA5IYBdhLWcg3wzhfZ - leo9r
6个回答
172
我认为最好的方法是：
储存您的本地更改：
git stash

更新分支至最新代码

git pull
将您的本地更改合并到最新的代码中：
git stash apply

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

git add
git commit
git push

根据我的经验，这是使用Git（至少在命令行上）最容易的方法。

7
你能解释一下为什么这样做更好吗？它避免了哪些问题？特别地，为什么这比简单的commit > pull > push更好？（我觉得这可能是最佳答案，但现在还没有足够的信息来被认为是一个好答案。） - dallin
18
也许这个故事性太强，但我总觉得这种方法（使用命令行而不是像Sourcetree那样）更容易。在一个大团队中进行提交然后拉取时，Git 通常无法很好地将我的文件更改与新进来的合并，导致了较大的合并冲突。通过存储，它允许我先拉取新的更改，再使用更新的代码作为基础添加我的更改。处理冲突变得更加容易，因为它们对我来说更加清晰（因为我的更改现在是冲突）。回想起来，也许只是对我这种情况更容易些。 - johnjo
4
听起来有点类似于“大象怎么吃？一口一口地吃。”即将过程分解成更多步骤，以简化合并操作，减少可能出现的更改并使其更加清晰。这很有道理。 - dallin
1
这里需要使用git add吗？如果所有文件都已经添加到暂存区了！ - Sharp Edge
2
@AaronFranke 然后开始使用 git stash。 - Slbox
显示剩余2条评论
91

拉取 = 获取 + 合并。

在合并之前，您需要提交您所做的更改。

因此，在提交后进行拉取。

11
这是否意味着每次提交后你都会多做一次提交，使存储库变得混乱？而且每次提交后，你的初始提交消息都会被合并注释所跟随。如果是这样的话，我倾向于使用@johnjo下面提到的隐藏方法。 - MondayPaper
6
@DanielM 是的，合并时会有额外的提交（带有明确的默认提交信息）。虽然如此，这其实是一件好事，因为它允许你检出你最后一次提交、你同事最后一次提交或合并提交。如果你想避免这种情况，而且想将你的提交放在同事提交之后，可以选择rebase而不是merge。你可以使用 git commit && git rebase 或者 git pull --rebase 来完成。 - Arnaud Denoyelle
感谢您的提示，@Arnaud。在阅读了许多不同的SO问题后，这个评论很有用。当我的同事们在不同的文件上工作时，我首选的选项是在暂存我的更改后执行git pull，因为我认为这是最自然的方式。虽然我意识到许多不同的工作流程也可以使用（stash 也很好），所以这可能只是个人口味的问题。 - nephewtom
61

我建议尽可能经常从远程分支拉取代码，以便最小化大型合并和可能的冲突。

话虽如此，我会选择第一种选项：

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

在拉取代码之前，请先提交您所做的更改，以便在拉取期间将您的提交与远程更改合并。这可能会导致冲突，但此时您的代码已提交，如果发生任何错误并且必须中止合并，则可以开始处理。

虽然我确定有人不同意我的看法，但我认为没有任何“正确”的方法来执行此合并流程，只有最适合个人的方式。

1
请您看一下我对问题的更新？我忘记解释在我的例子中 git add 到底是用来做什么的了。 - Green
1
无论是新文件还是已跟踪/修改的文件，都不应该有任何区别。仍然要提交并拉取。 - Jasarien
11

我认为 git pull --rebase 是把本地最新的提交放在一定点之后的远程提交的最干净的方法。

这样，你就不必每次想开始做更改时都要拉取了。

1
这也是我的做法，但需要指出的是，在这方面确实存在两种主要的思路（围绕着是在单个提交中解决冲突更好，还是在合并提交中解决冲突），而 Linus 本人则属于后者。值得庆幸的是，工具本身并不持有任何观点，所以请根据您和项目的需求使用最适合您的方式 :-) - Luke Usherwood
谢谢你的推荐。你会在提交之前做这个吗？还是在添加之前？或者在推送之前？ - undefined
2

你希望你的更改建立在远程分支当前状态之上。因此，在提交之前很可能需要先拉取。然后再次推送您的更改。

只要本地文件与远程分支没有冲突，“脏”本地文件就不是问题。但如果存在冲突，则合并将失败，因此在提交本地更改之前拉取没有任何风险或危险。

1
无法工作，正如Arnaud所提到的，拉取需要您先提交更改。 - Jasarien
我的git似乎很乐意拉取有很多本地更改的内容。 当然，如果远程分支上更改了相同的文件，则拉取操作的合并部分将失败。 要创建适当的合并冲突，我必须首先提交。 因此，如果本地和远程更改文件的集合是不相交的，则先拉取再提交就可以了。 否则，git将无法拉取。 尝试没有任何损害。 - AlexE
这是我在人们同时处理不同文件时的首选选项，我发现它最为自然。 - nephewtom
1

对我来说最好的方法是：

  1. 创建新分支，切换到该分支
  2. 创建或修改文件，git add，git commit
  3. 回到主分支并从远程进行拉取（以获取最新的主分支更改）
  4. 将新创建的分支与主分支合并
  5. 删除新创建的分支
  6. 将主分支推送到远程

或者您可以将新创建的分支推送到远程并在那里合并（如果您以这种方式执行，则最后需要从远程主分支进行拉取）

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接