git最佳实践
概要
git日常最佳实践
日常四步走
- 第一步，根据task创建对应的branch
- 第二步，在新建的分支上编码，push代码到远程分支上
- 第三步，创建pull request, 进行code review
- 第四步，合并代码到master，并删除之前创建的branch
- 第一步，根据task创建对应的branch
我们不应该直接在master上进行新的task的编码工作，尤其是在团队成员较多的情况下。团队的每个成员都应工作于自己新创建的branch上，而不会操作master分支，这样做的好处在于master始终处于一种“干净”的状态，不会因为多人的同时操作而造成过多的冲突，同时也降低了master被误操作的可能性。
具体的操作如下：
//切换到master分支；
git checkout master
//拉取master远程分支的代码；
git pull origin master
//创建新的分支并切换到新的分支上。
git checkout -b <my branch name>
- 第二步，在新建的分支上编码，push代码到远程分支上
分支创建完毕之后，我们就可以开始在branch上进行编码了。这是我们完成task的最主要的阶段，绝大部分的工作在此阶段完成，同时它应该也是持续时间最长的阶段。它的主要任务就是完成task的编码工作，并最终将代码push到当前分支对应的远程分支上去。
首先看一下这个阶段Git工作的命令流，示例如下：
//创建新的branch后的第一天工作结束时，首先将改动的代码放入index区；
git add .
//然后提交代码到本地仓库；
git commit -m "The first commit message"
//第二天开始工作前，切换到master分支；
git checkout master
//从master的远程分支拉取代码；
git pull origin master
//切换到task所在的本地分支；
git checkout <my branch name>
//将master上的最新的代码合并到当前分支上，这里的-i的作用是将我们 当前分支之前的commit压缩成为一个commit，这样做的好处在于当我们之后创建pull request并进行相应的code review的时候，代码的改动会集中在一个commit，使得code review更直观方便；
git rebase -i master
//第二天工作结束之后，将第二天的改动放入index区；
git add .
//提交代码到当前branch的本地仓库；
git commit -m "The second commit message"
//第三天开始工作前，
git checkout master //同上第二天
git pull origin master //同上第二天
git checkout //同上第二天
git rebase -i master //同上第二天
//第三天工作结束之后，
git add . //同上第二天
git commit -m "The third commit message" //同上第二天
..........
//最后，当task的所有编码完成之后，将代码push到远程分支。
git push --set-upstream origin <my branch name>
通过以上的工作流可以看出，我们在完成task期间所有的代码都始终存放在我们新创建的branch的本地仓库上。只有当所有的编码工作完成之后，才会将最终的代码push到当前分支的远程仓库。这样做的好处在于，我们push到远程的代码，也就是之后会通过pull request被code review的代码，始终是针对一个单独task的完整代码，这将有利于之后code review的执行。不过这样做同时可能会存在一个缺点，那就是最终一次push的代码可能会非常庞大，这就要求我们对于task粒度的把握应该更合适。我们不应针对一个非常大的task创建branch，完成编码，而是应该尽可能的将task分解成一个个粒度较小的子task，进而针对子task创建branch完成编码的工作。这是一项非常有技巧的工作，需要丰富的实践经验，它也不是本节要讨论的内容，不再赘述。
- 第三步，创建pull request, 进行code review
当所有的代码都已经被push到远程分支后，这时我们还不可以将代码合并到master上去，我们应该要做的是创建pull request。pull request的作用在于它可以使得代码在merge到master分支之前，能够被团队成员code review，从而提高代码的质量以及降低出错的概率。实际项目中我们使用jira来帮助我们创建相应的pull request，当然Github本身就具备创建pull request的功能。创建pull request的操作非常简单，无非就是点击创建pull request的按钮，填写comment信息，并输入可以进行code review的成员名称。当pull request创建完成之后，所有可以进行code review的团队成员都会收到邮件通知，并通过相应的pull request的链接查看代码的改动，从而完成code review的工作。这个步骤没有实际的Git指令的操作。
- 第四部，合并代码到master，并删除之前创建的branch
当所有的reviewer都结束了code review，且都已经将pull request标注为approved状态的时候，我们就可以将branch合并到master上去，并最终push到远程master分支。示例如下：
git checkout master //切换到master分支；
git merge <my branch name>//合并之前创建的分支的代码到master分支上；
git push origin master//将master的代码push到master的远程分支；
git branch -d <my branch name>//删除之前创建的分支。
经过以上四个步骤之后，一个task的 Git的工作流就结束了。之后，我们可以愉快的开始下一个task了～～
git代码提交到多个远程仓库
起因：新建了备用库
两种方案
1、提交到同一个远程主机的多个地址
2、提交到不同的远程主机
- 方案一：同一主机的两个地址。配置文件
.git/config示例如下
[remote "origin"]
url = ssh://gradle仓库地址
url = http://gitlab仓库地址
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
可以使用命令操作git remote set-url --add origin gitlab仓库地址。
建议直接修改.git/config
- 方案二：两个远程主机。
配置文件.git/config示例如下
[remote "gradle"]
url = ssh://gradle仓库地址
fetch = +refs/heads/*:refs/remotes/gradle/*
[remote "gitlab"]
url = http://gitlab仓库地址
fetch = +refs/heads/*:refs/remotes/gitlab/*
[branch "master"]
remote = origin
merge = refs/heads/master
[alias]
publish=!sh -c "git push gradle master && git push gitlab master:master"
修改配置文件或者使用命令git remote add <主机名> <网址>均可。
命令示例：remote add github git@github.com:XXXXXXXXX
查看结果：git remote show github
推送命令：git push github master
*说明：
- 在没有特别要求时第一种配置方式更简洁。前提是在备份仓库建立同名的分支。
2.[alias]自定义publish命令
2.git publish提交到所有主机；git push gitlab master提交到gitlab主机的master分支 *
git提交忽略设置
两种情况
1、不提交到git
2、已提交到git的文件，保持本地与git不同版本
第一种情况，有些文件不能提交到git上，比如编译文件，还有某些敏感信息的文件，或者开发工具生成的文件等。通过配置 .gitignore文件来解决。示例如下：
/target
/.settings
/.idea
/gears.iml
/.classpath
/.project
~
~/.m2
.DS_Store
第二种情况，有些配置文件已经提交到了git上。本地的开发环境的配置跟不同，所以不能提交本地的修改。
那怎么办呢，你会发现，已提交到仓库的文件在.gitignore中配置是不奏效的。这时候就要用到以下命令了： git update-index --assume-unchanged test.properties。
想恢复提交，则要使用命令：git update-index --no-assume-unchanged test.properties
更多git命令详解：