项目组刚开始新一轮的工作,我就再内网服务器上用 gitlab 搭建了一个 git 服务器——不用 github 的原因是钱、速度 /功夫网、领导们不放心。公司以往用的都是 svn ,但是因为项目刚开始,所以 svn 还没有在新项目全面使用。想着趁 svn 还没有全部使用的机会,推广一下 git ,但是没有说服领导们,在他们看来 git 最大的好处就是分布式管理,可以在本地 push/pull ,除此之外和 svn 区别也不大。如果换做大家,能怎么说服经理们从 svn 转到 git ?
ps :以前公司用的 ms 的 tfs ,自己用 git 也不是很熟练,但是 git 的速度要比 tfs 快太多了。
再追加一个求助,大家平时文档怎么进行管理的?对于 office 特别是 word 文档,有什么好的办法进行版本管理:能够直观的比较两个版本内容的不同。直接用 git/svn 这些工具只能进行二进制比较,不好用。
1
msg7086 2015-09-10 03:24:47 +08:00
Git 可以用来提高源码库的质量。
由于 Git 的分支免费,所以可以按照功能开分支开发完再合并。参考 Git Flow 流程(轻量版)。 另外这不是说服的问题。跟风上 Git 其实不见得是个好事,最好是用 SVN 遇到坑了或者受不了分支的高昂代价了再趁机转。 |
2
cxbig 2015-09-10 04:22:17 +08:00 1
先参考这个对 git flow 的概念有一个大概的了解
http://nvie.com/posts/a-successful-git-branching-model/ 然后根据自己团队的情况酌情处理命名规范、分支安排,切记不要 git 的最大好处有 2 点: 1. 快速开发的时候团队作业免不了遇到 conflict , svn 提交的时候发现其他人已经提交而且有 conflict ,想 checkout 也因为 conflict 无法正常进行,那么这时候程序员会很烦躁, git 用分支结构,每个人走一个分支, conflict 机会少,在代码合并的时候一次性处理 conflict ,压力不会太大。 2. 每个人都有 repo 的本地 copy ,各种 commit 版本切换不需依赖服务器, svn 就不行 |
3
cxbig 2015-09-10 04:23:44 +08:00
按错键发出去了,第三行漏了一句:
切记不要生搬硬套。 |
4
bbx 2015-09-10 05:43:41 +08:00
tfs 能用?呵呵。。。
|
5
bbx 2015-09-10 05:45:05 +08:00
而且我觉得 git 其实并不难,基本几个命令熟练就差不多了。
stats, checkout, commit, add, pull, push.... |
6
582033 2015-09-10 06:51:46 +08:00 via Android
查看 svn 历史
svn info svn://svn.test.co/foo/ svn log -l{num} #limit 从指定版本检出 git svn clone -r{svnNum}:HEAD {svnUrl} git svn clone -r100:HEAD svn://svn.test.co/foo/ 检出前,可以使用 svn 命令来查看最近{num}条记录 |
7
582033 2015-09-10 06:53:58 +08:00 via Android
如果 1 你是技术股干, 2 你是领导,否则还是不要试图说服
|
8
shoaly 2015-09-10 07:56:19 +08:00
自己都不熟悉还是别了, 项目最重要的是稳定性, 大家碰到刚转过去的水土不服, 多半会转向你, 如果你也说不出个所以然, 大家会转回 svn , 还会对你刮目相看的... 说实话, svn 和 git 我目前是同时使用的, 会 git 的人自然回不去 svn 了, 设计师, 前端工程师这种轻量级的, svn 其实足够了, 也会让他们的工作轻松不少.
|
9
582033 2015-09-10 08:18:02 +08:00
同意楼上看法
|
10
hantsy 2015-09-10 08:37:02 +08:00
@cxbig 分支合并到主分支的时候冲突也会很多的。
@oska874 Git 使用中分支是关键,我日常用到的命令包括: pull, push, fetch, merge, checkout, branch, reflog, rebase, reset, cherry-pick. 1. Github 提供简单互动的教程。 2. 建议好好看下 Atlassian 的教程。 https://www.atlassian.com/git/tutorials/ |
13
mozartgho 2015-09-10 09:10:20 +08:00
你们这些 git 党,都没有说到点上。 git 最重要的优点是分布式的数据库,还有就是 code review 比较方便,直接起个 pull request 。
|
14
oska874 OP |
15
yinheli 2015-09-10 09:34:13 +08:00
lz 好幸福, 我推广了两年都没成功. 只能使用 svn
|
16
wizardoz 2015-09-10 09:43:39 +08:00
@mozartgho 他说的分支免费是指分支不占用额外的空间。在 git 中,一个分支所占用的空间只是该分支和分叉点的 diff 而已。而在 SVN 中,每创建一个分支都是把分支的数据重新 copy 一份。
|
17
wizardoz 2015-09-10 09:46:23 +08:00
当然 svn 也有比 git 好用的地方,我觉得最明显的就是 svn 可以 co 一个子路径, git 只能 clone 这个项目。
|
18
msg7086 2015-09-10 09:48:17 +08:00 1
@mozartgho SVN 分支代价很大的。
比如说我们公司光 Git 库就已经 3G+了,如果换用 SVN 的话,一个 repo 几十 G 都有可能。 每次分支就得额外克隆个几百 M ,谁吃得消。 克隆一次假如要浪费 5 分钟,那么公司里几十几百次的克隆要浪费多少宝贵的时间? 这些时间难道不是钱? 当然可能有些企业不在乎。 「不就是晚几个星期发布产品嘛,无所谓」 「不就是让员工多加班几天嘛,无所谓」 可有些人在乎。 还是说你没有参与过稍微有点规模的项目? 「 code review 比较方便」你以为没有 git 这样的超低代价分支,你能这么轻松做 code review 和 pr ?能有 Git Flow 这种方便的工作流程? 就拿 mercurial 这样支持分布式但分支有轻微代价的版本管理系统来说好了。 你看看现在 Git 用户和 Hg 用户各有多少? 更何况 SVN 这种超重代价分支的系统了。 如果真的特别喜欢 SVN 这种开发模型的,也至少去用 Hg 吧。 坚守 SVN 我只能想到一个理由,那就是严格权限管理。 |
19
kqz901002 2015-09-10 10:06:53 +08:00
@msg7086 还有一点, git 太过复杂, svn 比较简单。我推广了很久 git ,结果还是换成了 svn+reviewboard
|
20
mozartgho 2015-09-10 10:13:34 +08:00
|
21
lizheming 2015-09-10 10:27:33 +08:00
office 自带版本管理……
|
22
msg7086 2015-09-10 12:10:02 +08:00
@mozartgho 现在的情况不清楚了,上一次用 SVN 大概是 6 年多前。
我刚才查了一下,似乎分支内部使用的是硬链接来做的。 那就是说,至少是不支持 WinXP 咯。新版的 Windows 也不知道支持情况如何……总之我是懒得测了啦。 还有个麻烦事就是不支持 rebase ,对于代码库洁癖来说面条状的提交记录会看疯的。 |
23
KNOX 2015-09-10 12:31:26 +08:00
团队里面必须有个 git 比较熟练的人才行,要不然当大家都解决不了的问题出现了就要找替罪羔羊了。
|
25
forcecharlie 2015-09-10 13:44:43 +08:00
@msg7086
@mozartgho svn 远程仓库肯定很大,但是也不会很大的, Subersion 基于差异,而 Git 每一次修改都将修改后的文件使用 zlib 压缩成一个 Object ,名字是 hash 格式如 {2}/{38} 存储在 .git/objects 目录 ,使用 git gc 后,写入到 objects/*.pack 对于大文件的修改, git 很容易出现体积陡增。这样的好处是,不要通过差异计算获得文件,只需要找到指定的 对象 id 然后 解压即可。 如果团队协作,项目非常大,建议使用 Subversion 或者是使用 Git 用 Submodule 机制。 Subversion 部分检出,只需要将开发者开发指定的分支或者指定的目录检出来即可。 Git Submodule 不同的开发者操作不同的 Submodule ,然后,技术主管在 总的 git 仓库设置 Submodule 的 Commit, 这个实际上可以编辑的。 分支模型, Git 的分支是均权分支,默认分支,主要指的是 remote 指向的存储库的 HEAD 里面的引用。 实际上,随着 Github 和 OSC@GIT 等代码托管网站的兴起, Pull Request 机制是比较适合 Git 的,这里带来的问题是 fork 仓库带来了磁盘存储的压力,多个 fork 请求, IO 居高不下,磁盘空间的需求几乎是呈指数增长的。 而 Subversion 的分支模型,更像文件系统目录结构,每个人对目录有不同的操作权限。在 Subversion 的官方仓库,也就是自举仓库 http://svn.apache.org/repos/asf/subversion/ trunk/ ......... The latest development sources. When people say "Get the head of trunk", they mean the latest revision of this directory tree. branches/ ...... Various development branches. Typically a branch contains a complete copy of trunk/, even if the changes are isolated to one subdirectory. Note that branch copies are generally removed after they've been merged back into trunk, so what's in branches/ now does not reflect all the branches that have ever been created. tags/ .......... Snapshots of releases. As a general policy, we don't change these after they're created; if something needs to change, we move it to branches and work on it there. 他们的快速开发主要是 trunk, 而发布分支主要是 branches 下载分支, tag 也就是里程碑。 |
26
yellowV2ex 2015-09-10 14:01:37 +08:00
昨天有个说 git 迁到 svn 的,今天又有 svn 迁到 git 的,你们两家的 CTO 直接调一下不就得了,这么的还是底层的码农
|
27
billwang 2015-09-10 17:13:51 +08:00
|
28
oska874 OP |
29
learnshare 2015-09-10 17:52:15 +08:00
文档最好还是用 Markdown 来写,存放到 GIt 上,然后使用 Web 服务来阅读
|
30
kaneg 2015-09-10 21:22:29 +08:00 via iPhone
楼主开发团队有多少人?如果人不对, 10 人以下,还是 svn 麻烦少
|
31
Tedko 2015-09-11 00:18:33 +08:00
受不了。。我们 5 人是 git ; 20 人公司也是 github 。。
最大的问题是你们领导。 |
32
aprikyblue 2015-09-11 02:10:14 +08:00
文档用 markdown 写
|
33
ttma1046 2015-09-11 07:47:49 +08:00
网上太多资料讲 git 的正确工作流了。
|
34
oscarzhao 2015-09-11 09:06:33 +08:00
gitlab 挺好用,合并分支的时候代码也不会丢
|
35
gamingcat1234 2015-09-11 10:01:12 +08:00
纯程序员的团队用用 git 挺好的,但是有人一说 git 就要出来喷 svn 。最关键的是,由于自己什么都不懂,还喷不到点上。“ SVN 中,每创建一个分支都是把分支的数据重新 copy 一份”,这是想什么呢??然后居然用这个指责 svn 在大 repo 下不好。事实上, git 相当不擅长处理有巨大文件的 repo ,还不如 svn 。你们应该好好看看 forcecharlie 的回复,他说的对,好几个关键问题都说到了。
|
36
gamingcat1234 2015-09-11 10:06:05 +08:00
另外,各种系统都能找到 office 文件的比较工具的。
|
37
zhuangzhuang1988 2015-09-11 13:29:06 +08:00
我还推荐 mercurial 呢, 安利了半年, 没啥鸟用.
|