关于工具

@kezhen 2016-06-07T16:35:08.000000Z 字数 1851 阅读 1341

团队开发中，遵循一个合理、清晰的Git使用流程，是非常重要的。否则，每个人都提交一堆杂乱无章的commit，项目很快就会变得难以协调和维护。

1. 工具: Git可视化工具SourceTree、合并代码工具BeyondCompare
2. 配置SourceTree：使用rebase替代merge，不使用fast-forward；Diff外部工具选择：BeyondCompare

打开终端，执行下列命令配置对比工具。

ln -s /Applications/Beyond\ Compare.app/Contents/MacOS/bcomp /usr/local/bin/

3. 如何拉取远端分支到本地进行开发？
从远端仓库拉取代码时，有两个选项要认真看清楚：要拉取的远程分支和拉取到本地分支。如果远端有一个fix1分支，我们需要在本地创建一个分支（最好是和要拉取的远端分支同名，因为推送时会默认采用本地分支的名字推送到本地名字的远端分支），这个分支是从远端fix1指向的分支分出来。
4. 开发者删除一个远端分支后，其他开发者如何刷新远端分支？
- 点选抓取，勾选删掉在所有远端都已经不存在的跟踪(tracking)分支后确定即可
5. 发生冲突时，如何使用外部工具进解决？

关于 `rebase` 和 `merge`

merge
团队的开发模式是本地的branch和远端的branch会同步地非常频繁，这两个branch几乎是完全同步。这时候就会发现这些merge动作其实没有必要，会造成线图错综复杂。

Rebase大致操作：
- 1. 把本地的repo从上次 pull 之后的的变更暂存起來
- 2. 返回到上次 pull 时的情況
- 3. 套用远端的变更
- 4. 最后再套用刚才暂存下来的变更。

合并之前示意图：

      D---E master
     /
A---B---C---F origin/master

使用 merge 合并示意图：

      D--------E  
     /          \
A---B---C---F----G   master, origin/master

使用 rebase 的方式，就不會有 G 合并点：

A---B---C---F---D'---E'   master, origin/master

注意到，其中 D’, E’ 的 commit SHA 序号跟本來 D, E 是不同的，因為算是砍掉重新 commit 了。

关于使用时遇到conflict的情况：
merge 如果发生 conflict，你只需要解決衝突一次；rebase 如果发生 conflict，你需要解决冲突多次。

分支策略

Master

master：代码库应该有且只有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。

Git主分支的名字，默认叫做master。

Develop

develop：日常开发分支，干活都在dev分支上。

如果想正式对外发布，就在master分支上，对develop分支进行"合并"（merge）。

Fix

fix：软件正式发布以后，难免会出现bug。这时就需要创建一个分支进行bug修补。
fix

修补bug分支是从master分支上面分出来的。修补结束以后，再合并进master和develop分支。它的命名，可以采用fixbug-*的形式。

Feature

feature：功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop并删除该分支。

功能分支的名字，可以采用 feature-*的形式命名。

所以，团队合作的分支看起来就像这样：

Commit规范

1.格式

<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>

2. Type

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

3. Scope

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

4. Subject

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

5. Body

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

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