重新上游版本

时间:2016-02-25 12:29:08

标签: git algorithm rebase

想象一下,我有一个这样的git配置:

t(rowsum(t(dat), group = colnames(dat), na.rm = T))
#  A C G T
#1 1 0 1 0
#2 4 0 6 0
#3 0 1 0 1
#4 2 0 1 0
#5 1 0 1 0
#6 0 1 0 1
#7 0 1 0 1

例如,我想在远程主服务器上重新绑定我的主分支以获得上游更改。我可以这样做:

o--o--o--o--o--o remote master
       \
        o--o--o--o my master
            \
             o--o--o feature branch

然后我会得到这个结构:

get rebase --onto remote_maste remote_maste my_master

然后我强行将其推送到我的仓库以使其他人可以使用my_master更新(想象在重新定位过程中my_master分支因新提交而关闭):

o--o--o--o--o--o remote master o--o--o--o my master
       \                       A' B'
        o--o
        A  B\
             o--o--o feature branch

所以我有两个问题。 第一个是:其他人能够将他们的功能分支重新设置为更新的主人吗?(我想是的,但我不确定) 第二个是主要问题:如果上一个问题的答案是肯定的,那么这些A和B的提交将会是什么,因为它们已经处于更新的主控(但是有其他哈希)?它们会消失,上面应用(所以我会有重复的提交)或者什么?

提前致谢。

1 个答案:

答案 0 :(得分:2)

它应该弄清楚它们是相同的而不是再次应用它们。

试试这个:

git checkout feature-branch
git rebase origin/master -i #or just master

你会看到一个要被应用的提交列表,它会发现已经应用了A和B,并且只要它们是相同的就把它们排除在外。

如果它们略有不同,(如果有人在功能分支中修改了一个),它应该让它们进入rebase,并尝试再次应用它们,并且要么以“3向合并”成功,要么你要解决冲突。