最好（也是最安全的）将git分支合并到master中
从master创build一个新的分支，我们称之为test 。
有几个开发人员要么承诺master或创build其他分支，然后合并到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 ，rebase会从master和stack上取得变化，因此它可以覆盖其他人的变化。
问题2：这两种方法哪一种是对的？ 那里有什么区别？
所有这一切的目标是让我的test分支更新为master发生的事情，之后我可以将它们合并回master希望能够保持时间线尽可能的线性。
我将如何做到这一点
git checkout master git pull origin master git merge test git push origin master
如果我有一个远程分支的本地分支机构，我觉得把这个分支与远程分支合并是不合适的。 另外，我不会推动我的改变，直到我对我想要推动的事情感到满意，而且我也不会推动所有事情，只有我和我的本地存储库。 在你的描述中，似乎这个test只针对你？ 所以没有理由发表它。
git总是试图尊重你和其他人的变化，所以会--rebase 。 我不认为我可以适当地解释它，所以看一下Git书 – 重新编辑或者git-ready：介绍一下稍微描述一下。 这是一个非常酷的function
这是一个非常实际的问题，但是上面的所有答案都是不实际的。
喜欢
git checkout master git pull origin master git merge test git push origin master
这种方法有两个问题 ：
-
这是不安全的，因为我们不知道testing分支和主分支之间是否有任何冲突。
-
它会把所有的testing提交“压缩”成为一个主合并提交; 也就是说在master分支上，我们看不到testing分支的所有更改日志。
所以，当我们怀疑会有一些冲突，我们可以有以下的git操作：
git checkout test git pull git checkout master git pull git merge --no-ff --no-commit test
在commit之前testingmerge ，避免由--no-ff进行快速提交，
如果遇到冲突，我们可以运行git status来检查有关冲突的细节并尝试解决
git status
一旦我们解决冲突，或者如果没有冲突，我们commit并push它们
git commit -m 'merge test branch' git push
但是这种方式会丢失testing分支中logging的变化历史logging，使得主分支难以让其他开发人员了解项目的历史。
所以最好的方法是我们必须使用rebase而不是merge （假设，在这个时候，我们已经解决了分支冲突）。
以下是一个简单的示例，对于高级操作，请参阅http://git-scm.com/book/en/v2/Git-Branching-Rebase
git checkout master git pull git checkout test git pull git rebase -i master git checkout master git merge test
是的，当鞋底完成时，所有testing分支的提交将被移动到主分支的头部。 重新devise的主要好处是您可以获得线性和更清洁的项目历史。
唯一需要避免的是：不要在公共分支上使用rebase ，比如master分支。
如下操作：
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
重组或合并都不能覆盖任何人的变更（除非您在解决冲突时select这样做）。
发展中的常用方法是
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在你身边。
使用推，然后拉作为合并的手段是愚蠢的。 我也不确定你为什么要testing原点。
除了KingCrunches的回答 ，我build议使用
git checkout master git pull origin master git merge --squash test git commit git push origin master
你可能在另一个分支中做了很多的提交，只能在master分支中提交。 为了保持提交历史尽可能的干净，你可能想要将所有的提交从testing分支压缩到主分支中的一个提交（参见： Git：压扁或不压缩？ ）。 然后你也可以把提交信息重写成非常有performance力的东西。 一些容易阅读和理解的东西，而不需要深入代码。
编辑：你可能会感兴趣
- 在git中，合并–squash和rebase有什么区别？
- 合并与重新激活
- 如何重新提取请求
所以在GitHub上，我最终做了以下function分支mybranch ：
从原点获取最新信息
$ git checkout master $ git pull origin master
find合并基础哈希：
$ git merge-base mybranch master c193ea5e11f5699ae1f58b5b7029d1097395196f $ git checkout mybranch $ git rebase -i c193ea5e11f5699ae1f58b5b7029d1097395196f
现在确保只有第一个pick ，其余的是s ：
pick 00f1e76 Add first draft of the Pflichtenheft s d1c84b6 Update to two class problem s 7486cd8 Explain steps better
接下来select一个非常好的提交消息，并推送到GitHub。 然后做出拉请求。
合并请求后，你可以在本地删除它：
$ git branch -d mybranch
和GitHub上
$ git push origin :mybranch
这是我在团队工作中使用的工作stream程。 场景如您所述。 首先，当我完成test我会和主人合作，在test分支上工作的时候把所有添加的东西都拉进去。
git pull -r upstream master
这会将更改拉到master，因为您已经分叉了test分支并应用它们，然后将所做的更改应用到主控的当前状态“之上”进行testing。 如果其他人对您在testing中编辑过的相同文件进行了更改，则可能存在冲突。 如果有，你将不得不手动修复它们，并提交。 一旦你这样做了，你将会切换到主分支并合并test ，没有问题。
git checkout master git pull origin master # Merge branch test into master git merge test
合并之后，如果文件被改变了，那么当你合并的时候会通过“Resolve Conflict”错误
那么你需要首先解决你所有的冲突，然后你必须再次提交所有的改变，然后推送
git push origin master
谁做了testing分支的改变，谁就知道他做了什么改变，这样做会更好。
