m*****a
发帖数: 1203 | 1 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
能用shell版本，不能用gui的
然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
有一本书！！！！
靠 |
G***o
发帖数: 5158 | |
z****e
发帖数: 54598 | 3 是，码农的东西大部分就这么难用
我能想到不需要training就能上手的估计只有clear case了
但是要钱
不只version control有书
连html这种玩意都有书，vb也有
是很搞笑 |
r******l
发帖数: 10760 | 4 git是最常见的吧？
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
V*********r
发帖数: 666 | 5 是《Pro Git》吗？你别说，你要从来没用过git，还真得读一遍
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
j******8
发帖数: 746 | |
m*****a
发帖数: 1203 | 7 那些大软件公司都用啥啊？也蛋疼的用git。。？
【在 r******l 的大作中提到】
: git是最常见的吧？
|
V*********r
发帖数: 666 | 8
syntax 设计上 mercurial 更合理一些，但架不住用git的人和厂子多
开发机用mac或linux的厂子一般都倾向用git
很多厂买github企业版，集成Jenkins做integration test，
push上去直接build，非常方便
【在 m*****a 的大作中提到】
: 那些大软件公司都用啥啊？也蛋疼的用git。。？
|
g*****g
发帖数: 34805 | 9 egit大部分命令都有。
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
f*****e
发帖数: 2992 | 10 git很牛的，其实就是一个分布式系统，如果能用好它，又能知道他内部原理就牛逼了。
SVN之类的branching is painful。GIT merge/branch和玩似的。
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
|
|
r****s
发帖数: 1025 | 11 我两个都用过，没看出区别，一个管source的文件系统不知道有什么必要分布式，从来
没见过哪个公司疯狂check in每秒上千次。
branching就是扯淡，所谓的branching在后台就是原样copy一个文件夹，这尼玛也开始
高大上了？branching 要小心，merge的时候就是pita.
merging就更扯淡了，conflict resolving还是得靠人一行一行地做，和SVN没有区别。
凡是觉得git和svn有区别的都是菜鸟。软件这行菜鸟占90%以上，所以git用的人比较多
。
我老现在用的是svn，组里有傻逼说要转git，说提高效率，被否了。还真没听说过软件
开发卡在check in的效率上。
了。
【在 f*****e 的大作中提到】
: git很牛的，其实就是一个分布式系统，如果能用好它，又能知道他内部原理就牛逼了。
: SVN之类的branching is painful。GIT merge/branch和玩似的。
|
z****e
发帖数: 54598 | 12 cvs
clear case
svn
mercurial tortoise
git 主要是github
我居然都用过
还是觉得cc最好用，版本树很直观清晰，也最贵，其他都是免费的
cvs最烂，能不用就不用
svn感觉不错，我也感觉比git好用，连猜带蒙都搞得八九不离十
git我做不到这样，需要google
mercurial很乡土，一开始折腾了下
我上手时间从短到长顺序排名是
cc
svn
mercurial
git
cvs |
z****e
发帖数: 54598 | 13 用gui的话，只用过cc和mercurial
但是cc那个gui比mercurial好用不少
如果再弄上clear quest
整套流程你不需要培训就能上手
cvs，svn和git都是command line
svn的命令我都是猜的，居然八九不离十
git命令我猜总猜错，所以不得不google
cvs是应该被淘汰的东西 |
c*******y
发帖数: 98 | |
z****e
发帖数: 54598 | 15 cvs连个eclipse plugin都不太好找
软件版本已经几乎停止更新了
最初的设计也有很多问题，移动文件很不方便
能用其他的都应该无脑用其他的
cvs除非是legacy system否则没有必要用 |
y***n
发帖数: 1594 | 16 做天还有哥们提到SourceSafe,更远古的东西。。 |
h********3
发帖数: 2075 | 17 外行人看东西都会觉得那些东西很简单，不值得一提，不需要学习，上手就会。
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
s******c
发帖数: 1920 | 18 等code review的时候branching
review完了再rebase
git这个还是很方便的
【在 r****s 的大作中提到】
: 我两个都用过，没看出区别，一个管source的文件系统不知道有什么必要分布式，从来
: 没见过哪个公司疯狂check in每秒上千次。
: branching就是扯淡，所谓的branching在后台就是原样copy一个文件夹，这尼玛也开始
: 高大上了？branching 要小心，merge的时候就是pita.
: merging就更扯淡了，conflict resolving还是得靠人一行一行地做，和SVN没有区别。
: 凡是觉得git和svn有区别的都是菜鸟。软件这行菜鸟占90%以上，所以git用的人比较多
: 。
: 我老现在用的是svn，组里有傻逼说要转git，说提高效率，被否了。还真没听说过软件
: 开发卡在check in的效率上。
:
|
s******c
发帖数: 1920 | 19 git的命令设计的有点儿拧巴，linus设计的，没办法
【在 z****e 的大作中提到】
: 用gui的话，只用过cc和mercurial
: 但是cc那个gui比mercurial好用不少
: 如果再弄上clear quest
: 整套流程你不需要培训就能上手
: cvs，svn和git都是command line
: svn的命令我都是猜的，居然八九不离十
: git命令我猜总猜错，所以不得不google
: cvs是应该被淘汰的东西
|
g*****g
发帖数: 34805 | 20 区别当然是有的，我们就几百个developer，perforce都经常很慢，git就不会有这个问
题。git的branch当然不是简单拷贝。你这连git的原理都没整明白就出来扯了。
【在 r****s 的大作中提到】
: 我两个都用过，没看出区别，一个管source的文件系统不知道有什么必要分布式，从来
: 没见过哪个公司疯狂check in每秒上千次。
: branching就是扯淡，所谓的branching在后台就是原样copy一个文件夹，这尼玛也开始
: 高大上了？branching 要小心，merge的时候就是pita.
: merging就更扯淡了，conflict resolving还是得靠人一行一行地做，和SVN没有区别。
: 凡是觉得git和svn有区别的都是菜鸟。软件这行菜鸟占90%以上，所以git用的人比较多
: 。
: 我老现在用的是svn，组里有傻逼说要转git，说提高效率，被否了。还真没听说过软件
: 开发卡在check in的效率上。
:
|
|
|
r**********g
发帖数: 22734 | |
r****s
发帖数: 1025 | 22 我靠，真还有公司卡在source code management上，开了眼了，这真开了眼了。
你们公司也比较奇芭哈，居然有几百人同时checkin到一个source code system，而且
还用的perforce - 不敢还是不会用SVN?
思路正常一点的公司，每个dev team不会超过10-15个人，team和team之间绝对绝对不
可以共用一个SVN source，比如A team 不可以checkin checkout B team的code。各
team之间用的是对方的prod build jar。
随之而来的就是每个team自己有自己的svn server,怎么会慢？你们公司难道每次build
都把几百人的checkin 全部build一遍？我靠这架构，牛逼了。
也许是你们公司只有一个perforce license? 要不多买几个呗？
总之，你们那肯定有搞拧了的地方，我老纵横码工界数年，还未尝见过哪个公司（即使
是很小的startup)被source control击倒的，贵公司是头一号。
另外你要知道我谈的是svn vs. git，svn tag/branch就是文件夹拷贝。perforce按你
的用户体验肯定搞错了什么地方，我不知道perforce错在什么地方，也许就是branch没
有用的copy？
【在 g*****g 的大作中提到】
: 区别当然是有的，我们就几百个developer，perforce都经常很慢，git就不会有这个问
: 题。git的branch当然不是简单拷贝。你这连git的原理都没整明白就出来扯了。
|
g*****g
发帖数: 34805 | 23 你跟我老装逼有用吗？git的branch不是拷贝，更像一个tag，你连基本概念都错了，还
跟我装到底。
我们整个公司就一个产品，文化又比较开放，自然允许team直接互相check in, check
out，无非需要过一下code review. 多个perforce不是不行，但是没有stash和github
这样的高一层组织架构，不利于
合作。一个perforce是退而求其次的办法。自然性能有问题，自然要往git上转。
perforce都不行，svn比perforce更慢。
分布式自然有分布式的理由，只有像你这样所有代码都由一个team完全控制，没有分布
式的需求，team又小的时候，才会觉得别人是奇葩。一句话，少见多怪。
build
【在 r****s 的大作中提到】
: 我靠，真还有公司卡在source code management上，开了眼了，这真开了眼了。
: 你们公司也比较奇芭哈，居然有几百人同时checkin到一个source code system，而且
: 还用的perforce - 不敢还是不会用SVN?
: 思路正常一点的公司，每个dev team不会超过10-15个人，team和team之间绝对绝对不
: 可以共用一个SVN source，比如A team 不可以checkin checkout B team的code。各
: team之间用的是对方的prod build jar。
: 随之而来的就是每个team自己有自己的svn server,怎么会慢？你们公司难道每次build
: 都把几百人的checkin 全部build一遍？我靠这架构，牛逼了。
: 也许是你们公司只有一个perforce license? 要不多买几个呗？
: 总之，你们那肯定有搞拧了的地方，我老纵横码工界数年，还未尝见过哪个公司（即使
|
V*********r
发帖数: 666 | 24 svn开分支的时候拷文件夹，这正是他的原罪，merge的时候无比痛苦
git的commits是对整个项目的整体快照（准确的说是指向一个快照树的指针），
而一个分支只是一个可移动的指向某个commit的指针而已，轻松merge/rebase
101都没搞清楚就来批判也太贻笑大方了
build
【在 r****s 的大作中提到】
: 我靠，真还有公司卡在source code management上，开了眼了，这真开了眼了。
: 你们公司也比较奇芭哈，居然有几百人同时checkin到一个source code system，而且
: 还用的perforce - 不敢还是不会用SVN?
: 思路正常一点的公司，每个dev team不会超过10-15个人，team和team之间绝对绝对不
: 可以共用一个SVN source，比如A team 不可以checkin checkout B team的code。各
: team之间用的是对方的prod build jar。
: 随之而来的就是每个team自己有自己的svn server,怎么会慢？你们公司难道每次build
: 都把几百人的checkin 全部build一遍？我靠这架构，牛逼了。
: 也许是你们公司只有一个perforce license? 要不多买几个呗？
: 总之，你们那肯定有搞拧了的地方，我老纵横码工界数年，还未尝见过哪个公司（即使
|
s******c
发帖数: 1920 | 25 Google几万人还有fb几千人都用一个版本控制 往一同个src tree里commit代码的。
其实这样好处很多，可以随时看到和搜索整个源码库，看别人怎么写怎么调用一些库，
很有效
build
【在 r****s 的大作中提到】
: 我靠，真还有公司卡在source code management上，开了眼了，这真开了眼了。
: 你们公司也比较奇芭哈，居然有几百人同时checkin到一个source code system，而且
: 还用的perforce - 不敢还是不会用SVN?
: 思路正常一点的公司，每个dev team不会超过10-15个人，team和team之间绝对绝对不
: 可以共用一个SVN source，比如A team 不可以checkin checkout B team的code。各
: team之间用的是对方的prod build jar。
: 随之而来的就是每个team自己有自己的svn server,怎么会慢？你们公司难道每次build
: 都把几百人的checkin 全部build一遍？我靠这架构，牛逼了。
: 也许是你们公司只有一个perforce license? 要不多买几个呗？
: 总之，你们那肯定有搞拧了的地方，我老纵横码工界数年，还未尝见过哪个公司（即使
|
w**z
发帖数: 8232 | 26 Re 这个，以前 svn checkout 一个branch, 喝杯咖啡的时间都搞不定，现在一眨眼就
搞好了。local 随便branch,很方便 。
【在 V*********r 的大作中提到】
: svn开分支的时候拷文件夹，这正是他的原罪，merge的时候无比痛苦
: git的commits是对整个项目的整体快照（准确的说是指向一个快照树的指针），
: 而一个分支只是一个可移动的指向某个commit的指针而已，轻松merge/rebase
: 101都没搞清楚就来批判也太贻笑大方了
:
: build
|
l*****3
发帖数: 50 | 27
严重同意！最恨的就是 clear case。
★ 发自iPhone App: ChineseWeb 8.6
【在 j******8 的大作中提到】
: Clear Case 是最难用的，没有之一。
|
r****s
发帖数: 1025 | 28 我还真没遇到过A team往B team里check in code的情况，即使是bug fix,也是提交
delta,由B team的人自己check in。贵公司实在是行为艺术。
A team当然可以随时看B team的code，即使是另一个SVN server (千万不要说没法做到
），但是永远是read only,绝对不可以随意check in。
check
github
【在 g*****g 的大作中提到】
: 你跟我老装逼有用吗？git的branch不是拷贝，更像一个tag，你连基本概念都错了，还
: 跟我装到底。
: 我们整个公司就一个产品，文化又比较开放，自然允许team直接互相check in, check
: out，无非需要过一下code review. 多个perforce不是不行，但是没有stash和github
: 这样的高一层组织架构，不利于
: 合作。一个perforce是退而求其次的办法。自然性能有问题，自然要往git上转。
: perforce都不行，svn比perforce更慢。
: 分布式自然有分布式的理由，只有像你这样所有代码都由一个team完全控制，没有分布
: 式的需求，team又小的时候，才会觉得别人是奇葩。一句话，少见多怪。
:
|
r****s
发帖数: 1025 | 29 看来你们都在同一个公司，这个架构真是神奇哈。我靠，码工的大部分时间是在check
in/check out code,你们不花时间写code吗？
居然没人complain或者稍微思考一下，为什么需要这么多的时间？一个source code
branch一般不超过几十M，network speed基本上是100Gbit，为什么读一个文件会需要
半小时？
完全，完全的不可思议。
而且还随便branch。。。那不是神经病吗？branch根本不费什么时间，merging code
到main/trunk 才费时间。遇到conflict, svn/git都要手动一行一行地核对，你以为随
意branch之后，git可以帮你自动地擦那一屁股的屎？一看就是没正经干过活的。正经
干活的人最怕的就是merge code。
不要对git有不切实际的性幻想。那jb玩意就是个toy。
其实这尼玛就根本没有吵的必要，自己搭个svn/git服务器，看看速度就可以了。凡是
说git有革命性改变的，都是傻逼，没正经干过活。
【在 w**z 的大作中提到】
: Re 这个，以前 svn checkout 一个branch, 喝杯咖啡的时间都搞不定，现在一眨眼就
: 搞好了。local 随便branch,很方便 。
|
r****s
发帖数: 1025 | 30 我靠，你都不知道merge是啥吧？
SVN merge， 如果没有conflict，几秒钟的事，我老还真来不及感觉痛苦。
git merge，如果有conflict,你点亮一下我老，如何自动merge? 那还不得一行一行地
人工对程序，搞不好还得叫过来TPM核对biz logic,merge之后还得再来一轮code
review才行。
还尼玛轻松merge。扯鸡巴蛋。
【在 V*********r 的大作中提到】
: svn开分支的时候拷文件夹，这正是他的原罪，merge的时候无比痛苦
: git的commits是对整个项目的整体快照（准确的说是指向一个快照树的指针），
: 而一个分支只是一个可移动的指向某个commit的指针而已，轻松merge/rebase
: 101都没搞清楚就来批判也太贻笑大方了
:
: build
|
|
|
w**z
发帖数: 8232 | 31 原来全世界都傻逼，就你最聪明？
check
【在 r****s 的大作中提到】
: 看来你们都在同一个公司，这个架构真是神奇哈。我靠，码工的大部分时间是在check
: in/check out code,你们不花时间写code吗？
: 居然没人complain或者稍微思考一下，为什么需要这么多的时间？一个source code
: branch一般不超过几十M，network speed基本上是100Gbit，为什么读一个文件会需要
: 半小时？
: 完全，完全的不可思议。
: 而且还随便branch。。。那不是神经病吗？branch根本不费什么时间，merging code
: 到main/trunk 才费时间。遇到conflict, svn/git都要手动一行一行地核对，你以为随
: 意branch之后，git可以帮你自动地擦那一屁股的屎？一看就是没正经干过活的。正经
: 干活的人最怕的就是merge code。
|
z****e
发帖数: 54598 | 32 都激动了，消消火
他说的其实也没有错
分布式事务处理，一个比较经典的反例就是version control的时候
出现了conflicts，不宜用自动化处理，一般分布式事务主要用来对付data
大多数时候，代码管理能分就分了，大牛你当年在o的时候
肯定也是这样，不过现在startup了，所以自由度变大了也正常
时代在变，适用的环境也不一样，不能说哪个一定是错的
【在 w**z 的大作中提到】
: 原来全世界都傻逼，就你最聪明？
:
: check
|
z****e
发帖数: 54598 | 33 不，他们不在一个公司，但是他们都是startup文化，这个倒是真的
startup很多公司，对于一般正规大公司来说
可能规模也就是一个部门不到而已
check
【在 r****s 的大作中提到】
: 看来你们都在同一个公司，这个架构真是神奇哈。我靠，码工的大部分时间是在check
: in/check out code,你们不花时间写code吗？
: 居然没人complain或者稍微思考一下，为什么需要这么多的时间？一个source code
: branch一般不超过几十M，network speed基本上是100Gbit，为什么读一个文件会需要
: 半小时？
: 完全，完全的不可思议。
: 而且还随便branch。。。那不是神经病吗？branch根本不费什么时间，merging code
: 到main/trunk 才费时间。遇到conflict, svn/git都要手动一行一行地核对，你以为随
: 意branch之后，git可以帮你自动地擦那一屁股的屎？一看就是没正经干过活的。正经
: 干活的人最怕的就是merge code。
|
w**z
发帖数: 8232 | 34 Svn 是每个file 单独下载，所以慢。 Git 整个repo 一起下载。 当然速度快很多。
你肯定你知道 svn co 是干什么的？
check
【在 r****s 的大作中提到】
: 看来你们都在同一个公司，这个架构真是神奇哈。我靠，码工的大部分时间是在check
: in/check out code,你们不花时间写code吗？
: 居然没人complain或者稍微思考一下，为什么需要这么多的时间？一个source code
: branch一般不超过几十M，network speed基本上是100Gbit，为什么读一个文件会需要
: 半小时？
: 完全，完全的不可思议。
: 而且还随便branch。。。那不是神经病吗？branch根本不费什么时间，merging code
: 到main/trunk 才费时间。遇到conflict, svn/git都要手动一行一行地核对，你以为随
: 意branch之后，git可以帮你自动地擦那一屁股的屎？一看就是没正经干过活的。正经
: 干活的人最怕的就是merge code。
|
z****e
发帖数: 54598 | 35 这个例子不是特别好，严格说来，不应该看源代码学习的
这个严重违背软件工程最基本的规范
最早都认为应该看文档，然后搞出了一堆规范，一堆阿三往里面灌水
后来发现，coding monkeys都不愿意写文档，这些规范几乎没用
目前最有效的文档是javadoc，至少我能看javadoc就看javadoc
除非万不得已，不看源代码，而且要搜索源代码，一般通过ide完成
【在 s******c 的大作中提到】
: Google几万人还有fb几千人都用一个版本控制 往一同个src tree里commit代码的。
: 其实这样好处很多，可以随时看到和搜索整个源码库，看别人怎么写怎么调用一些库，
: 很有效
:
: build
|
e*******o
发帖数: 4654 | 36 https://www.youtube.com/watch?v=4XpnKHJAok8&feature=kp
大牛们别吵了。
回楼主，就几个命令学会了就行了。
git checkout -b branchname
commit, commit, commit...
git rebase -i HEAD~x x is commit times.
back to master
git pull
back to your brach
git rebase master
back to the master
git merge.
还能再简单？欢迎大牛们指点。（有时候会有conflict，麻烦一些，但这几个90% 的时
候够用） |
z****e
发帖数: 54598 | 37 幼稚了不是
大牛们都是做架构的
手下管着一堆人
要经常merge的
吵的都是管理经验
【在 e*******o 的大作中提到】
: https://www.youtube.com/watch?v=4XpnKHJAok8&feature=kp
: 大牛们别吵了。
: 回楼主，就几个命令学会了就行了。
: git checkout -b branchname
: commit, commit, commit...
: git rebase -i HEAD~x x is commit times.
: back to master
: git pull
: back to your brach
: git rebase master
|
g*****g
发帖数: 34805 | 38 因为你就在井里，井外面的地方都很奇怪。我老有个服务好几个team都用，几十号程序
员。发现个bug，
对我老不是个事，那个team的服务可能坏了，心急火燎。但我老也很忙，咋办？
人帮我fix了，弄个pull request, 我老跑一下整合测试，没发现问题，merge，半个小
时的事，这个叫做合作。
碰到你们这样的流程，人跑过来跟我说有问题，我老说很忙，没时间帮你解决，你着急
的话跟我老板说让他重新规划优先级。于是对方安排了个会议，双方老板见面，表现出
自己团队很忙，很愿意帮忙但是难度很大，需要时间云云，半个月能解决就算不错了。
这个叫做扯皮。
至于我们公司还有很多开源项目，外部来的pull request不少，原来都是行为艺术。按
贵公司的思路，我看开源本身就是行为艺术。
【在 r****s 的大作中提到】
: 我还真没遇到过A team往B team里check in code的情况，即使是bug fix,也是提交
: delta,由B team的人自己check in。贵公司实在是行为艺术。
: A team当然可以随时看B team的code，即使是另一个SVN server (千万不要说没法做到
: ），但是永远是read only,绝对不可以随意check in。
:
: check
: github
|
z****e
发帖数: 54598 | 39 这贴主要问题是不同情况都混在一起说，容易鸡同鸭讲
主要上火的几个id都是用java的，至少是主流用java的
所以经验都跟其他id非常不一样，至少对于java程序员来说
ide日常工作中占了很大比重，比如代码搜索这种
都是通过ide来完成，而其他语言，很多都是用vim来写代码
搜索是一个大问题，所以git下载快是一个优势
先下载，再grep去找到code，用vi打开阅读，用/去找
ide比如eclipse里面就是control+command+r
其次就是前面说的，下载代码所需要的时间，git明显快
但是呢，git命令很糟糕，又但是，这对于大多数java程序员来说
这不是问题，因为他们一般用的是ide上的可视化plugin
比如古德霸说的egit，所以很多人不在乎命令是哪个
他只需要懂右键点击，选择check in就行了
所以他们可以选择git，但是并不代表其他语言都有ide这种神器
如果你没有比较powerful的ide的时候，对于命令的感觉就相对重要了
这个时候用svn可能会更容易点，我用svn时候就是我写python的时候
最后一点就是，分布式系统，source control的确不是一个好例子
一般都拿db或者nosql这些做例子，而不是source control
source control是分布式的反例，因为就像某id说的
merge时候你只能通过人来处理，而非自动化处理
这就涉及到分布式事务这种分布式核心问题了
这其实是一个很好的例子，从侧面看出java程序员日常工作相对轻松
很多东西都很规范，只需要找到合适的工具就事半功倍
如果是其他的，你做好什么都要自己去折腾的准备 |
s******y
发帖数: 936 | 40 赞同，git 应该是功能最强大，效率最高的。适合很多人一起开发。 但是最大的问题
是上手不容易啊，command太多了，不可能记住。 我是自己搞了个cheatingsheet 。
git 的branch和copy 没有任何关系， 他们是给每个文件加了index，牛逼就在于他们
不用copy。 这样速度快很多，而且空间小，你在一个codebase 上面可以切换不同的
branch 但是这个在svn 上面你需要copy 一个code base。
重复你这一句 “你这连git的原理都没整明白就出来扯了。” 很多人真的是不懂还能
吹成专家。真正用过半年以上的，我觉得不会那么说。
【在 g*****g 的大作中提到】
: 区别当然是有的，我们就几百个developer，perforce都经常很慢，git就不会有这个问
: 题。git的branch当然不是简单拷贝。你这连git的原理都没整明白就出来扯了。
|
|
|
s******y
发帖数: 936 | 41 你这个帖子，只能说明你不懂GIT，git 不容易上手。 但是GIT 很牛逼。
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
y**********u
发帖数: 6366 | 42 git太难了，完全搞不懂阿
我只会装个sourcetree...
做到
【在 g*****g 的大作中提到】
: 因为你就在井里，井外面的地方都很奇怪。我老有个服务好几个team都用，几十号程序
: 员。发现个bug，
: 对我老不是个事，那个team的服务可能坏了，心急火燎。但我老也很忙，咋办？
: 人帮我fix了，弄个pull request, 我老跑一下整合测试，没发现问题，merge，半个小
: 时的事，这个叫做合作。
: 碰到你们这样的流程，人跑过来跟我说有问题，我老说很忙，没时间帮你解决，你着急
: 的话跟我老板说让他重新规划优先级。于是对方安排了个会议，双方老板见面，表现出
: 自己团队很忙，很愿意帮忙但是难度很大，需要时间云云，半个月能解决就算不错了。
: 这个叫做扯皮。
: 至于我们公司还有很多开源项目，外部来的pull request不少，原来都是行为艺术。按
|
s******y
发帖数: 936 | 43 我靠 你真的是需要开眼界了， 50-100个人用一个code base 太他妈正常了。为什么你
们公司不这么干，因为svn 做不到。Git 牛逼就在这里 ，GIT能做到，速度上比svn
还快。但是真的不容易上手。
哎 你虽然在业界这么多年，但是不要这么排斥新技术吧。
build
【在 r****s 的大作中提到】
: 我靠，真还有公司卡在source code management上，开了眼了，这真开了眼了。
: 你们公司也比较奇芭哈，居然有几百人同时checkin到一个source code system，而且
: 还用的perforce - 不敢还是不会用SVN?
: 思路正常一点的公司，每个dev team不会超过10-15个人，team和team之间绝对绝对不
: 可以共用一个SVN source，比如A team 不可以checkin checkout B team的code。各
: team之间用的是对方的prod build jar。
: 随之而来的就是每个team自己有自己的svn server,怎么会慢？你们公司难道每次build
: 都把几百人的checkin 全部build一遍？我靠这架构，牛逼了。
: 也许是你们公司只有一个perforce license? 要不多买几个呗？
: 总之，你们那肯定有搞拧了的地方，我老纵横码工界数年，还未尝见过哪个公司（即使
|
y**********u
发帖数: 6366 | 44 我司，2-3k人用同一个code base, 还用svn呢
不怕想不到，就怕做不到，哈哈
而且
对不
即使
【在 s******y 的大作中提到】
: 我靠 你真的是需要开眼界了， 50-100个人用一个code base 太他妈正常了。为什么你
: 们公司不这么干，因为svn 做不到。Git 牛逼就在这里 ，GIT能做到，速度上比svn
: 还快。但是真的不容易上手。
: 哎 你虽然在业界这么多年，但是不要这么排斥新技术吧。
:
: build
|
s******y
发帖数: 936 | 45 我没说不可以啊，我说git 会更好更牛逼。你说你不用version control 都不会有问题
啊 一个个copy merge 就是了。 不是说行不行，是不好不好的问题。 不过git 真
心不容易懂。懂了就觉得牛逼了。
【在 y**********u 的大作中提到】
: 我司，2-3k人用同一个code base, 还用svn呢
: 不怕想不到，就怕做不到，哈哈
:
: 而且
: 对不
: 即使
|
s******y
发帖数: 936 | 46 问题是sourcetree 不支持linux 只有mac 和 windows 版本， command line真心恶心
啊。
【在 y**********u 的大作中提到】
: git太难了，完全搞不懂阿
: 我只会装个sourcetree...
:
: 做到
|
g****y
发帖数: 2810 | 47 但是svn会让印度office的check in变慢的
【在 r****s 的大作中提到】
: 我两个都用过，没看出区别，一个管source的文件系统不知道有什么必要分布式，从来
: 没见过哪个公司疯狂check in每秒上千次。
: branching就是扯淡，所谓的branching在后台就是原样copy一个文件夹，这尼玛也开始
: 高大上了？branching 要小心，merge的时候就是pita.
: merging就更扯淡了，conflict resolving还是得靠人一行一行地做，和SVN没有区别。
: 凡是觉得git和svn有区别的都是菜鸟。软件这行菜鸟占90%以上，所以git用的人比较多
: 。
: 我老现在用的是svn，组里有傻逼说要转git，说提高效率，被否了。还真没听说过软件
: 开发卡在check in的效率上。
:
|
C*****n
发帖数: 1049 | 48 如果是windows，装个tortoiseGit用起来就是傻瓜式的了。
用Git就像玩Dota，很难上手的，但是会了就觉得很牛B；用svn就像玩TD，很容易上手
，玩久了就觉得很弱。
【在 m*****a 的大作中提到】
: 我不是码农，但需要跟码农合作，时不时也要commit个code之类的
: 忘了是因为什么限制了，什么binary file啊submodule precompile之类的，码农说只
: 能用shell版本，不能用gui的
: 然后发现这个东西也太confusing了，之前用过svn，用过p4p, 都没有这么难用
: 今儿整不出来问人家，他说RTFM，然后居然是本书，妈的不就个source control么居然
: 有一本书！！！！
: 靠
|
s******c
发帖数: 1920 | 49 错了 git像星际 哈哈
【在 C*****n 的大作中提到】
: 如果是windows，装个tortoiseGit用起来就是傻瓜式的了。
: 用Git就像玩Dota，很难上手的，但是会了就觉得很牛B；用svn就像玩TD，很容易上手
: ，玩久了就觉得很弱。
|
t***t
发帖数: 6066 | 50 google tens of thousands of developers can checkout and checkin any code
from other team (of course you need review and approve to check in) in one
source code system.
you are frog in the well.
build
【在 r****s 的大作中提到】
: 我靠，真还有公司卡在source code management上，开了眼了，这真开了眼了。
: 你们公司也比较奇芭哈，居然有几百人同时checkin到一个source code system，而且
: 还用的perforce - 不敢还是不会用SVN?
: 思路正常一点的公司，每个dev team不会超过10-15个人，team和team之间绝对绝对不
: 可以共用一个SVN source，比如A team 不可以checkin checkout B team的code。各
: team之间用的是对方的prod build jar。
: 随之而来的就是每个team自己有自己的svn server,怎么会慢？你们公司难道每次build
: 都把几百人的checkin 全部build一遍？我靠这架构，牛逼了。
: 也许是你们公司只有一个perforce license? 要不多买几个呗？
: 总之，你们那肯定有搞拧了的地方，我老纵横码工界数年，还未尝见过哪个公司（即使
|
|
|
s******y
发帖数: 936 | 51 这就是为什么 it 是青春饭，都有老去的这一天，很难学新东西 也很难接受新东西。
就喜欢自己最熟悉的。 多学才是王道啊。
【在 t***t 的大作中提到】
: google tens of thousands of developers can checkout and checkin any code
: from other team (of course you need review and approve to check in) in one
: source code system.
: you are frog in the well.
:
: build
|
z****e
发帖数: 54598 | 52 把这茬给忘了
楼主可以考虑用一下sourcetree
免费软件 made in au
应该就不会confuse了
【在 y**********u 的大作中提到】
: git太难了，完全搞不懂阿
: 我只会装个sourcetree...
:
: 做到
|
c******o
发帖数: 1277 | |
a********c
发帖数: 3657 | 54 扯淡，clearcase是最难用的，没有之一。
【在 z****e 的大作中提到】
: 是，码农的东西大部分就这么难用
: 我能想到不需要training就能上手的估计只有clear case了
: 但是要钱
: 不只version control有书
: 连html这种玩意都有书，vb也有
: 是很搞笑
|
J*******n
发帖数: 2901 | 55 git 2个优点就秒杀centralized version control systems了，第一是cheap branch，
第二所有历史都在本地，不像svn查个diff还得连上公司网络 |
r****s
发帖数: 1025 | 56 我靠，这个世界上真有不会玩SVN的：
- Re 这个，以前 svn checkout 一个branch, 喝杯咖啡的时间都搞不定，现在一眨眼
就搞好了。local 随便branch,很方便 。
- 我靠 你真的是需要开眼界了， 50-100个人用一个code base 太他妈正常了。为什么
你们公司不这么干，因为svn 做不到。
comments: SVN做不到？真的假的？
而且还有这样的敏捷开发
- 人帮我fix了，弄个pull request, 我老跑一下整合测试，没发现问题，merge，半个
小时的事，这个叫做合作。
comment: 你这merge进去的code，怎么通知其他的team? oh 对了，其他的team直接
build你的source code，直接就上prod了。太爽了，直冲云霄啊。Apache应该直接用你
的经验，还用啥maven啥dependency jar的，整个fundation直接source code build，
一步到位。 我现在知道贵公司为什么只有一个perforce license了，因为大家都不太
懂。 |
r****s
发帖数: 1025 | 57 有啊，我老就是。
瞎JB branching折腾source code, 没有任何帮助，conflict还得自己一行一行地
resolve。
【在 c******o 的大作中提到】
: 只有svn->git的，没有反过来的
|
A*****i
发帖数: 3587 | 58 merge的时候github会发给repo所有者邮件
其实创建PR的时候就会发邮件，owner组的人就会知道
再说这也不是个大问题，github只要integration test做得好提交PR的时候自动会跑一
遍，然后扔给owner组review就行了。
【在 r****s 的大作中提到】
: 我靠，这个世界上真有不会玩SVN的：
: - Re 这个，以前 svn checkout 一个branch, 喝杯咖啡的时间都搞不定，现在一眨眼
: 就搞好了。local 随便branch,很方便 。
: - 我靠 你真的是需要开眼界了， 50-100个人用一个code base 太他妈正常了。为什么
: 你们公司不这么干，因为svn 做不到。
: comments: SVN做不到？真的假的？
: 而且还有这样的敏捷开发
: - 人帮我fix了，弄个pull request, 我老跑一下整合测试，没发现问题，merge，半个
: 小时的事，这个叫做合作。
: comment: 你这merge进去的code，怎么通知其他的team? oh 对了，其他的team直接
|
r****s
发帖数: 1025 | 59 你没有得到我的idea。
1. 组和组之间是用prod jar来联系的，如果你不理解，自己看看Apache foundation里
的project之间互相调用是不是直接编译对方source code。
2. prod release应该有固定的流程，比如应该有versioning - 这里指的是jar file
versioning。这里居然不release。
3. 他举的这个例子就是典型的扯淡。整个公司用一个perforce license的，50个dev
就能crash SVN server的， 你能指望啥？你觉得TwoSigma的HFT code会随便让其他组
checkin？你觉得Amazon的payment team的code会让随便一个瘪三checkin？你觉得
Google的Ads team的code会敞开来随便checkin？你觉得任何一家银行的trading code
应该敞开来给所有人都能checkin？这不叫cool，叫胡说八道。 business critical的
code，任何公司都捂得死死的。
常识，是每个码工应有的素养。
【在 A*****i 的大作中提到】
: merge的时候github会发给repo所有者邮件
: 其实创建PR的时候就会发邮件，owner组的人就会知道
: 再说这也不是个大问题，github只要integration test做得好提交PR的时候自动会跑一
: 遍，然后扔给owner组review就行了。
|
w**z
发帖数: 8232 | 60 你觉得他知道什么是PR？
【在 A*****i 的大作中提到】
: merge的时候github会发给repo所有者邮件
: 其实创建PR的时候就会发邮件，owner组的人就会知道
: 再说这也不是个大问题，github只要integration test做得好提交PR的时候自动会跑一
: 遍，然后扔给owner组review就行了。
|
|
|
A*****i
发帖数: 3587 | 61 只能说公司文化不同吧，我们公司都可以提交PR的
还有你好像不太懂git，PR人人都可以提交，至于merge不merge是owner组决定的
这个和code有多重要没有关系，code review就是用来做这个的
我觉得你固步自封不想接受一些新方法，而且不太懂git还喜欢用svn来比较，这两种版
本控制的工作流程完全是不同的。
code
【在 r****s 的大作中提到】
: 你没有得到我的idea。
: 1. 组和组之间是用prod jar来联系的，如果你不理解，自己看看Apache foundation里
: 的project之间互相调用是不是直接编译对方source code。
: 2. prod release应该有固定的流程，比如应该有versioning - 这里指的是jar file
: versioning。这里居然不release。
: 3. 他举的这个例子就是典型的扯淡。整个公司用一个perforce license的，50个dev
: 就能crash SVN server的， 你能指望啥？你觉得TwoSigma的HFT code会随便让其他组
: checkin？你觉得Amazon的payment team的code会让随便一个瘪三checkin？你觉得
: Google的Ads team的code会敞开来随便checkin？你觉得任何一家银行的trading code
: 应该敞开来给所有人都能checkin？这不叫cool，叫胡说八道。 business critical的
|
A*****i
发帖数: 3587 | 62 恩，我觉得他肯定不知道
【在 w**z 的大作中提到】
: 你觉得他知道什么是PR？
|
r****s
发帖数: 1025 | 63 发信人: rtscts (syslink), 信区: JobHunting
标 题: Re: 很多公司用github做source control么？跟屎一样
发信站: BBS 未名空间站 (Wed Jun 25 09:31:51 2014, 美东)
我还真没遇到过A team往B team里check in code的情况，即使是bug fix,也是提交
delta,由B team的人自己check in。贵公司实在是行为艺术。
A team当然可以随时看B team的code，即使是另一个SVN server (千万不要说没法做到
），但是永远是read only,绝对不可以随意check in。
【在 g*****g 的大作中提到】
: 你跟我老装逼有用吗？git的branch不是拷贝，更像一个tag，你连基本概念都错了，还
: 跟我装到底。
: 我们整个公司就一个产品，文化又比较开放，自然允许team直接互相check in, check
: out，无非需要过一下code review. 多个perforce不是不行，但是没有stash和github
: 这样的高一层组织架构，不利于
: 合作。一个perforce是退而求其次的办法。自然性能有问题，自然要往git上转。
: perforce都不行，svn比perforce更慢。
: 分布式自然有分布式的理由，只有像你这样所有代码都由一个team完全控制，没有分布
: 式的需求，team又小的时候，才会觉得别人是奇葩。一句话，少见多怪。
:
|
s******c
发帖数: 1920 | 64 反正在Google，team之间互相提交代码太平常了。我们组的系统因为有很多下游组合作
，代码就经常有他们提交的修改
【在 r****s 的大作中提到】
: 发信人: rtscts (syslink), 信区: JobHunting
: 标 题: Re: 很多公司用github做source control么？跟屎一样
: 发信站: BBS 未名空间站 (Wed Jun 25 09:31:51 2014, 美东)
: 我还真没遇到过A team往B team里check in code的情况，即使是bug fix,也是提交
: delta,由B team的人自己check in。贵公司实在是行为艺术。
: A team当然可以随时看B team的code，即使是另一个SVN server (千万不要说没法做到
: ），但是永远是read only,绝对不可以随意check in。
|
g*****g
发帖数: 34805 | 65 你不装逼会死吗？明明对git的101都没弄明白，branching跟传统VCS的不同, pull
request这些都没经验，
非要死撑。我老谈的又不是什么高深的东西，就是git的基本用法而已，这个版没有一
个ID赞同你，你就不能
学学再来？
fix跟release是两码事。一个PR被merge了，通常是merge到dev branch, 我们会用
jenkins自动产生snapshot版本，触发integration test. 作为app owner, 我决定什么
时候merge到master上，
产生candidate版本，candidate产生之后，无论是内部的QA, 还是外部的team，都可以
开始测试。测试通过，觉得合适的时候才release. 整个进程的管理是通过JIRA进行的
，所有相关的人都知道到了哪一步。
我们的jar是通过artifactory来管理的，尼玛maven都多少年了，你觉得这些基本的
dependency管理只有你懂？我老人家好好的跟你举例子为啥fix可以快两周，你又混淆
到release上了。release既然是我的
team决定的，问题严重的时候当天能测试好就可以hot fix release, 不严重按照自己
的sprint release。小朋友要不懂CI，agile的这些基本流程我可以给你好好讲讲，但
你明
明101都没整明白，就牛逼上了。
code
【在 r****s 的大作中提到】
: 你没有得到我的idea。
: 1. 组和组之间是用prod jar来联系的，如果你不理解，自己看看Apache foundation里
: 的project之间互相调用是不是直接编译对方source code。
: 2. prod release应该有固定的流程，比如应该有versioning - 这里指的是jar file
: versioning。这里居然不release。
: 3. 他举的这个例子就是典型的扯淡。整个公司用一个perforce license的，50个dev
: 就能crash SVN server的， 你能指望啥？你觉得TwoSigma的HFT code会随便让其他组
: checkin？你觉得Amazon的payment team的code会让随便一个瘪三checkin？你觉得
: Google的Ads team的code会敞开来随便checkin？你觉得任何一家银行的trading code
: 应该敞开来给所有人都能checkin？这不叫cool，叫胡说八道。 business critical的
|
y**********u
发帖数: 6366 | 66 大牛
我以后要用git，能不能给点讲解怎么用git阿！
foundation里
file
dev
他组
critical的
【在 g*****g 的大作中提到】
: 你不装逼会死吗？明明对git的101都没弄明白，branching跟传统VCS的不同, pull
: request这些都没经验，
: 非要死撑。我老谈的又不是什么高深的东西，就是git的基本用法而已，这个版没有一
: 个ID赞同你，你就不能
: 学学再来？
: fix跟release是两码事。一个PR被merge了，通常是merge到dev branch, 我们会用
: jenkins自动产生snapshot版本，触发integration test. 作为app owner, 我决定什么
: 时候merge到master上，
: 产生candidate版本，candidate产生之后，无论是内部的QA, 还是外部的team，都可以
: 开始测试。测试通过，觉得合适的时候才release. 整个进程的管理是通过JIRA进行的
|
g*****g
发帖数: 34805 | 67 git不要问我，我也是一知半解，需要看cheatsheet的。但常识还是有的，不懂还可以
狗嘛。
总之不懂没啥的，这个世界新技术太多了，别不懂还看不起新技术就行。
【在 y**********u 的大作中提到】
: 大牛
: 我以后要用git，能不能给点讲解怎么用git阿！
:
: foundation里
: file
: dev
: 他组
: critical的
|
y**********u
发帖数: 6366 | 68 我一看新技术直接就跪了。。。
哪里还敢看不起
【在 g*****g 的大作中提到】
: git不要问我，我也是一知半解，需要看cheatsheet的。但常识还是有的，不懂还可以
: 狗嘛。
: 总之不懂没啥的，这个世界新技术太多了，别不懂还看不起新技术就行。
|
