版本控制之道---Git时代已经来到？（获奖名单已公布-2012-10-30）

personball

回复 26# OwnWaterloo


    支持一个，，用过svn的都知道。。。svn的缺点哎

starwing83

回复 43# OwnWaterloo


    我说的不是这个意思………………

我是说，大二的时候，有次写代码，突然想到一个绝妙的主意，然后删了现在的实现（文件里面删代码，不是直接删文件），然后开始做新的实现，结果后来发现新的想法有问题，还是老的能工作，但是代码已经删了，EditPlus保存以后就不能undo，那个悔啊……至此就开始手工版本控制生涯了，遇到要改实现的情况有的没的都拷贝一份foobar_old.c再说……

后来用git就直接本地git init然后commit -a然后开搞了，基本上就跟开挂一样不怕，可以随便瞎搞了。

starwing83

回复 43# OwnWaterloo


    我这已经有胶水了，我就是问问有没有类似的解决方案……好奇而已……没有就算了……

其实我要的就是可以push stash而已……

hebingyue

基本上git和svn都会用到。
公司使用的是git,主要偏向于Linux平台使用，
个人用SVN，在win平台下。

OwnWaterloo

回复 42# starwing83

纳尼？ dracs不是 David's Advanced Revision Control System的意思？
丑陋的女人是怎么来的。。。？


git管理的是含有chronological order的branches。 dracs管理的是sets of patches。

对一个git仓库：

1. 
   
2.             branch0
   
3.      +--- F <- G
   
4.      |
   
5.      v      branch1
   
6. A <- B <- D <- E
   
7.      ^
   
8.      |      branch2
   
9.      +--- H <- I
   

复制代码

对dracs而言， branch0是由 A, B, F, G 这4个patches组成（git实现策略不是changeset而是snapshot）。 branch1, branch2同理。
但dracs可以构建出这样一个状态： 由A, F, G 这3个patches组成。 这很容易， 因为dracs管理的就是set of patches。
你用git实现看看。。。   就得把B从中间抹去。。。  因为git是有chronological order的。


对管理一些极为松散的项目。 比如我本地的一些notes，它们之间的联系很少。
我想抽出里面的若干文件 —— 比如我要把clojure相关的notes单独整理出来 —— 以及它们的记录来组成一个新的仓库（不再包含其他notes）就很容易。
剩余的notes再作为另一个仓库也很容易。

而git，因为它有年代顺序， 就基本是在重写整个仓库了。也就是说git把年代顺序给耦合了。。。
dracs没有，但弄一个出来很容易，给组成状态的那个set增加一个顺序就ok了。 这个仅仅是为了追踪历史而做的，不是dracs必须的。


哪怕就是实际的项目，你用过git cherry-pick 没。。。
从svn -> git来看，这是一个进步。 但从dracs来看， git的cherry-pick就不方便了。
比如上面的图里， branch1 cherry-pick I， 得到 A <- B <- D <- E <- I'。 注意那个'。
branch2就要rebase（呃，这个例子没举好，无论是否cherry-pick， branch2想要合并到branch1都得rebase）。
而dracs直接将那2个patches收进来就完了。。。

所以git项目参与的人多了之后，rebase以保持一个干净的、线性的（没有多parents）的历史就不容易了，太耗人力了。
就倾向于使用merge commit， 树型就树型吧。。。

OwnWaterloo

回复 46# starwing83

stash也是在记录了吧。。。 而且它的commit message肯定不是你想要的。。。  你愿意把这样的commit分享给他人么。。。

shuge_guet

1.团队使用git，但少部分顽固派还在使用svn，个人使用git

选择git无它，就是想怎么搞就怎么搞，不管什么merger branch checkout commit  cherry

starwing83

回复 48# OwnWaterloo


    擦，我就是被你害了！仔细看看你的拼写！darcs不是dracs！！！


svn似乎也是用patches进行管理的。只是做的不好。但是这是无可避免的。我问你。patches最重要的是什么？是历史！至少是单个的前向历史。patches最重要的就是你得知道对谁patch，所以你不可能只保存patch，你必须保存patch和一个指针，说明patch对谁进行！

所以，git明显是做得到的。假设有个历史A->B->C->D，你只需要rebase就能够merge B和C，得到A->C'->D，这个过程和darcs是一样的，即如果要得到A->C‘->D，darcs也必须构建一个新的patchC'，这个patch是patch B和patch C merge得到的，不可能直接对Apatch掉C，很可能会冲突，并且丢掉了B的修改状态。

而且，patch本质上是对snapslot的一个模拟，只是一个实现问题。从这一点讲，保存snapslot和patch没有区别。git的内部对于强相关性的object也是用patch来维护的。这只是一个优化策略，本质上还是snapslot。

所以如果仅仅是你说的这一点，我觉得对git没有优势。git完全可以模拟这种行为，工作量是一样的——注意如果是patch，实际上你操作的仍然是个链表，你仍然需要遍历patch，观察patch的过程，并对patch进行合并，这和rebase的原理是一样的。根本不存在git需要很多工作量而darcs O(1)就能做到。最多只能说darcs对这种应用给予了支持。问题是git同样有支持——rebase，然后commit到一个新的分支，然后clone这个新的分支形成一个repo，完全一样的。

顺便说说push stash，stash有commit message？我怎么不知道？我只要共享一个状态，我不需要这个状态有commit-message。就是说，我本地有一个状态，一些文件add了，另一些modify了没record，我希望共享这个临时状态给别人，别人建立一个新的分支，同样一些文件add了，另一些modify了，就是这样。所谓同步。

wang290

shuge_guet 发表于 2012-10-11 16:32
1.团队使用git，但少部分顽固派还在使用svn，个人使用git

选择git无它，就是想怎么搞就怎么搞，不管什么 ...

这个头像很吊，这个理由也很吊，想怎么搞就怎么搞

shuge_guet

回复 52# wang290

就像搞女人一样，想怎么搞都行。
svn的目录像女人的裹脚布一样，又乱又臭
svn提交记录也相对丑陋，git的看起来就爽点

git的分享也很方便，svn用过一段时间，还不知道怎么弄