Git - 与其他人在分支机构工作时是拉动还是变形

所以,如果我使用的是远程(跟踪)分支的分支,我想获得最新的,我还不清楚我是否应该做git pull或git rebase.我以为我已经读过git rebase在与其他用户一起工作的时候做的事情,当他们拉动或重新绑定时,它可以搞砸了.真的吗？我们都应该使用git pull吗？

Git pull是2个命令的组合

git fetch(使用遥控器上最新的东西同步你的本地仓库)

git merge(将远程分支的更改(如果有)合并到本地跟踪分支中)

git rebase只是git merge的粗略等价物.它无法远程获取任何内容.事实上,它也没有进行适当的合并,它重放了你在第二个分支的新提交后所站立的分支的提交.

其目的主要是让您拥有更清洁的历史.在gitk过去的历史中,很多人并没有需要很多合并才能获得意大利面条.

在这里的前2个图形中可以看到最好的图形说明.但是,让我在这里用一个例子来解释.

我有两个分支:主人和mybranch.站在mybranch上我可以跑

git rebase master

在mybranch最近的提交之前,我会在master中插入任何新东西.这是完美的,因为如果我现在在master中合并或重新绑定mybranch中的东西,我的新提交会在最近的提交后线性添加.

如果我在"错误"的方向上重新定位,你提到的问题就会发生.如果我刚刚获得了最新的主人(有了新的更改),并且从主人那里就像这样(在同步我的分支之前)进行rebase:

git rebase mybranch

现在我刚刚做的是我在master过去的某个地方插入了我的新变化.提交的主线已经改变.由于git使用commit id的方式,所有刚刚重新播放的提交(来自master)都有新的ID.

嗯,用语言解释有点难...希望这有点意义:-)

无论如何,我自己的工作流程如下:

'git pull'来自远程的新变化

切换到mybranch

'git rebase master'在我的提交历史中带来了master的新变化

切换回主人

'git merge mybranch',只有当master中的所有内容都在mybranch中时才会快进(因此避免了公共分支上的提交重新排序问题)

'git push'

最后一句话.我强烈建议在差异微不足道时使用rebase(例如,处理不同文件或至少不同行的人).它有我试图在那里解释的问题,但它创造了一个更清洁的历史.

一旦可能存在重大冲突(例如,同事已经在一堆文件中重命名了某些内容),我强烈建议合并.在这种情况下,系统会要求您解决冲突,然后提交解决方案.从好的方面来说,当存在冲突时,合并更容易解决.不好的一面是,如果很多人确实合并,你的历史可能会变得难以理解:-)

祝好运!

Git rebase是对历史的重写.您永远不应该在"公共"的分支上执行此操作(即,您与他人共享的分支).如果有人克隆你的分支,然后你重新分支那个分支 - 那么他们就不能再从你的分支中提取/合并更改 - 他们将不得不抛弃旧分支并重新拉动.

关于使用git打包软件的这篇文章非常值得一读.它更多的是关于管理软件分发,但它非常技术性,并讨论如何使用/管理/共享分支.他们谈论什么时候变革,什么时候拉,以及每个人的各种后果是什么.

简而言之,他们都有自己的位置,但你需要真正理解差异.

git pull如果您有不在远程分支中的提交,则进行合并.git rebase重写您必须相对于远程分支的提示的任何现有提交.它们之间的相似之处在于它们都可能导致冲突,但我认为git rebase如果你可以使用更顺畅的协作.在rebase操作期间,您可以优化提交,使它们看起来像是新应用于远程分支的最新版本.合并可能更适合具有更多历史记录的分支上的更长开发周期.

像git中的大多数其他东西一样,有很多重叠的功能可以适应不同的工作方式.