从 svn 迁到 git，求教大家单位上 git 都是怎么用的？

Git 可以用来提高源码库的质量。
由于 Git 的分支免费，所以可以按照功能开分支开发完再合并。参考 Git Flow 流程（轻量版）。
另外这不是说服的问题。跟风上 Git 其实不见得是个好事，最好是用 SVN 遇到坑了或者受不了分支的高昂代价了再趁机转。

先参考这个对 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 就不行

按错键发出去了，第三行漏了一句：
切记不要生搬硬套。

tfs 能用？呵呵。。。

而且我觉得 git 其实并不难，基本几个命令熟练就差不多了。
stats, checkout, commit, add, pull, push....

查看 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}条记录

如果 1 你是技术股干， 2 你是领导，否则还是不要试图说服

自己都不熟悉还是别了, 项目最重要的是稳定性, 大家碰到刚转过去的水土不服, 多半会转向你, 如果你也说不出个所以然, 大家会转回 svn , 还会对你刮目相看的... 说实话, svn 和 git 我目前是同时使用的, 会 git 的人自然回不去 svn 了, 设计师, 前端工程师这种轻量级的, svn 其实足够了, 也会让他们的工作轻松不少.

同意楼上看法

@cxbig 分支合并到主分支的时候冲突也会很多的。


@oska874

Git 使用中分支是关键，我日常用到的命令包括： pull, push, fetch, merge, checkout, branch, reflog, rebase, reset, cherry-pick.

1. Github 提供简单互动的教程。

2. 建议好好看下 Atlassian 的教程。 https://www.atlassian.com/git/tutorials/

@msg7086 什么叫“ Git 的分支免费”？ SVN 分支收你钱了？

@cxbig 关于你的第 1 点，难道 SVN 不能建分支？

你们这些 git 党，都没有说到点上。 git 最重要的优点是分布式的数据库，还有就是 code review 比较方便，直接起个 pull request 。

@mozartgho 的确，分布式是最大的优点。
@shoaly @582033 正因为目前是刚开始，项目成员以前也不全是用过 svn 的，所以历史包袱还是很轻的，但是领导们以前一直在用 svn ，所以。
@bbx 不能鄙视 tfs ， 以前公司就是从免费的 svn 迁移到收费的 tfs 的， tfs 很容易上手。

lz 好幸福, 我推广了两年都没成功. 只能使用 svn

@mozartgho 他说的分支免费是指分支不占用额外的空间。在 git 中，一个分支所占用的空间只是该分支和分叉点的 diff 而已。而在 SVN 中，每创建一个分支都是把分支的数据重新 copy 一份。

当然 svn 也有比 git 好用的地方，我觉得最明显的就是 svn 可以 co 一个子路径， git 只能 clone 这个项目。

@mozartgho SVN 分支代价很大的。
比如说我们公司光 Git 库就已经 3G+了，如果换用 SVN 的话，一个 repo 几十 G 都有可能。
每次分支就得额外克隆个几百 M ，谁吃得消。
克隆一次假如要浪费 5 分钟，那么公司里几十几百次的克隆要浪费多少宝贵的时间？
这些时间难道不是钱？

当然可能有些企业不在乎。
「不就是晚几个星期发布产品嘛，无所谓」
「不就是让员工多加班几天嘛，无所谓」
可有些人在乎。

还是说你没有参与过稍微有点规模的项目？

「 code review 比较方便」你以为没有 git 这样的超低代价分支，你能这么轻松做 code review 和 pr ？能有 Git Flow 这种方便的工作流程？

就拿 mercurial 这样支持分布式但分支有轻微代价的版本管理系统来说好了。
你看看现在 Git 用户和 Hg 用户各有多少？
更何况 SVN 这种超重代价分支的系统了。

如果真的特别喜欢 SVN 这种开发模型的，也至少去用 Hg 吧。

坚守 SVN 我只能想到一个理由，那就是严格权限管理。

@msg7086 还有一点， git 太过复杂， svn 比较简单。我推广了很久 git ，结果还是换成了 svn+reviewboard

@wizardoz
@msg7086 你们确信在 SVN1.8.9 上创建分支是完整地重新拷贝一份代码？而不是基于 diff ? 建议你们动手试一下。

office 自带版本管理……

@mozartgho 现在的情况不清楚了，上一次用 SVN 大概是 6 年多前。
我刚才查了一下，似乎分支内部使用的是硬链接来做的。
那就是说，至少是不支持 WinXP 咯。新版的 Windows 也不知道支持情况如何……总之我是懒得测了啦。

还有个麻烦事就是不支持 rebase ，对于代码库洁癖来说面条状的提交记录会看疯的。

团队里面必须有个 git 比较熟练的人才行，要不然当大家都解决不了的问题出现了就要找替罪羔羊了。

@mozartgho

@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 也就是里程碑。

昨天有个说 git 迁到 svn 的，今天又有 svn 迁到 git 的，你们两家的 CTO 直接调一下不就得了，这么的还是底层的码农

t/219174

楼主是在逗我们的吧

@billwang 收到一点启发而已，恰巧最近在干这事。
@yellowV2ex 和 cto 无关， cto 才不管这些呢，而且这种迁移是自下而上推动的，是要说服你所说的 CTO 。

文档最好还是用 Markdown 来写，存放到 GIt 上，然后使用 Web 服务来阅读

楼主开发团队有多少人？如果人不对， 10 人以下，还是 svn 麻烦少

受不了。。我们 5 人是 git ； 20 人公司也是 github 。。
最大的问题是你们领导。

文档用 markdown 写

网上太多资料讲 git 的正确工作流了。

gitlab 挺好用，合并分支的时候代码也不会丢

纯程序员的团队用用 git 挺好的，但是有人一说 git 就要出来喷 svn 。最关键的是，由于自己什么都不懂，还喷不到点上。“ SVN 中，每创建一个分支都是把分支的数据重新 copy 一份”，这是想什么呢？？然后居然用这个指责 svn 在大 repo 下不好。事实上， git 相当不擅长处理有巨大文件的 repo ，还不如 svn 。你们应该好好看看 forcecharlie 的回复，他说的对，好几个关键问题都说到了。

另外，各种系统都能找到 office 文件的比较工具的。

我还推荐 mercurial 呢, 安利了半年, 没啥鸟用.

@bbx git 有一个不足，就是没办法给目录分别设权限，而这一点 tfs 做的就很不错。