# 1.Git

# 1.1 一些Git规则

这里有一套规则要牢记

在功能分支中执行开发工作

• 因为这样，所有的工作都是在专用的分支而不是在主分支上隔离完成的。它允许您提交多个 pull request 而不会导致混乱。您可以持续迭代提交，而不会使得那些很可能还不稳定而且还未完成的代码污染 master 分支

从 develop 独立出分支

• 这样，您可以保持 master 分支中的代码稳定性，这样就不会导致构建问题，并且几乎可以直接用于发布

永远也不要将分支（直接）推送到 develop 或者 master ，请使用合并请求（Pull Request）

• 通过这种方式，它可以通知整个团队他们已经完成了某个功能的开发。这样开发伙伴就可以更容易对代码进行 code review，同时还可以互相讨论所提交的需求功能

在推送所开发的功能并且发起合并请求前，请更新您本地的develop分支并且完成交互式变基操作（interactive rebase）

• ebase 操作会将（本地开发分支）合并到被请求合并的分支（ master 或 develop ）中，并将您本地进行的提交应用于所有历史提交的最顶端，而不会去创建额外的合并提交（假设没有冲突的话），从而可以保持一个漂亮而干净的历史提交记录

请确保在变基并发起合并请求之前解决完潜在的冲突

• 合并分支后删除本地和远程功能分支
  • 如果不删除需求分支，大量僵尸分支的存在会导致分支列表的混乱。而且该操作还能确保有且仅有一次合并到master 或 develop。只有当这个功能还在开发中时对应的功能分支才存在

在进行合并请求之前，请确保您的功能分支可以成功构建，并已经通过了所有的测试（包括代码规则检查）

• 因为您即将将代码提交到这个稳定的分支。而如果您的功能分支测试未通过，那您的目标分支的构建有很大的概率也会失败。此外，确保在进行合并请求之前应用代码规则检查。因为它有助于我们代码的可读性，并减少格式化的代码与实际业务代码更改混合在一起导致的混乱问题

使用 这个 .gitignore 文件

• 此文件已经囊括了不应该和您开发的代码一起推送至远程仓库（remote repository）的系统文件列表。另外，此文件还排除了大多数编辑器的设置文件夹和文件，以及最常见的（工程开发）依赖目录

保护您的 develop 和 master 分支

• 这样可以保护您的生产分支免受意外情况和不可回退的变更

# 1.2 Git 工作流

基于以上原因, 我们将 功能分支工作流 ， 交互式变基的使用方法 结合一些 Gitflow中的基础 (比如，命名和使用一个develop branch)一起使用。 主要步骤如下

针对一个新项目, 在您的项目目录初始化您的项目。 如果是（已有项目）随后的功能开发/代码变动，这一步请忽略

cd <项目目录>
git init

检出（Checkout） 一个新的功能或故障修复（feature/bug-fix）分支

git checkout -b <分支名称>

新增代码变更

git commit -a 会独立启动一个编辑器用来编辑您的说明信息，这样的好处是可以专注于写这些注释说明

git add
git commit -a

（切换至功能分支并且）通过交互式变基从您的develop分支中获取最新的代码提交，以更新您的功能分支

您可以使用 --autosquash 将所有提交压缩到单个提交。没有人会愿意（看到） develop 分支中的单个功能开发就占据如此多的提交历史

git checkout <branchname>
git rebase -i --autosquash develop

如果没有冲突请跳过此步骤，如果您有冲突, 就需要解决它们并且继续变基操作<