协慌网

创建了一个来自master的新分支，我们将其称为test 。

有几个开发人员承诺master或创建其他分支，然后合并到master 。

假设test工作需要几天时间，并且您希望通过master内部的提交不断更新test 。

我会从test做git pull origin master 。

问题 1：这是正确的方法吗？其他开发人员可以轻松地处理相同的文件，就像我工作顺便说一句。

我的test工作已经完成，我准备将它合并回master 。以下是我能想到的两种方式：

A：

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test

B：

git checkout test
git pull origin master
git checkout master
git merge test

我没有使用--rebase因为根据我的理解，rebase 将从master和 stack mine 获得更改，因此它可以覆盖其他人所做的更改。

问题 2：这两种方法中哪一项是正确的？那有什么区别？

所有这一切的目标是让我的test分支更新为master发生的事情，之后我可以将它们合并回master希望尽可能保持时间线的线性。

我该怎么做

git checkout master
git pull origin master
git merge test
git push origin master

如果我有一个远程本地分支，我觉得将其他分支与远程分支合并后感觉不舒服。此外，我不会推动我的更改，直到我对我想要推送的内容感到满意，而且我根本不会推送任何东西，这些内容仅适用于我和我的本地存储库。在您的描述中，似乎该test仅适用于您？所以没有理由发表它。

git 总是试图尊重你和其他人的变化，所以--rebase也是如此。我不认为我能够恰当地解释它，所以看看Git 书 - 重新定位或git-ready：介绍变基础以获得一些描述。这是一个非常酷的功能

这是一个非常实际的问题，但上述所有答案都不切实际。

喜欢

git checkout master
git pull origin master
git merge test
git push origin master

这种方法有两个问题 ：

1. 这是不安全的，因为我们不知道测试分支和主分支之间是否存在任何冲突。

2. 它会将所有测试提交 “挤压” 到 master 上的一个合并提交中; 也就是说在 master 分支上，我们看不到测试分支的所有更改日志。

所以，当我们怀疑会有一些冲突时，我们可以进行以下 git 操作：

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

在commit之前测试merge ，避免--no-ff的快进提交，

如果遇到冲突，我们可以运行git status来检查有关冲突的详细信息并尝试解决

git status

一旦我们解决了冲突，或者没有冲突，我们就会commit并push冲突

git commit -m 'merge test branch'
git push

但是这种方式将丢失测试分支中记录的更改历史记录，并且它会使主分支很难让其他开发人员了解项目的历史记录。

所以最好的方法是我们必须使用rebase而不是merge （假设，在这个时候，我们已经解决了分支冲突）。

以下是一个简单的示例，对于高级操作，请参阅http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

是的，当你完成鞋面时，所有 Test 分支的提交都将转移到 Master 分支的头部。变基的主要好处是可以获得线性且更清晰的项目历史记录。

你唯一需要避免的是：永远不要在公共分支上使用rebase ，比如 master branch。

切勿执行以下操作 ：

git checkout master
git rebase -i test

https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing 的详细信息

附录：

• 如果您不确定重新定位操作，请参阅： https ： //git-scm.com/book/en/v2/Git-Branching-Rebasing

无论是 rebase 还是合并都不应该覆盖任何人的更改（除非您在解决冲突时选择这样做）。

开发过程中的常用方法是

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

当你准备合并回主人，

git checkout master
git log ..test # if you're curious
git merge test
git push

如果你担心在合并上破坏某些东西， git merge --abort就在那里。

使用 push 然后 pull 作为合并的手段是愚蠢的。我也不确定你为什么要把测试推向原点。