g*****1
发帖数: 173 | 1 原帖地址：http://www.mitbbs.com/article_t1/JobHunting/32723821_0_6.html
没想到这个帖子这么火。由于本人工作的公司最近也在考虑CVS转到git，我也负责写了
一些相关的文档。在写文档的过程中也仔细考虑过一些帖子里讨论的问题，因为毕竟要
说服一个用了CVS 10几年的人转到Git并不是一件容易的事情。所以在此也谈谈个人的
看法。
个人认为帖子里很多人的观点还集中在版本控制本身的功能身上，其实，在这点上几乎
所有的版本控制工具功能都是大同小异的，无外乎checkout, branch, merge, tag,
commit之类。而大多数人都忽略的是不同的版本控制工具带来的工作流（work flow）
上的变化。
想必很多人都用过Centralized的版本控制工具，和你们一样我也是从SVN和CVS起步的
。我觉得这类VCS最大的问题是branching 和merging，当时我们的project都是尽量避
免这些操作。而且我们每天也commit有限的次数（每天下班之前我们头总会提醒我们
commit 当天的code），这样导致的一个直接问题是很多中间版本的丢失。比如如果我
们发现commit的code有问题（有人说commit之前local test呀，可是别忘了我们不是一
个人在战斗！代码只有集合到一起才能test的啊！），怎么办？？这是很让人头痛的问
题。相对于centralized的VCS，git带来最大的变化就是使得branching和merging变得
非常非常简单和cheap。而且由于是版本树就在本地，对server也没有什么影响，其实
说到底，git带来的最大的变化不是它增加了什么新的功能，而是这种对branching和
merging等操作的改进直接导致版本控制工作流的变化。比如我们可以随时随便随地
commit，branch和merge而不用考虑别人和server的感受。不同branch甚至commit/tag
之间的切换我认为是最惬意的事情了！当然，如果你说CVS和SVN也可以做到，我还是真
诚地希望你比较一下他们之间的差异再做评论。
后记：IT是当下更新换代最快的行业，这要求我们用open的眼光来看待新的技术，否则
我们很快就out了，你觉得呢？ |
g*****1
发帖数: 173 | |
R******9
发帖数: 267 | 3 太赞了，正想学习这方面的
【在 g*****1 的大作中提到】
: 另外推荐大家看看这个关于git work flow的帖子：http://nvie.com/posts/a-successful-git-branching-model/
|
m********e
发帖数: 118 | |
Y******u
发帖数: 1912 | 5 非IT公司，从cvs转git，算上gitlab，工作效率提高一倍有余吧 |
p**********e
发帖数: 316 | 6 所有的工具都是大同小异，只是这个不太好用，那个更好用的问题。作为developer，
你就只管checkin, checkout就行了， 其他的功能偶尔用一下而已
【在 g*****1 的大作中提到】
: 原帖地址：http://www.mitbbs.com/article_t1/JobHunting/32723821_0_6.html
: 没想到这个帖子这么火。由于本人工作的公司最近也在考虑CVS转到git，我也负责写了
: 一些相关的文档。在写文档的过程中也仔细考虑过一些帖子里讨论的问题，因为毕竟要
: 说服一个用了CVS 10几年的人转到Git并不是一件容易的事情。所以在此也谈谈个人的
: 看法。
: 个人认为帖子里很多人的观点还集中在版本控制本身的功能身上，其实，在这点上几乎
: 所有的版本控制工具功能都是大同小异的，无外乎checkout, branch, merge, tag,
: commit之类。而大多数人都忽略的是不同的版本控制工具带来的工作流（work flow）
: 上的变化。
: 想必很多人都用过Centralized的版本控制工具，和你们一样我也是从SVN和CVS起步的
|
z****t
发帖数: 63 | 7 难变的是习惯不是工具
【在 g*****1 的大作中提到】
: 原帖地址：http://www.mitbbs.com/article_t1/JobHunting/32723821_0_6.html
: 没想到这个帖子这么火。由于本人工作的公司最近也在考虑CVS转到git，我也负责写了
: 一些相关的文档。在写文档的过程中也仔细考虑过一些帖子里讨论的问题，因为毕竟要
: 说服一个用了CVS 10几年的人转到Git并不是一件容易的事情。所以在此也谈谈个人的
: 看法。
: 个人认为帖子里很多人的观点还集中在版本控制本身的功能身上，其实，在这点上几乎
: 所有的版本控制工具功能都是大同小异的，无外乎checkout, branch, merge, tag,
: commit之类。而大多数人都忽略的是不同的版本控制工具带来的工作流（work flow）
: 上的变化。
: 想必很多人都用过Centralized的版本控制工具，和你们一样我也是从SVN和CVS起步的
|
f******n
发帖数: 314 | 8 git直接把svn秒成渣。不会用git的代表不愿意学习，知识落伍，直接不需要给面试机
会 |
a*****0
发帖数: 6788 | 9 一直用SVN和TFS，最近用上Git，虽然还不熟觉得这种open source东下载个东西西下载
个东西拼起来很麻烦，不过发现DVCS的概念果然好。其实原来TFS里的shelfing已经有
这个意思了，但还是在server上。 TFS2013也有local repository和local commit,
但俺觉得too little, too late. MSFT还是直接package Git,把TFS的ticketing部分和
client integration做好就是了。 Source control这部分就算了吧。 |
l******t
发帖数: 55733 | |
|
|
k*******p
发帖数: 219 | 11 接触git很久了，入门的时候有点头大，用了这么久其实99%的时候用的以下的命令，
git commit --amend 把当前added 但没commit的内容贴到上个commit里
git rebase -i HEAD^ #N 这个是特别有用的命令，对当前N个commit进行Squash skip
edit等操作整合
git rebase --interactive #commit sha1 跳跃到以前的某个commit进行修改
git branch 创建local新的branch
git reset HEAD^ 这个我很喜欢， 就是把最当前的commit 解散
git checkout -b #remote branch name， checkout branch 到本地
git tag 每次release 最好tag起来以方便随后refer
git reflog 这个是最救命的命令。它显示所有commit过的记录，就算不小心删除了个
branch或者amend 或者rebase搞混乱了，照样可以从这个命令里找到以前的commit id
从而cherry pick 回来
git cherry-pick 把版本库里某个commit给抓过来到当前
git stash 存放未commit的内容
git format-patch 偶尔需要线下share某个commit 给别人可以做个patch 发给别人，
不过大多时候发remote branch， 然后cherry-pick 这个commit可以替代之。
另外一个非常重要的原则就是always commit，因为commit的东西误删除的时候总能再
找回来
这是我的2 cents，不对之处请指正。
至于git和svn哪个好呢，不同人有不同需求吧，对于我个人恐怕是回不到svn了。 |
A*****i
发帖数: 3587 | 12 git rebase -i HEAD^ #N 这个是特别有用的命令，对当前N个commit进行Squash skip
edit等操作整合
对于这个我们一般不用rebase很容易出错，应为squash之后要和master force merge稍
有不慎就会把master毁了
我们的做法是
git reset
git stash
git merge --ff
git stash apply
git commit
git push -f |
C******8
发帖数: 501 | 13 写的挺好，不过有点雷声大雨点小 ，没几行就后记了。。。
【在 g*****1 的大作中提到】
: 原帖地址：http://www.mitbbs.com/article_t1/JobHunting/32723821_0_6.html
: 没想到这个帖子这么火。由于本人工作的公司最近也在考虑CVS转到git，我也负责写了
: 一些相关的文档。在写文档的过程中也仔细考虑过一些帖子里讨论的问题，因为毕竟要
: 说服一个用了CVS 10几年的人转到Git并不是一件容易的事情。所以在此也谈谈个人的
: 看法。
: 个人认为帖子里很多人的观点还集中在版本控制本身的功能身上，其实，在这点上几乎
: 所有的版本控制工具功能都是大同小异的，无外乎checkout, branch, merge, tag,
: commit之类。而大多数人都忽略的是不同的版本控制工具带来的工作流（work flow）
: 上的变化。
: 想必很多人都用过Centralized的版本控制工具，和你们一样我也是从SVN和CVS起步的
|
q*c
发帖数: 9453 | 14 开什么玩笑，世界上哪里来的 silver bullet. 提高一倍效率，抽大麻呢，呵呵。
git 的 push 就等于别人的 chck in. 楼主那种直接 work on master 本来就不对。
你自己开个 feature branch 想 check in, comit 多频繁都可以。
多人协调，最后的 merge, conflict 各种系统面临完全一样的问题，理论上只能手动
，没有别的办法， 这是物质守恒定律保证的。
【在 Y******u 的大作中提到】
: 非IT公司，从cvs转git，算上gitlab，工作效率提高一倍有余吧
|
q*c
发帖数: 9453 | 15 这两个我用的都很熟，你太搞笑，武断，狭隘了。
【在 f******n 的大作中提到】
: git直接把svn秒成渣。不会用git的代表不愿意学习，知识落伍，直接不需要给面试机
: 会
|
l*****s
发帖数: 672 | 16 git还是有大问题的，就是module的问题,不知道这个sparse checkout
是不是能够部分实现这个问题了。
git的优势在integrity带来的种种好处，缺点也在integrity带来的module
共享的局限性。
如果真要选的话，还是会选择git.
不过现在用perforce |
l*****s
发帖数: 672 | 17 另外一个关于git的问题，不知道是不是个实际问题，大家都在local的repo干活，
最后测试没有问题后提交给remote，这个导致以后remote的check in 太大块，
这样历史纪录就会差很多。我是比较喜欢那种一点一点check in的。 |
z****e
发帖数: 54598 | 18 cvs还是不要拿出来当例子了
真的是不行，不是一个时代的
我对git没有太多偏见，快是好事
但是动不动就有人说git能提高开发效率几倍
这就是纯粹扯蛋了，能提高10％就不错了
除非你告诉大多数时间你都在搞vcs这种扯蛋的事
工作中除了写代码，看代码，测试，debug
真正用在vcs上的时间，都不应该太多
以前主要是code base太大，所以经常导致co太慢
半个小时甚至半天才co完成，然后无数的conflicts，主要是lib的order导致的
然后被这种东西折磨得晕过去，主要常见于各种legacy code/system
对付这种也不仅仅是只能通过改良vcs就可以搞定的
很多时候依赖的是maven/gradle这种类库管理工具，而非vcs
这就是那个id说的本意，同时他也强调了对模块提高内聚和减少耦合
这都是软件工程的核心思想，只要做到了这两步
其实你不用git也不会有什么太大问题，因为这两步把codebase减小
并干掉各种dependency，这样co自然就快了
以前要co所有的prj，现在只要co一个module就好了，这样就快了
从构架层面思考，这无疑是正确的而且应该这么做
wwzz他们说的是另外一种情况，就是假设每次都co整个prj
那么git可以在短时间内co整个prj出来，而svn因为codebase会随着分支增加而增加
所以co整个prj出来会比较慢，这个时候用git就会有好处，简单说就快
但是从整体结构上说，你把整个公司所有的code让一个程序员全部co出来
会不会有问题，那这个很难说的，南翔技校为啥出名？
还不就是google说tg有个内奸偷了内部代码么
那还不是自身政策就允许的？这种情况就不会发生在上一种情况中
上一种情况所有modules之间都是割裂隔绝的，安全性就要强一点
搞it的原教旨主义者太多，vcs这种东西甚至it核心都算不上
面试谁问这个？从来没遇到过，不懂找着抄一下就懂了
又不是什么火星科技 |
l*****s
发帖数: 672 | |
o*******0
发帖数: 699 | |
|
|
k********4
发帖数: 858 | 21
顶，程序架构最重要，其他都tm扯淡
【在 z****e 的大作中提到】
: cvs还是不要拿出来当例子了
: 真的是不行，不是一个时代的
: 我对git没有太多偏见，快是好事
: 但是动不动就有人说git能提高开发效率几倍
: 这就是纯粹扯蛋了，能提高10％就不错了
: 除非你告诉大多数时间你都在搞vcs这种扯蛋的事
: 工作中除了写代码，看代码，测试，debug
: 真正用在vcs上的时间，都不应该太多
: 以前主要是code base太大，所以经常导致co太慢
: 半个小时甚至半天才co完成，然后无数的conflicts，主要是lib的order导致的
|
z*****m
发帖数: 119 | 22 单一项目的，不做continuous delivery的，SVN足够了。多项目持续集成的，没有Git
还真的很痛苦。基本上没法保证trunk的稳定。 |
h********o
发帖数: 484 | 23 git提高生产效率n倍，扯。刚接触是我看是降效率。git有learner curve，尤其svn用
惯了。
其实基本大伙都能干，高级阶段是对source code management strategy的理解, 这个
理解透了，svn都能解决，只是有时不如git方便。 |
g*****g
发帖数: 34805 | 24 There's no holy grail, but git is a big improvement over SVN, period. |
g***l
发帖数: 2753 | 25 同意这个。我是个人，开源的用git，主要是branch方便。公司里面用perforce。
perforce主要是不支持local branch，但是有个shelve的功能非常方便。 对于有冲突
的merge，还是perforce好用，git的gui界面太烂了，更不用提命令行的merge了。
【在 q*c 的大作中提到】
: 开什么玩笑，世界上哪里来的 silver bullet. 提高一倍效率，抽大麻呢，呵呵。
: git 的 push 就等于别人的 chck in. 楼主那种直接 work on master 本来就不对。
: 你自己开个 feature branch 想 check in, comit 多频繁都可以。
: 多人协调，最后的 merge, conflict 各种系统面临完全一样的问题，理论上只能手动
: ，没有别的办法， 这是物质守恒定律保证的。
|
t****d
发帖数: 488 | 26 我觉得git的却比较好，只不过呢对于很多人，比较懒，难得改习惯。毕竟csv已经用习
惯了，而git呢还需要花上好几个小时去学一下。比如我就是因为懒了这几个小时过了
几个月才真正的转成git的。 |
i********e
发帖数: 546 | |
h*******t
发帖数: 2679 | 28 你连merge和diff都没提。这是git的强项。
你说的这些都跟svn差不多。
git和svn非常大的区别是工作流程不同。
要分清
master,
development,
feature branches,
hot fix branches.
git主要还是learning curve。我被赵策他们公司去年逼着从svn换到git，也头大了好
几个月，刚开始用git的时候，总有种便秘的感觉。习惯了git后，反而觉得svn没意思
。git还是要用命令行更方便。
skip
【在 k*******p 的大作中提到】
: 接触git很久了，入门的时候有点头大，用了这么久其实99%的时候用的以下的命令，
: git commit --amend 把当前added 但没commit的内容贴到上个commit里
: git rebase -i HEAD^ #N 这个是特别有用的命令，对当前N个commit进行Squash skip
: edit等操作整合
: git rebase --interactive #commit sha1 跳跃到以前的某个commit进行修改
: git branch 创建local新的branch
: git reset HEAD^ 这个我很喜欢， 就是把最当前的commit 解散
: git checkout -b #remote branch name， checkout branch 到本地
: git tag 每次release 最好tag起来以方便随后refer
: git reflog 这个是最救命的命令。它显示所有commit过的记录，就算不小心删除了个
|
h*******t
发帖数: 2679 | 29 TFS太烂。跟SS一个档次的。
一个主要运行在服务器上的软件，对客户端的兼容跟shi一样。
【在 a*****0 的大作中提到】
: 一直用SVN和TFS，最近用上Git，虽然还不熟觉得这种open source东下载个东西西下载
: 个东西拼起来很麻烦，不过发现DVCS的概念果然好。其实原来TFS里的shelfing已经有
: 这个意思了，但还是在server上。 TFS2013也有local repository和local commit,
: 但俺觉得too little, too late. MSFT还是直接package Git,把TFS的ticketing部分和
: client integration做好就是了。 Source control这部分就算了吧。
|
h*******t
发帖数: 2679 | 30 "git mergetool"
【在 g***l 的大作中提到】
: 同意这个。我是个人，开源的用git，主要是branch方便。公司里面用perforce。
: perforce主要是不支持local branch，但是有个shelve的功能非常方便。 对于有冲突
: 的merge，还是perforce好用，git的gui界面太烂了，更不用提命令行的merge了。
|
|
|
C*****n
发帖数: 1049 | 31 windows下装个tortoisegit、linux下装个rabbitvcs保管傻瓜也能入门。人家写小说的
都开始用git了。 |
A*****i
发帖数: 3587 | 32 赵策公司是啥？那个做jira的？
【在 h*******t 的大作中提到】
: 你连merge和diff都没提。这是git的强项。
: 你说的这些都跟svn差不多。
: git和svn非常大的区别是工作流程不同。
: 要分清
: master,
: development,
: feature branches,
: hot fix branches.
: git主要还是learning curve。我被赵策他们公司去年逼着从svn换到git，也头大了好
: 几个月，刚开始用git的时候，总有种便秘的感觉。习惯了git后，反而觉得svn没意思
|
g******o
发帖数: 109 | 33 可以用sourceTree做git的GUI客户端，管理起来很方便。GIT还是很快的，我碰到的git
最大的问题就是创建了太多的feature branch,一些branch修改相同的文件，最后导致
conflicts.
再有就是每个developer都是在自己的branch工作的，他修改了database的一些东西，
但又不能立刻pull request他的branch code到master, 但恰好他database的改动又影
响了你了，这阵估计就郁闷了 |
d***s
发帖数: 1062 | |
