你应该从 SVN 迁移到 Git 吗？

Send_linux

简而言之，对于新项目来讲，Git是不错的选择，否则，NO！
　　最近整个技术社区都在讨论Git。很多人都推崇Git，说它是多么多么的牛逼，如果你还不从SVN或者CVS迁移到就会被淘汰云云。我并不同意这个观点。我承认Git的设计比SVN要好，但是真的好到让你马上不顾一切的迁移所有的SVN代码库到Git吗？我看来看去，Git真的比SVN强的地方就两点。

1. 分布式的系统
项目的每一个参与者都有完整的代码库和版本树。所以你基本上不可能丢失任何代码。
2. 提交代码更快速
因为你有完整的代码库在你本地，所以提交代码是非常快速的。而且Git在存储上面也比SVN高效，它允许小量数据被来回传输。
所以，如果你常常觉得更新或者提交代码太慢，或者你的SVN服务器没有备份机制，那么你也许应该考虑迁移到SVN，否则没有必要。当然，针对新项目，使用Git将是明智的选择。

不知道大家是怎么看的，欢迎大家讨论！

OwnWaterloo

>> 我看来看去，Git真的比SVN强的地方就两点。

没眼力就别放这种大话
虽然这确实是git比svn强的地方，但根本就没说到关键点上。

分布式强在支持比集中式更多的工作流，而且是很重要的工作流。
分布式版本控制将：
1. 记录仓库某个时刻的状态 —— git commit
2. 仓库变动共享给他人 —— git push
分解，而不是一个不可分离的动作。

能够以更小的粒度记录仓库的状态 —— 想做就做 —— 而无需担心这种临时状态会破坏他人的工作环境。
等到产生一系列满意的变化，意图与他人共享时再共享。
并且在共享这一系列变化之前，还可以修改这一变化的历史，比如：
1. 丢弃一些错误的commit
2. 将一些小commit合并为大commit
3. 将一个大commit分解为若干小commit
...
使之更有逻辑。 注意，这已经是在有意识地丢失一些历史了。 所以"所以你基本上不可能丢失任何代码。"根本就不是git的主要优势。


总之，一个干净清晰的仓库历史是最终结果，但这不是其真正演化的过程。
而svn要么强迫从一开始就想好如何产生这样的历史，要么就干脆不顾放弃干净与清晰的历史。

walleeee

前面kernel被植入后门，快速找到就是靠了git的特征（hash值记录）。

svn和git看需要吧，svn容易入门，git功能或许强大。

chinesedragon

现在 还没有用 版本管理工具

walleeee

回复 4# BetonArmEE


    赞一个

peijue

回复 2# OwnWaterloo


    1. 丢弃一些错误的commit
2. 将一些小commit合并为大commit
3. 将一个大commit分解为若干小commit

请教这个如何能方便的完成， 我也是用git的

OwnWaterloo

回复 4# BetonArmEE

>> 版本库备份：要不然你就手工cp -rf下吧，简单原始即实用

要不然干脆svn也不用，都cp -rf吧，简单原始即实用？

OwnWaterloo

回复 7# peijue

说实话，真要case by case的讲解git怎么用，确实会给人很复杂的感觉。
我是有了一些经验后就看了看git存储的格式，就完全放心的使用git了。
因为，假设我想完成什么功能，却暂时不知道应该用什么命令，甚至git根本就没有提供这种功能，自己写几行脚本就搞定。



先说拆分，需要利用git的暂存区域(staging area/index)。 git commit 只是记录index而非working tree的状态。

假设某个分支的历史是： ... <- A <- B， working tree与B相同。并且想将历史改变为： ... <- A <- C <- D <- B'。
首先用git reset HEAD~ 让index回到A的状态，且working tree保持B的状态。
然后将index改变为C的状态 —— 可以用 git add --patch —— 并提交。
然后将index改变为D的状态，提交；最终将index改变为B'（内容与B相同，只是时间戳不同），提交。



然后是丢弃commit，需要用到cherry-pick的概念。
假设某个分支的历史是： ... <- A <- B <- C <- ...
可以重新构造出一个类似的分支， 首先创建temp分支： git checkout A -b temp。
然后将 A<-B 的变化添加到该分支： git cherry-pick B。此时temp分支： ... <- A <- B'
还可以继续git cherry-pick C，此时temp分支： ... <- A <- B' <- C'。

那么如果想丢弃B引入的变化，只要如上面一样，但略过cherry-pick B就行了。

而连续的cherry-pick，可以用git rebase -i。
比如git rebase -i A，就会提示用户编辑一个文件：
pick B
pick C
pick ...
如果保持不变，git就会创建一个临时分支，然后挨个cherry-pick。

如果想略过B，直接删除那一行然后退出编辑器就行。



合并commit。假设分支历史是： ... <- A <- B <- C <- D ... 打算将BC的变化记录在一个commit中： ... <- A <- BC' <- D' ...
与上面类似，可以新分支上用cherry-pick产生一个类似历史：
git checkout A -b temp
git cherry-pick B
# -----
git cherry-pick -n C  # 只将B<-C的变化应用到index，但并不产生一个commit
git commint --amend ... # 修改最近一个提交
# ------
git cherry-pick D
...

对应到rebase -i的文件：
pick B
pick C
pick D
...
如果想达到git cherry-pick -n 之后 git commit --amend 的目的，可以将对应行的pick改为squash，或者s：
pick B
s C
pick D
...



再说说pick/squash之外的另一个edit。回到拆分提交，假设历史是： ... <- A <- B <- C ... 想改变为 ... <- A <- B0 <- B1 <- B' <- C' ...
可以在新分支上连续的cherry-pick，并且pick B后用上面的add --patch拆分为B0,B1,B'。
也可以rebase -i，并且将pick B 改为 edit B， git就会在pick B之后停止， 用户用add --patch 改为 B0 <- B1 <- B' 后 再 git rebase --continue 继续执行那个文件之后的其他cherry-pick操作。
edit仅仅是告知git停下来， 并不只是为了拆分提交。 停下来之后完全可以就地增加一些新的改动， 然后继续pick后面的改动。




总之，git其实只需要学习很少量的命令，以及仓库格式（很清晰的）；想要的功能就可以做到，大不了自己动手。
之后只是慢慢熟练其他命令，让这些功能实现起来更方便而已。
而不像其他没有公开仓库格式的工具， 想要什么功能却又查不到对应命令的话真的是无能为力。

git仓库的部分格式可以在git pro（有在线英/中版本）后面章节里找到，好像叫git internal。
丢弃、拆分、合并提交的例子这书里也有。