Question

我对git非常陌生，我想到目前为止我已经了解了基础知识，但是我不确定某些标准的工作流程。

所以，如果我有一个常见的情况，我是从

之类的远程存储库中提取的最后一个信息

git pull master

几天前，在其上创建了一个分支

git branch myBranch
checkout myBranch

并在该分支机构工作了几天。

现在，我想将包含更改的分支推送到远程git存储库中，但当然首先要了解最新的更改，这些更改发生在我上次提取请求到现在之间。我该怎么做？我以为应该做

git rebase master

但是我发现一些信息，应该尽可能避免变基。

所以我想知道在这种情况下的标准程序是什么？

Answer 1

在处理最终将作为请求请求的分支时，Rebase是一种很好的做法。这样可以使提交历史记录更整洁，并有助于避免某些合并冲突。

没有rebase的“老方法”是在本地分支上使用merge。

master *---*-----------*---*
        \                   \ (merge)
myBranch *---*---*---*---*---*---*---*

如果在创建将分支返回到master的拉取请求之前多次合并master，这可能会使分支混乱。相反，这里的rebase会剪切分支的起点并将其上移：

master *---*---*---*
     (rebase)...    \
myBranch             *---*---*---*---*---*---*

rebase时，任何其他在自己的本地副本上处理过分支的人都会遇到一些困难，但是由于您的分支仅在您的计算机本地，因此不必担心。

您可以使用以下命令执行变基：

(myBranch):$ git fetch
(myBranch):$ git rebase origin/master

Answer 2

没有“标准”程序。

有些人更喜欢将master合并到分支中：

git checkout myBranch
git fetch
git merge origin/master
# adds a merge commit that merges currentmost master into myBranch

而其他人则宁愿将分支重新建立在master之上（以保持平坦的历史记录）：

git checkout myBranch
git fetch
git rebase origin/master  
# rewrites whole myBranch to start at currentmost master, instead of previous master

这主要是关于个人喜好，特定的项目政策以及保持git历史记录可读性的权衡。

Answer 3

在处理feature-branch时，同时master/develop-branch继续进行。您需要更新feature-branch。为此，您需要使用一个变基，以便您的提交成为feature-branch中的最后一个提交。您不应该使用合并来更新feature-branch，这只会使git历史复杂化。

$ git checkout master
$ git pull origin master
$ git checkout mybranch
$ git rebase master
$ git push origin mybranch

在本地分支上工作后使用git rebase

3 个答案: