团队中的git实践

为了获得软件质量和开发效率的双重收益，软件项目开发早已不再是一个人的事情了，而是一个团队(team)的事情。不但如此，现今的软件开发规模越来越大，所涉及的技术门类也越来越复杂，一个人难以独挑大梁，同时，一个人也难以在短周期内完成复杂项目。团队的意义不仅在于提高开发效率，更能保证开发质量，一人负责一块开发内容就可以用充足的精力和热情使这块内容做的更加完美。
说到团队开发，总是离不开项目管理和版本控制工具，这里我们将会讨论版本控制工具——git在团队中正确实践的姿势。
Git/Github是任何一个非小白程序员都知道或使用的工具/网站，随着软件开发学龄的深入，我自己的体会是越来越离不开这个东西了。一个人用git可以用得随心所欲，但团队中就是另外一回事了。一个人的项目，代码怎么改、怎么提交都不会有冲突，这样也会养成一些不良习惯，把这些习惯带到团队开发中，轻则让队友讨厌，重则酿成大祸（这不是危言耸听）。

1.习惯养成

如果一个团队在使用git时没有一些规范，那将是一场难以醒来的噩梦！然而，规范固然重要，但更重要的是个人素质，在使用git时需要自己养成良好的习惯。

2.提交

Commit Message格式

<type>(<scope>): <subject>
<space>
<body>
<space>
<footer>

上面是一次提交后Message格式规范，分成标题、内容详情、结尾三个部分，各有各的用处。
头部即首行，是可以直接在页面中预览的部分，一共有三个部分, , , 含义分别如下：

Type

- feat: 新功能(feature)
- fix: 修补bug
- docs: 文档(documentation)
- style: 格式(不影响代码运行的变动)
- refactor: 重构(即不是新增功能，也不是修改bug的代码变动)
- test: 增加测试
- chore: 构建过程或辅助工具的变动

Scope

1	用来说明本次提交影响的范围，即简要说明修改会涉及的部分。

Subject

用来简要描述本次改动，概述就好了，因为后面还会在Body里给出具体信息。并且最好遵循
下面三条：
 - 以动词开头，使用第一人称现在时
 - 首字母不要大写
 - 结尾不用句号( . )

Body

1	<body>里的内容是对上面subject里内容的展开，在此作更加详尽的描述，内容里应该包括修改动机和修改前后的对比。

Footer

1	<footer>里主要放置不兼容变更和Issue关闭的信息。

Revert

1	此外如果需要撤销之前的提交，那么本次提交Message中必须以revert: 开头，后面紧跟前面描述的Header部分，格式不变。

在具体开发工作中主要需要遵守的原则就是[使每次提交都有质量]，只要坚持做到以下几点：

提交时的粒度是一个小功能点或者一个bug fix，这样进行恢复等操作时能够将[误伤]减到最低；
用一句简练的话写在第一行，然后空一行稍微详细阐述提交所增加或修改的地方；
不要没提交一次就推送一次，多积攒几个提交后一次性推送，这样可以避免在进行一次提交后发现代码中还有小错误。

加入代码已经提交了，对这次提交的内容进行检查时发现里面有个变量单次拼错了或者其他失误，只要还没有推送到远程，
就有一个不被他人发觉你的疏忽的补救方法——   
首先，把失误修正之后提交，可以用与上次提交相同的Message。   
然后，终端中执行<code>git rebase -i [SHA]</code>，其中SHA是上一次提交之前的那次提交的。   
最后，这样就将两次提交的节点合并成一个，甚至能够修改提交信息。

3.推送

当自己一个人进行开发时，在功能完成之前不要急着创建远程分支。

4.拉取和合并

在将其他分支的代码合并到当前分支时，如果那个分支是当前分支的父分支，为了保持图表的可读性和可追踪性，
可以考虑用 git rebase 来代替 git merge；反过来或者不是父子关系的两个分支以及互相已经 git merge 过的分支，
就不要采用 git rebase 了，避免出现重复的冲突和提交节点。

最后献上一句话

日拱一卒，功不唐捐。