1.git 和 svn 的差异
git和svn 最大的差异在于git是分布式的管理方式而svn是集中式的管理方式。如果不习惯用代码管理工具，可能比较难理解分布式管理和集中式管理的概念。下面介绍两种工具的工作流程（团队开发），通过阅读下面的工作流程，你将会很好的理解以上两个概念。
集中式管理的工作流程如下图（图2.1）：
　　集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上是不可以工作。下面举例说明：
开始新一天的工作：
1：从服务器下载项目组最新代码。
2：进入自己的分支，进行工作，每隔1个小时向服务器自己的分支提交一次代码（很多人都有这个习惯。因为有时候自己对代码改来改去，最后又想还原到前一个小时的版本，或者看看前一个小时自己修改了哪些代码，就需要这样做了）。
3：下班时间快到了，把自己的分支合并到服务器主分支上，一天的工作完成，并反映给服务器。
这就是经典的svn工作流程，从流程上看，有不少缺点，但也有优点。
1、服务器压力太大，数据库容量暴增。
2、如果不能连接到服务器上，基本上不可以工作，看上面第二步，如果服务器不能连接上，就不能提交，还原，对比等等。
3、不适合开源开发（开发人数非常非常多，但是Google app engine就是用svn的）。但是一般集中式管理的有非常明确的权限管理机制（例如分支访问限制），可以实现分层管理，从而很好的解决开发人数众多的问题。
1、管理方便，逻辑明确，符合一般人思维习惯。
2、易于管理，集中式服务器更能保证安全性。
3、代码一致性非常高。
4、适合开发人数不多的项目开发。
5、大部分软件配置管理的大学教材都是使用svn 和vss。
下面是分布式管理的工作流程，如下图（图2.2）：
　　分布式和集中式的最大区别在于开发者可以在本地提交。每个开发者机器上都有一个服务器的数据库。
　　图2.2就是经典的git开发过程。步骤如下：
一般开发者的角度：
1：从服务器上克隆数据库（包括代码和版本信息）到单机上。
2：在自己的机器上创建分支，修改代码。
3：在单机上自己创建的分支上提交代码。
4：在单机上合并分支。
5：新建一个分支，把服务器上最新版的代码fetch下来，然后跟自己的主分支合并。
6：生成补丁（patch），把补丁发送给主开发者。
7：看主开发者的反馈，如果主开发者发现两个一般开发者之间有冲突（他们之间可以合作解决的冲突），就会要求他们先解决冲突，然后再由其中一个人提交。如果主开发者可以自己解决，或者没有冲突，就通过。
8：一般开发者之间解决冲突的方法，开发者之间可以使用pull命令解决冲突，解决完冲突之后再向主开发者提交补丁。
主开发者的角度（假设主开发者不用开发代码）：
1：查看邮件或者通过其它方式查看一般开发者的提交状态。
2：打上补丁，解决冲突（可以自己解决，也可以要求开发者之间解决以后再重新提交，如果是开源项目，还要决定哪些补丁可用，哪些不用）。
3：向公共服务器提交结果，然后通知所有开发人员。
适合分布式开发，强调个体。
公共服务器压力和数据量都不会太大。
速度快、灵活。
任意两个开发者之间可以很容易的解决冲突。
资料少（起码中文资料很少）。
学习周期相对而言比较长。
不符合常规思维。
代码保密性差，一旦开发者把整个库克隆下来就可以完全公开所有代码和版本信息。
2.git常用命令介绍
创建一个数据库
复制一个数据到制定文件夹
git add 和git commit
把想提交的文件add上，然后commit这些文件到本地数据库。
从服务器下载数据库，并跟自己的数据库合并。
从服务器下载数据库，并放到新分支，不跟自己的数据库合并。
git whatchanged
查看两个分支的变化
git branch
创建分支，查看分支，删除分支
git checkout
合并分支，把目标分支合并到当前分支
git config
配置相关信息，例如email和name
查看版本历史
查看版本号对于版本的历史，如果参数是HEAD查看最新版本。
标定版本号
恢复到之前的版本
--mixed是git-reset的默认选项，它的作用是重置索引内容，将其定位到指定的项目版本，而不改变你的工作树中的所有内容，只是提示你有哪些文件还未更新。
--soft选项既不触动索引的位置，也不改变工作树中的任何内容。该选项会保留你在工作树中的所有更新并使之处于待提交状态。相当于在--mixed基础上加上git add。
--hard 把整个目录还原到一个版本，包括所有文件。
向其他数据库推送自己的数据库
git status
显示当前的状态
重命名文件或者文件夹
删除文件或者文件夹
查看帮助，还有几个无关紧要的命令，请自己查看帮助。
3.git开发模式
1：大项目开发模式（如图4.1）
对于项目负责人
对于最终项目负责人：
使用git init --bare在公共服务器上建立一个空数据库，在自己的机器上通过
或者数据库（这里需要设置一下访问权限，由于git没有提供权限管理功能，所以要通过ssh设置，具体是对下一级子项目项目可读不可写，对自己可读可写）。
新建一些必要的文件夹和文件放到自己的数据库上
提交到公共服务器上，作为原始版本。
告诉下级公共服务器的地址。
对于子项目负责人：
在子公共服务器上克隆一个数据库
设置访问权限，对下级可读不可写，对自己可读可写。在自己的计算机中克隆一个数据库
告诉下级子公共服务器地址。
对于最底层的开发人员：在上级公共服务器中克隆一个数据库
2：开展工作对于最终项目负责人收来自下级的邮件在自己的数据库上建分支，并转到分支上
重复上述步骤，直到所有补丁打完。如果发现在合并分支的时候发现有些冲突需要下级项目负责人协助解决的话，可以通知下级项目负责人。对于子项目负责人：如果上级项目负责人需要他们之间合作解决某些冲突，他们可以通过
解决冲突。如果上级项目负责人没有要求合作解决冲突，那项目负责人应该做以下事情：
然后项目负责人就开始接收邮件，然后打补丁
重复上述工作，直到补丁全部打完。下面是向上级提交更新的过程
对于最底层的开发人员：如果上级要求解决冲突，同样是要解决冲突，然后再提交补丁
如果不用，就从上级服务器更新
然后建分支，并开发代码
然后是向上级提交代码
以上就是git在大项目开发中的应用。但是明显是不适合我们实验室的。原因有三：1、我们学生中没有专门的维护人员。2、我们学生中没有对全局都很了解架构师。3、我们的老师可以担当此重任也只有我们的老师有这样的实力，但是老师太忙，没时间每天做这些琐事。所以我们需要一种新的合作模式（一种没有项目负责人的模式）。
这种模式对开发人员的素质要求很高。合作模式如下图（图4.2）：（适合我们实验室使用）
这种模式的开发流程如下：1、由其中一个开发者这服务器上建立一个数据库。所有开发者都可以向数据库提交和下载东西，这里必须规定一定的时间间隔（一周或者一天）必须提交一次，不然以后解决冲突时是个大问题。如果每个人的开发耦合度很高，我们可在服务器上建立分支，然后每人每次提交到自己的分支上，过一段时间之后（不能太久）有一个人去合并分支。然后所有人更新自己的数据库的master分支，使之跟服务器上的master分支同步。2、这样服务器会有非常多的版本信息，集合了每个人的版本信息。过了一段时间之后，例如有里程碑的出现。再由一个人把所有改动打补丁到最终服务器上。这样最终服务器的版本信息就会很精练。3、当我们的服务器无限膨胀到一定程度的时候我们可以把它删除，然后用最终服务器上的一个版本作为起始版本。
阅读(...) 评论()GIT中，大家团队是如何使用的呢？ - 开源中国社区
当前访客身份：游客 [
当前位置：
请教一下各位在团队中，你们是如何使用GIT的呢？
目前，我打算安排团队这样使用。
git仓库有 以下分支：正式版分支，开发版分支 &和 对应开发人员的分支。
开发版分支用于测试合并 其他开发人员的开发分支。 待开发版确认无误，再与正式版合并。。
就是说，每个员工有自己一个分支。如，张三，李四分支。。 他们两个开发完毕后，先推送到自己的分支。
接着和 开发版的分支进行 合并。。解决冲突。 跑环境测试。。。确认无误，与正式版合并，同步生产服务器。。。。
------------------------------------------
未知大家的团队是如何使用GIT的呢？请经验指点，谢了。
共有15个答案
<span class="a_vote_num" id="a_vote_num_
这个blog里面，讲了4种不同的git工作流程，感觉不错，推荐给大家看看。
git flow流程，个人感觉过于复杂，小团队不推荐使用。
--- 共有 1 条评论 ---
还有人回复啊？太感动了
(2年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
git flow可以说是最佳流程了
然后你需要考虑的就是怎么测试了
<span class="a_vote_num" id="a_vote_num_
和你有一样的疑问呀，关注答案，希望有经验的同事进行分享
<span class="a_vote_num" id="a_vote_num_
我们是公用一个分支 当然没有你的好。你的还有个问题，张三开发a功能，还没开发完，有让他紧急改一下b功能 怎么办？所以应该再加一层功能分支或者叫特性分支 开发分支下面多个特性分支 每个特性分支下面多个人员分支
--- 共有 1 条评论 ---
我认为，这个不成问题。他在本地切换一个新分支。待开发完毕和他的分支 合并就行了。 最后再推送一下。
(2年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
我觉得可以参照现有的GITOSC上开源项目的模式，一个正式主项目，各个小组Fork主项目，开发测试完毕提交自己项目组的Request。
--- 共有 2 条评论 ---
: 有在用fork吗？一直不甚了解该如何使用fork和pull request，我们采用了gerrit作为代码审查和门禁签入的工具
(2年前)&nbsp&
嗯，但貌似fork存在一个同步问题。
(2年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
搭建私有仓库。我们用的是gerrit，带有审核功能，团队成员推送的commit会被其他成员review，然后项目经理根据review结果进行verify和commit patch操作
<span class="a_vote_num" id="a_vote_num_
如果員工間寫的代碼會經常互相調用，會不會使管理很繁瑣，不停的需要合併開發版分區，影響開發效率？
<span class="a_vote_num" id="a_vote_num_
一般都用模块划分项目，然后进行模块分支，组内成员merge，Request！最后进行模块整合，到项目完成
<span class="a_vote_num" id="a_vote_num_
听说过“git-flow”吗？
--- 共有 1 条评论 ---
没，果断搜索了解
(2年前)&nbsp&
<span class="a_vote_num" id="a_vote_num_
Git&通常是个人使用。&我更推荐下面的流程。以方便共同协作。
只有俩分支是共享的，开发分支，发布分支。其他所有分支为成员临时建立的分支。作为功能补丁加入系统，供专人负责合并进开发分支。
版本管理有专人专职负责，或者专人兼职负责。&个人成员负责向开发分支提交属于自己分支的代码，可以不必公开，专人负责合并进开发分支，提供团队共同参与测试。 经过一段时间的历练，确保相对稳定，建立 tag&合并进发布分支进行整体测试。&仍然有专人负责。
--- 共有 2 条评论 ---
: 在建立之初， 有人负责是好的，直到大家都习惯了，并且都会维护分支管理了。另外， 好的团队对于提交的内容。合并其实很少有冲突需要解决，只是一个命令。 解决冲突是属于每个团队里开发人员的责任。 不属于版本管理人员的责任，可以要求存在冲突的提交内容再决绝冲突后合并进开发分支。
(2年前)&nbsp&
这样得需要一个人去管理啊。 orz..
(2年前)&nbsp&
更多开发者职位上
有什么技术问题吗？
首席李兰...的其它问题
类似的话题android studio怎么使用git团队开发_百度知道小团队如何利用好 Git？
5个人的小团队，有美工有程序。我们是一人负责一个模块，所以就一个人一个分支，一个人完成了之后推送到主分支。但是总会有意想不到的冲突。求大神指导下。
正好今天写了一下我们团队这几年一直在改进的 Git Flow，可以参考一下，
有几点要注意。1. Branch 应该是跟着 Features/Bugs 走，而不是跟人走。试想我们的工作推进方法，应该是这个模块完成了，把这个模块的更改给 merge 到主分支，而不是说这个人的工作完成了，把这个人更改的代码给 merge 回去。2. merge 要越早越好，merge 的越晚冲突的可能性越高。所以，这个就要求你作计划的时候粒度细一点，修改越少越好 merge。同时，也可以在主分支之外有个 staging 一样的分支，基本是主分支的备份，但是在有模块完成后可以先 merge 到 staging 做测试。3. 每次 merge 一个东西，一次把 5 个人的更改都推送到主分支，很难不起冲突。所以，推送应该是双向的，不要只往主分支推送，而是在推送前先同步主分支，看看有没有冲突，有冲突就解决，没冲突就表示可以安全地 merge 到主分支。除了我们团队的 Git Flow，也有一些其他分享，可以多看看，会有帮助。
稍微说一下我们团队的工作情况，可能会给你一点帮助。我们团队负责iOS客户端开发，总共三人都是iOS程序员，公司主要依赖Jira+Stash+Git来进行开发。1.UI、测试、产品经理、项目经理等等不用Git，只使用Jira分配任务和交换素材等等。2.我们的Git下面分为：release、master、develop三个固定分支。develop是用于新版开发，release用语提交到store上的版本的存储（应用被拒和已发布版本的紧急修护均在这上修改），master则是最稳定版本的存储。3.其余分支只有在开发新功能、修改bug的时候根据需要建立，一般而言以改bug为例，一个bug就建一个分支，这样子一天分支多的时候会建几十个，换句话说，我们临时分支比较小，保证互相code review的时候每次工作量较小，这么做也有助于提升代码质量以及减少冲突。4.互相比较了解各自的工作区域，遇到可能同时修改同一文件的时候，一般会特别知会其他程序员，大家有个心理预期，什么改法比较保险如果merge出问题要怎么应对等等。5.一般在develop上进行开发，遇到需要对release的代码进行hotfix的时候，一定要注意是不是develop上也要改对应的地方。6.在提交代码前，一定要看diff，如果发现有些并非自己改动的部分发生改动并且在自己的提交列表里，要discard掉这类提交。保证所有修改都是有效修改。7.统一大家的编码格式，Xcode可以通过插件然后共享对应格式文件保证大家该缩进的地方锁进，该空格的地方空格，这样子可以避免很多没什么意义的冲突。
搬运下，原文见------小团队的代码管理可以采用这样一种方式：项目存在一个中心远程仓库，作为团队成员进行代码交流的主要场所。同时可以存在一些成员远程仓库，用于局限在团队中部分成员间的代码交流。并将成员分成以下几类不同的角色：负责人、普通组员、预发布责任人 和 版本修复责任人。下面的章节具体介绍了各类角色的 Git 使用流程。基本须知：需要多个人共同完成的分支可以建立远程分支，单个人完成的分支只建立本地分支即可。一、负责人负责人的职责：管理远程仓库。负责人的工作均可直接在远程仓库完成。1.创建项目创建公有项目添加README.md添加证书添加忽略文件创建 dev 分支2.其他更新 README.md 文件二、组员工作流程：克隆项目签出并创建 dev 分支，使其跟踪远程的 origin/dev 分支。在dev分支基础上创建自己的分支 member* 。在自己的分支上添加文件在自己的分支上修改文件合并到dev分支推送dev分支到origin/dev分支// 更新 .gitignore 文件从 dev 新建一个分支 ignore （如果预测变更频繁就建立一个远程分支，现在一般都有模板，偶尔有个没有忽略的直接在dev分支上改就可以了）更新忽略文件尽快合并到\推送到 origin/dev 分支 （避免两个组员同时更改该文件造成冲突。）1.创建本地仓库$ cd [项目路径]
$ git clone https://coding.net/tangyikejun/GitTest2.git
$ git checkout -u -b dev origin/dev
$ git checkout -b [MEMBER_NAME];
2.更新本地仓库$ git add .
$ git commit -m”your comments”
// 多次提交后完成了一项新的功能，自己的分支下能正常运行
$ git checkout dev
$ git merge --no-ff [MEMBER_NAME]
// [MEMBER_NAME] 是自己的分支名称
$ git push
3.更新 .gitignore 文件$ git checkout dev
// 更新忽略文件
$ git add .
$ git commit -m“更新.gitignore文件”
$ git push
4.常用查询命令$ git branch
// 查看自己所在分支 以及自己所拥有的分支
$ git log --pretty=“%h - %cn(%ci): %s” --graph
// 查看自己的提交记录
$ git reflog
// 查看自己的操作历史
$ git status
// 查看本地仓库当前的文件状态
$ git blame [FILE_PATH]
// 查看文件的每一部分最后由谁改动
5.意外情况处理意外：推送代码到远程 dev 分支时发生冲突。解决方案：先把 远程仓库的 origin/dev 分支拉取下来，解决冲突文件后再推送。平时的时候尽量避免不同组员更改同一个文件。$ git push
// 遇到错误
$ git pull
// 解决冲突
$ git add .
$ git commit -m”solve conflict:由于XX原因出错，修改XX文件解决问题”
$ git push
意外：不小心把自己的工作成果push到了master分支。解决方案：先对master进行回退，再使用git push -f将错误的提交删除。意外：错误地把文件添加到git仓库并推送到了远程。解决方案：先将文件从git仓库中移除，但是保留工作目录中的对应文件。然后将该文件添加到忽略文件中，再重新进行提交。命令如下：$ git rm --cached [FILE_PATH]
// 将该文件添加到 .gitignore 文件
$ git add .
$ git commit -m"detach file XXX"
$ git push
三、预发布责任人 & 版本修复责任人1.预发布责任人当需要发布新的版本时，预发布责任人：基于最新的 dev 分支创建一个 release-版本号 分支进行修缮工作合并到 dev 分支合并到 master 分支打标签删除 release-版本号 分支$ git checkout dev
$ git pull
$ git checkout -b release-1.2
// 进行修缮工作
$ git checkout dev
$ git merge --no-ff release-1.2
$ git checkout master
$ git merge --no-ff release-1.2
// 在评论中写入相比上个版本新增的功能，修复的bug等详细内容
$ git tag v1.2
$ git branch -d release-1.2
使用 git show [TAG_NAME]可以查看标签对应的提交信息。2.版本修复责任人当新发布的版本发现 bug 时，版本修复责任人：基于最新的 master 分支创建一个 hotfix-版本号 分支进行debug工作合并到 master 分支打标签合并到 dev 分支删除 hotfix-版本号 分支$ git checkout master
$ git pull
$ git checkout -b hotfix-1.2.1
// 进行修缮工作
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag v1.2.1
$ git checkout dev
$ git merge --no-ff hotfix-1.2.1
// 在评论中写入修复的bug等详细内容
$ git branch -d hotfix-1.2.1
3.意外情况处理意外：某组员完成自己的任务后合并到 dev 分支，推送时发现 release 分支的修缮工作更改了自己原来的文件，产生了冲突。解决方案：把 origin/dev 分支拉取下来，将冲突解决后再次提交。(注意这里解决冲突后 master 分支上的文件与该组员的工作成果依旧是有冲突的。除非该组员解决冲突时不更改 relese 时的修缮代码，而仅仅更改自己的代码来解决问题。因此，一旦有冲突产生，最好双方进行合理交流达成一致意见。减少冲突。)四、成员远程仓库当某个团队成员希望其他成员协助完成他的编程任务时，该成员可以为自己的本地仓库创建一个远程仓库作为成员远程仓库，方便其他成员协助。建立成员远程仓库可以避免中心远程仓库的代码交流繁杂混乱。成员远程仓库在在操作上是中心远程仓库的简化版。仅在细微处有所不同。1.求助者创建成员远程仓库添加成员远程仓库推送自己的分支到成员远程仓库的 master 分支拉取成员远程仓库的 master 分支到自己的分支$ git remote add [ALIAS_NAME] [GIT_ADRESS]
$ git push [ALIAS_NAME]
[BRANCH_NAME]:[BRANCH_NAME_REMOTE]
$ git pull
举例：$ git remote add binRepo https://coding.net/chenbin/GitTest2.git
$ git push binbin
binRepo:master
//由于是第一次推送，该操作已经使得分支binbin 跟踪了远程分支 binRepo/mastr
当某个分支 a 跟踪了远程分支 b，即 b 成为 a 的默认拉取来源，也因此，一个本地分支同一时间只能跟踪一个远程分支。让本地某分支跟踪远程分支的命令$ git branch -u [REPO_NAME]/[REMOTE_BRANCH_NAME] [BRANCH_NAME]
// git branch -u binRepo/master binbin
2.协助者克隆成员远程仓库在 master 分支基础上创建自己的分支 member*在自己的分支上修改代码合并到 master 分支后推送到成员远程仓库$ git clone https://coding.net/chenbin/GitTest2.git
$ git checkout -b member1;
//修改代码
$ git add .
$ git commit -m"我帮你把XX功能完成了"
$ git checkout --no-ff merge member1;
$ git push
一个功能一个分支...... 买，买，买，PM负责Jira，我一个人就完成git，build 和 deploy (Dev Integration Environment) JIRA, Agile boardJIRA, development logsJIRA, development logsStash, Commits history:Bamboo Auto-build: Bamboo Auto-build: Octopus Deploy:
除了上面说的。才5个人，提交的代码就会冲突，说明大家修改了相同部分的源码，这就说明了这五个人的分工是有问题的，应该检讨一下研发的分工和管理。
说到分支，微软里面就有不同的态度。SQLServer认为，一个功能需要一个分支，你们几个人慢慢写，写到最后merge进去就好了。当然merge起来比较痛苦。Office认为，分支是什么能吃嘛，我们所有的人都在同一个分支上干，merge的痛苦分散到了每次checkin里面，build不过系统自动把你的checkin给删掉发邮件让你重来。说实话两种方法都运转的很好，所以其实并没有谁更加好的问题。所以，你们还是把心思花在提高你们的编程技术吧，不要浪费时间在这些无谓的问题上。
架jenkins，写好单元测试，开发在develop branch，每次checkin触发jenkins任务跑测试，不过不让checkin。定期合入master branch，记得打tag。
因为Merge本身风险其实蛮大的，所以一般建议在Trunk做日常开发，等到版本维护的时候，为版本新开Branch。
谢邀。个人观点是由于沟通过程不及时，事后反馈，很容易推翻之前的决定。建议LZ可以看看官网,我们团队在用的，非常好用。希望可以帮到你
没有conflict也叫merge吗？建议搭个Gerrit吧，默认是cherry-pick，冲突少一些。
已有帐号？
无法登录？
社交帐号登录