标签：
不都是SCM代码管理嘛，有很大区别么？很多svn老鸟都是抱着这样的心态去学习git，然后无一幸免地陷入“查阅过很多资料，依然掌握不好”的困境，至少我们团队是这样的。
网上的资料确实已经很多了，却没有把整个知识结构串起来。通读《git权威指南》是可行的，只是大家都急着用，没那耐性。我这里熬一碗鸡汤，整理供大家享用。
服务器端不展开，因为主要面向搬砖的码农。
客户端可参见大神 廖雪峰 的Git教程-安装git
需要特别说明的是，在windows中，msysgit才是真正的git客户端，乌龟tortoisegit只是个界面。mercurial和sourcetree也是类似道理。
又见 工作区和暂存区
这里容易是初学者容易踩坑的地方，代码只提交到本地版本库，却没有推送到远程版本库。（其实是选型的人的反人类设定吧，用分布式的工具去做集中式的管理。）
svn是本地-远程两层的结构，而git则是工作区-本地-远程三层的结构。
在客户端看的见到的源码文件是工作区，提交到的是本地版本库，本地版本库的修改如果不推送，就是单机自己玩，不会影响其他人。
命令方面资料很健全，我就不重复造轮子了。见上文的Git教程。
命令的查阅很流行这种叫Cheatsheet（考试作弊的小抄么？）速查手册，也是一搜一大把～
比如 http://ndpsoftware.com/git-cheatsheet.html 清晰地指出从哪个区到哪个区对应的命令是什么～
又比如上图，图示说明了遇到各种场景应该怎么办。
至于冲突，都是发生在跨分支或跨库的修改。比如，工作区的修改未commit而pull远程的更新时会报错（要先commit），本地库push发现远程库有其他人提交时会报错（要先pull并在本地解决冲突），暂存区取回stash pop时可能发生冲突。
而当合并发生冲突需要手动解决时，svn老鸟肯定是懵逼的，三路对比合并，哪个打哪个啊。。。这是因为，在svn中只有“我和中央库”的冲突，而git中却是“我和他”的冲突。
所以在git中做合并有三个源：base是分支的共同祖先，local是本地仓当前分支，remote是要从这个分支合过来，output当然就是合并结果的预览啦。
详见 对于解决 Git 的 Merge Conflict 你有哪些经验和技巧？
两者没有本质区别，图形界面最后也还是触发命令。直接用命令行能更好理解整个操作的过程。
图形界面则操作方便。但新手一定要对图形界面中的参数保持敏感，可能多勾了选项结果就完全不一样，比如--force。。。
查阅过很多git分支管理的资料，依然用得不好，直到踩过若干个月的坑。。。
git的发源是开源系统，思想是分布式、去中心化，用svn的集中式管理是很容易踩坑的。
首先，svn是针对文件内容的对比，而git是针对文件增量和提交时间的对比，多人的频繁的冲突合并极容易发生错误。
其次，git的去中心化思想认为每个开发者都是熟练的负责任的。而事实上不是的，如果团队里有一两个“流氓”，遇到冲突没有细看，直接--force或use mine，测试会抓狂的，然后开发和项目经理都会抓狂的～
然后最后，你便会质疑：为什么不用svn啊？git跟svn没什么区别啊，还更难用！
且看看开源项目对git是怎么用的。 Git使用规范流程 开发者先fork复制出自己的库（远程），然后一系列的开发（本身也可以有分支管理），push上自己的远程库后，再pull request提交给管理员review和合并。而开源项目的发布，是有stable和nightly update等不同的发布版本。
回过头来看，公司团队里的项目要怎样管理git的版本和分支呢？
上图 git flow 便是最完整最科学的分支管理模型了。
这里有四点血泪经验要谨记：
1.不要吝啬开分支，git开分支的代价很小。
2.合并是容易出事的环节，要让负责任的熟手来把关。
3.以feature划分开发分支是非常好的思维方式，把相互依赖的内容放在一起、把不相关的内容隔离开、让“这个功能暂时不上”这种需求变更变得可行。
4.分支是活的、会变动的，标签tag才是一个确切的版本。
至此，使用git做源码管理的项目和团队足以运作起来而且可以避开大部分的坑。要用得更溜的话可以继续精修patch、rebase、revert、--fast-forward、cherry pick等更高阶的用法。
最后彩蛋：老司机温馨提醒，请把eclipse项目文件、编译后文件（文件夹）加入.gitignore文件，这个问题在svn就存在了～
标签：
原文地址：http://www.cnblogs.com/syjkfind/p/5935276.html
