在GITHUB上进行团队项目开发教程技术
就项目开发管理而言，很多公司都走的比较慢，很多很多的软件公司在软件项目开发管理方面还不是很前卫，大部分的公司都在用 CVS，SVN 作为版本控制系统，很少有公司使用 GIT 来管理，在 GITHUB 上协同开发项目的团队就更少了。究其原因，可能大家习惯了 Windows 桌面带来的方便，使用 GIT 多少有些不习惯；将项目放在 GITHUB 上要收费，并且有些东西涉及机密，很多公司也不敢这么做。
国外的一些产品比国内的产品更让人感觉到可靠，我想 GITHUB 应该是个有道德的公司，对保护用户数据应该还是做的不错的。我相信，以后会有很多公司都会将项目放到 GITHUB 的私有库上。用过很多的在线产品，印象中做的不错的网站有 126 邮箱，GITHUB 等。这篇文章将完整的讲述如何在 GITHUB 上进行团队项目开发的过程。
在 GITHUB 上进行团队多人项目开发，一般会被公司拉入一个组织，这样你才有权限 Fork 一个项目到自己的账号下。当然，如果你以后离开了这个组织，你 Fork 的代码是否还存在，你提交过的代码是否还可见，本人也不知道会是什么样子，我想 GITHUB 会很好的处理这样的问题。
关于对 GIT 的认知，有一句话说的非常好：“GIT，Every thing is local”。一般情况下，clone 下来的项目都有个主分支，名字叫 master。主分支主要是用来更新代码和创建新分支的，一般不建议对其做任何修改，需要开发一个功能时，直接创建一个新的分支即可。在 master 上需要经常的执行 git pull，保证代码的最新。
有了新的需求后，我们一般先创建一个新的分支。切换到新的分支后，通常开发周期会很长，整个过程中我们会提交很多次，当然，在某些时候一个人可能会同时开发几个功能，需要在不同的分支之间来回切换。当在一个分支上做了修改后，这个时候如果其他的分支的需求更急切，需要切换到另一个分支，可以先将当前的分支的修改提交，不然 GIT 不会允许切换过去。在开发完成一个分支后，一般的，我们要对这个分支的提交做一些整理，合并成一个提交，详细见我的另一篇文章《git使用之rebase合并提交》，然后再将新分支 push 到 GITHUB 远程库上；如果 push 到远程库后，又做了修改和提交，下次 push 的时候需要带上 -f 参数，否则会提示发生冲突。
GITHUB 提供了一个 pull request 功能，这样有个好处，就是全世界的开发者都可以向原项目作者贡献代码。在 Pull Request 之前，我们需要做个 git rebase master 的操作。一般情况下开发周期比较长，大型项目很多人都在开发，在新分支开发完成时，主分支也许进行了很多次的提交，我们新开发的分支已经落后主分支很多次的提交。rebase master 的意思就是将这个分支的所有提交和修改以主分支现在的状态为起点，rebase 的过程其实是临时的产生了一个新的分支，如果文件有冲突，可以使用 git status 查看哪些文件有问题，手动修改好了之后，执行 git rebase --continue 完成 rebase 操作。rebase master 操作成功了之后，通过 git log --pretty=oneline 可以看到新分支的所有提交都移动到了 master 最近一次提交的前面了。最后将新分支 push 到 GITHUB 上，并发出 Pull Request，可以看到此次 pull request 下面有绿色的提示：这个分支可以自动合并，这个时候如果原作者认可，就可以自动合并该分支的代码到主分支。合并了之后，GITHUB 会提示，这个分支已经合并，可以安全的删除了。