git常用命令和版本管理实例

总结一下常用的几个git命令：

1. 拉取远程仓库：git pull

2. 本地修改的代码推送到stage区域：git add .

     说明：也可以在add后面加上文件名，只推送该文件到stage

3. 提交代码到本地仓库：git commit -m "注释信息"

4. 推送本地仓库代码到远程仓库：git push

5. 在远程仓库新建分支，并推送本地仓库代码：git push origin develop:Test   

     说明：在远程仓库新建Test分支，将本地develop分支的代码推送到新建的分支

6. 查看本地分支：git branch

7. 查看远程分支：git branch -a

8. 切换分支：git checkout Test

9. 查看历史日志：git log

10. 回退本地的修改：

      git clean -df        只删除untracked的文件，不会回退已经tracked的文件

      git reset --hard   把tracked的文件回退到前一个版本，对untracked的文件不会删除

 

下面举一个版本管理的例子：

限制：远程develop分支只有几个leader有权限，三组人同时进行开发并各自建立分支A，B，C。同时还有bug修复小分队不停地合入代码到develop。

平时各组分别维护自己的分支很简单，冲突很少，提代码比较容易。然而一到部署就头大了，大家要集中在一两天把自己代码合入develop。

应该怎么办呢？以A组为例（前提条件各组以develop分支为基础创建的A，B，C分支）：

step1：切换代码分支到本地的develop，git checkout develop

step2：拉取代码到本地develop，git pull

step3：把本地develop的代码merge到本地的A分支， git develop A

step4：解决merge的冲突后，切换回到A，并提交代码到本地A分支，

            git checkout A

            git add.

            git commit -m "xxxxxxx"

step5：提交代码到远程A分支，git push   

step6：在github上提交pull request （A --> develop），等待批准merge

 

个人心得：

大团队开发最好不要采用上述方式进行版本管理，否则会浪费时间来提交代码和解决冲突，而且不利于dev环境部署，也不利于多组联调测试。

大团队可以根据上线版本分别创建分支，比如：为版本R50建立分支R50，为版本R51建立分支R51。。。每个人都可以在对应的版本上fork自己的分支，大家可以随时提交代码到同一时间上线的版本，有利于部署到dev环境测试，并及时发现别人的修改对自己的影响。但这种方式也有不好的地方，对于生产环境上需要及时修复的bug只能修改到当前生产环境的版本中，同时需要同步代码到其他版本中。

当然也有Devops做得非常好的团队，每天都可以发布版本，所以不存在代码管理混乱的问题。