两个人开发一个项目，用的Git做版本控制，两个人同时都有代码要提交到已有的远端仓库里面，这个步骤应该是怎样的呢？
例如下面一个场景该如何处理？（只用了一个分支master）
开发人员1：git clone ...
开发人员2：git clone ...
开发人员1：编码...
开发人员2：编码...
开发人员1：git add -> git commit -> git push (ok)
开发人员2：git add -> git commit -> git push (失败！)
当一个人push成功后，另一个人再push就不可以了。 现在我们的处理办法是，开发人员2重新Clone一次，手动增加代码，再提交，push。但是这样做太麻烦了，正确的做法应该是怎样呢？
两个人连git最基本的流程都不知道，而且遇到问题不知道看git给的错误提示，当初是怎么选择使用git的？随大流了吗？
clone是一次性的，之后的开发中对于任何一个人：
- 修改代码
- git add, git commit
- git push
如果git push失败了：
- git pull
- 自动合并修改，如果无法自动合并就手工合并，然后git coomit
- git push
推荐这本书：http://git-scm.com/book/zh
上面的问题使用 git pull 或者 git fetch 就可以解决，如果想更好的使用git的话，
推荐使用 Git Flow，Git Flow算是一套优秀Git分支模型方法论。完全遵守这套规则可以避免常见的问题，带来开发上的流畅体验。 这可以说是 最佳实践
github: https://github.com/nvie/gitflow
相关文章：
开始实践git-flow http://www.jeffkit.info/2010/12/842/
Git flow 開發流程 http://ihower.tw/blog/archives/5140/
http://nvie.com/posts/a-successful-git-branching-model/
git分支管理策略 http://www.ruanyifeng.com/blog/2012/07/git.html
git flow and github flow http://hooopo.writings.io/articles/fe2b0791
说一下你这样的做法两点不好的地方。
1.只有一个master版本。通常我们有两个版本，一个master版本，一个是work版本。
master版本相当于正式版，基本上每次更新都是好几十个文件一起更新的。work版相当于测试版，一般一天更新个20来此很正常。
2.你说的a，b两个人同时提交问题。正常情况下应该是a提交，之后b 合并（merge）a的提交之后，先在本地测试自己的工程是否还能正常工作，最后才是b提交。
第二点是git的灵魂，也是很多人不习惯的地方。git这么设计，最大的好处在于，保证了每一次提交的版本都是可运行的，这样不论你删除某个版本，在整个更新线上都不会有问题。因为以后的版本依然是可以跑的。
所以用git有一个默认的前提条件首先，即所有人提交的版本在自己的本机上都应该是跑的正确的。我这里说的可以跑正确，不仅仅说的是自己修改的代码，还包括合并了其他人的更新之后的。换句话说，每一次的提交，其实都是一个完整性测试。做开发的人都知道，初期的环境配置不管什么项目都是少不了的，开发的时候如果项目都跑不起来，基本上就更不用说修改代码了。所以保持项目的完整性，是非常必要的。
开发人员1：git add -> git commit -> git push (ok)
开发人员2：git add -> git commit -> git pull origin master -> git commit -a -m 'merge'-> git push