我是git的新手，我正在尝试使用它来对抗我的SVN服务器。 我不明白“git svn rebase”得到更新的原因。根据我的理解，如果我使用SVN服务器更新我的本地存储库，提交GIT（本地）我的更改，而不是“git svn rebase”，我可能会覆盖其他用户对我工作的文件的更改。
我理解正确吗？如果我这样做，为什么我要使用rebase并承担这样的风险（我理解快进的想法，但听起来确实有风险）？
希望我不会遗漏一些基本的东西！
答案 0 :(得分：2)
反之亦然：git svn rebase阻止你覆盖他人的工作。正如Git-SCM book恰当地指出的那样，将git svn rebase视为等同于svn update。这是使用SVN服务器更新本地存储库的方式。
...你查看了一个存储库版本（比方说，@ 9001）。您进行了一些更改，并准备提交，但是 - oops-有人检查了更改9002.您svn update修订版9002，必要时合并，然后检查您的更改以生成9003.如果您没有运行svn update，你会覆盖队友的修订版9002;通过运行svn update，您的行为就好像您的工作基于修订版9002而不是9001 。
SVN 9001-------------------------------9002---------------9003--------->
\ \ / svn commit
your feature local work [now update] updated work
...历史记录没有编号和线性。您可以随时在本地提交，并将您的工作合并到您的团队指定“主”分支的任何提交中。
your teammate's feature T1--T2--T3---T4--T5
/ \ merge
master M1------------------M2-------M3------------M4--------M5------------->
\ / merge
your feature Y1-----Y2-----Y3--Y4
我已将Y1 Y2 Y3 Y4标记为您的功能工作的本地提交，所有这些都基于您检出 M3 的世界状态。所有这些历史都是公开的，所以如果你像上面那样提交，你的队友可以告诉你基于Y1的M3。如果您想更改，您可以要求git将您的功能工作基于M4。这就是所谓的 git rebase 。
your teammate's feature T1--T2--T3---T4--T5
/ \ merge
master M1------------------M2-------M3------------M4----------------M5----->
\ / merge
your feature after rebase Y1--Y2--Y3--Y4
在rebase之后，所有提交ID（哈希）都会发生变化，因为它们是根据您提交的父级计算的，并且通过重新定位您故意更改父级。
...你需要将git的提交图映射到svn的线性历史。这意味着在您提交之前运行svn update（git svn rebase），以使您的工作基于SVN存储库中的最新修订。
SVN 9001-------------------------------9002----------------9003--------->
\ \ / git svn dcommit
your feature Y1--Y2--Y3--Y4 [now rebase] Y1--Y2--Y3--Y4
有关更多说明和示例，请参阅Git-SCM chapter on SVN。