如何使用git拉

git pull: Update your local working branch with commits from the remote, and update all remote tracking branches. git pull --rebase: Update your local working branch with commits from the remote, but rewrite history so any local commits occur after all new commits coming from the remote, avoiding a merge commit. git pull --force: This option allows you to force a fetch of a specific remote tracking branch when using the option that would otherwise not be fetched due to conflicts. To force Git to overwrite your current branch to match the remote tracking branch, read below about using git reset. git pull --all: Fetch all remotes - this is handy if you are working on a fork or in another use case with multiple remotes.

我认为这可以归结为个人喜好。

您想要在推动更改之前隐藏您的愚蠢错误吗?如果是这样，git拉-rebase是完美的。它允许您稍后将提交压缩为几个(或一个)提交。如果你在你的(未推送的)历史中有合并，那么以后做git rebase就不那么容易了。

我个人并不介意公布我所有的愚蠢错误，所以我倾向于合并而不是重新建立数据库。

一个实践案例是当你与Bitbucket PR合作时。 让我们用下面的例子来理解它:

这里有公共关系部门。

然后你决定通过BitBucket GUI用最新的Master分支重新构建PR远程分支。这个操作将改变你的PR的提交id。

因为您已经使用GUI重新创建了远程分支。首先，你必须同步你电脑上的本地分支和远程分支。

在这种情况下，git pull -rebase就像魔法一样有效。

在git pull -rebase之后，你的本地分支和远程分支具有相同的历史和相同的提交id。

那么现在，如果您向PR分支添加一个新的提交/更改。

你可以很好地推送一个新的提交，而不需要使用强制或任何东西到远程分支/BitBucket PR。

也许最好的解释方式是用一个例子:

Alice creates topic branch A, and works on it Bob creates unrelated topic branch B, and works on it Alice does git checkout master && git pull. Master is already up to date. Bob does git checkout master && git pull. Master is already up to date. Alice does git merge topic-branch-A Bob does git merge topic-branch-B Bob does git push origin master before Alice Alice does git push origin master, which is rejected because it's not a fast-forward merge. Alice looks at origin/master's log, and sees that the commit is unrelated to hers. Alice does git pull --rebase origin master Alice's merge commit is unwound, Bob's commit is pulled, and Alice's commit is applied after Bob's commit. Alice does git push origin master, and everyone is happy they don't have to read a useless merge commit when they look at the logs in the future.

注意，合并到的特定分支与示例无关。本例中的Master可以是一个发布分支或开发分支。关键是Alice和Bob同时将他们的本地分支合并到一个共享的远程分支。

Git pull -rebase可能会从合作者Git push -force中隐藏历史重写。我建议只有当你知道你忘记在其他人做同样的事情之前推送你的提交时，才使用git pull -rebase。

如果你没有提交任何东西，但你的工作空间不干净，只是在git隐藏之前要git拉。这样你就不会默默地重写你的历史(这可能会默默地丢掉你的一些工作)。

只需记住:

Pull = fetch + merge Pull—rebase = fetch + rebase

因此，选择您想要处理分支的方式。

你最好知道merge和rebase的区别:)