如何使用git加入到团队开发

Git是一种分布式版本控制系统，可以高效地处理项目的版本管理，包括跨区域的多人协同开发，追踪和记录文件的历史记录，组织和保护源代码和文档，统计工作量，跟踪记录整个软件的开发过程。

Git的四个工作区域

1	Remote	远程仓库
2	Repository	本地仓库
3	Index	暂存区
4	Workspace	工作区

Remote：远程仓库

位于托管代码的服务器，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改。比起本地仓库，远程仓库通常旧一些，因此本地仓库修改完之后需要同步到远程仓库。

Repository：本地仓库

位于自己的机器，本地仓库保存了被提交过的各个版本，比起工作区和暂存区的内容，它更旧一些。首先是 git commit 同步 index 的目录树到本地仓库，然后通过 git push 同步本地仓库到远程仓库。

Index：暂存区

位于.git目录下的index文件，暂存区会记录 git add 添加文件的相关信息（文件名、大小），不保存文件实体，通过 id 指向每个文件的实体。使用 git status 可以查看暂存区的状态，暂存区标记了当前工作区中那些内容是被 git 管理的，当完成某个需求或者功能后需要提交代码，第一步就是通过 git add 先提交到暂存区。

Workspace：工作区

即进行开发改动的地方，是当前看到的，内容也是最新的，平常开发就是拷贝远程仓库中的分支，基于该分支进行开发，在开发的过程就是在工作区的操作。

Git 的工作流程

不同工作区在实际开发中的应用场景

在实际的开发过程中，具体的流转流程如下所示：

• 使用git clone命令拉取远程仓库到本地
• 使用git checkout命令，切换到你要开发的分支。一般不在原分支中作修改，而在稳定的分支上新建分支进行操作
• 修bug，就在稳定的分支上新建fix分支
• 新功能，就在稳定的分支上新建feature分支。在新分支上进行编码和测试操作
• 使用git add 和 git commit命令来将所作的更改提交到本地仓库，每一次使用commit命令都会产生一条提交日志。
• 使用git push命令将分支推送到远程分支之上
• 待其他Review之后，将分支合并到稳定分支上

git分支开发规范

分支命名

master 分支

master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性
master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码

develop 分支

develop 为开发分支，始终保持最新完成以及bug修复后的代码
一般开发的新功能时，feature分支都是基于develop分支下创建的

feature 分支

开发新功能时，以develop为基础创建feature分支
分支命名: feature/ 开头的为特性分支， 命名规则: feature/user_module、 feature/cart_module

release分支

release 为预上线分支，发布提测阶段，会release分支代码为基准提测
当有一组feature开发完成，首先会合并到develop分支，进入提测时，会创建release分支。
如果测试过程中若存在bug需要修复，则直接由开发者在release分支修复并提交。
当测试完成之后，合并release分支到master和develop分支，此时master为最新代码，用作上线。

hotfix 分支

分支命名: hotfix/ 开头的为修复分支，它的命名规则与 feature 分支类似
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支

常见任务

增加新功能

遇到新需求时，即可在develop开发分支上直接编程、测试、推送，也可以新建分支完成该需求。具体分情况讨论，建议新开分支操作，避免与其他同事的提交代码产生冲突。
如果新开分支，则一定要在稳定的分支上完成新建操作。
如果develop分支上所有的代码都是经过测试的稳定代码，那么可由该分支新建feature分支。
如果develop分支上存在尚未测试的代码，那么建议从master或者release分支上下载稳定的代码进而新建feature分支开发。

(dev)KaTeX parse error: Expected 'EOF', got '#' at position 42: …xxx #̲ 从dev建立特性分支 (fe…: blabla # 开发
(feature/xxx)$:gitaddxxx(feature/xxx)$: git commit -m ‘commit comment’
(dev)$: git merge feature/xxx --no-ff # 把特性分支合并到dev

修复紧急bug

• develop分支存在BUG。如果仅仅是该分支存在BUG，而master和release分支不存在bug，那么可直接在该分支新建fix分支，待修复bug后，将该分支合并到develop分支，然后删除该fix分支。
• 若master分支或release分支存在bug，那么需要回顾下develop分支是否有相同的bug。然后基于master分支新建fix分支，后将该fix分支分别合并到master分支和develop分支上。
  总结：如果是新需求，那么在稳定的分支上新建feature分支，如果是线上bug，那么在线上环境所在分支上新建fix分支，待开发测试完成后，分别合并到master分支和develop分支上即可。

(master)KaTeX parse error: Expected 'EOF', got '#' at position 38: …ix/xxx #̲ 从master建立hotfi…: blabla # 开发
(hotfix/xxx)$:gitaddxxx(hotfix/xxx)$: git commit -m ‘commit comment’
(master)KaTeX parse error: Expected 'EOF', got '#' at position 38: … --no-ff #̲ 把hotfix分支合并到ma…: git merge hotfix/xxx --no-ff # 把hotfix分支合并到dev，同步代码

测试环境代码

(release)$: git merge dev --no-ff # 把dev分支合并到release，然后在测试环境拉取并测试

生产环境上线

(master)KaTeX parse error: Expected 'EOF', got '#' at position 38: …no-ff #̲ 把testing测试好的代码…: git tag -a v0.1 -m ‘部署包版本名’ #给版本命名，打Tag

日志规范

在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。

编写良好的Commit messages可以达到3个重要的目的：

加快review的流程
帮助我们编写良好的版本发布日志
让之后的维护者了解代码里出现特定变化和feature被添加的原因

Commit messages格式要求

# 标题行：50个字符以内，描述主要变更内容
#
# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
#
# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
# * 他如何解决这个问题? 具体描述解决问题的步骤
# * 是否存在副作用、风险? 
#
# 如果需要的化可以添加一个链接到issue地址或者其它文档

总结：master和release分支不可直接更改，只能通过分支合并的方式来变更。日常开发一般在develop分支、deature分支和hotfix分支上工作。

• master分支。用于部署到生产环境，一般由 release 或 hotfix 分支合并，不允许直接在 master 分支上修改代码
• release分支。预上线分支，一般由 develop 或 hotfix 分支合并，不建议直接在 release 分支上直接修改代码。
• develop分支。测试分支，一般用于测试环境中。始终保持最新完成以及 bug 修复后的代码。
  若开发时间短，可直接在该分支进行开发、测试，在测试完成后直接推送到远程仓库。
  若开发时间较长，则需在该分支上新建feature分支，待feature分支开发、测试完成后，推送到远程仓库，利用分支合并功能，合并该分支到develop分支上。
• feature分支。该分支为需求开发分支，命名规则为 feature- 开头，一旦该需求上线，便将其删除。
• hotfix分支。当线上出现紧急问题需要马上修复时，需要基于 release 或 master 分支创建 hotfix 分支，修复完成后，再合并到 release 或 develop 分支，一旦修复上线，便将其删除。

git命令

git merge 合并冲突

当想要合并的两个分支的同一文件中的同一行代码上有不同的修改，或者一个分支删除了一个文件而另一个分支修改了这个文件时，Git 就会产生分支冲突。在这样的情况下，Git 会询问你想要保留哪种选择？

git merge在使用的时候，有以下两种合并场景

• fast-forward模式，fast-forward！这类合并不会创建新的提交，而是会将我们正在合并的分支上的提交直接合并到当前分支。即合并的结果不会产生结，而会形成一条直线。

• No-fast-foward (—no-ff)。Git 会在当前活动分支上创建新的 merging commit。这个提交的父提交（parent commit）即指向这个活动分支，也指向我们想要合并的分支！即会产生分支合并的结

git rebase 变基操作

使用场景一： 不同分支进行rebase操作

开发者在feature分支上开发新功能，而此时master分支上同事推送了新的代码，因此如果feature分支需要获得master分支的代码只有两种形式。

git merge。将master分支的变更合并到当前的feature分支上，这大会产生合并的结，使你feature分支的提交不清晰。不推荐
git rebase。 该命令会将master分支的变更同步到本地，同时，修改你feature分支的基础commit。

总结：在进行分支合并时，feature分支合并到develop分支/master分支时，建议使用git merge。而master分支/develop分支的变更合并到feature分支时，推荐使用git rebase。这会使提交历史更清晰。

使用场景二：同一分支进行rebase操作，实现压缩commit

日常在feature开发工作中，往往会稍作一点变更就git commit提交该变更，然而当该feature分支合并到develop分支时，会导致大量的develop的分支历史及其不清晰。因此，需要压缩commit，将所有的commit合并为一条，然后再向develop分支提出分支合并请求。

git rebase -i HEAD~3 #整理HEAD附近3条的commit记录
git rebase -i $COMMIT_ID #整理指定COMMIT_ID之前的所有commit记录
上述命令会进入到一个交互式的编辑界面
将除第一条以外的commit都改为squash即可将所有的commit合并到第一条记录中。

另：如果当前commit历史较为复杂，并非一条直线时，该命令将会产生冲突，无法达到合并commit的结果。故建议下游更新上游代码时，使用git pull --rebase，或者 git fetch + git rebase的操作，使下游分支提交历史较为清晰。不然在合并commit时会遇到麻烦。

实际开发场景如何应用git

1、 将团队的代码库下载到本地

此处分为两种场景。

对团队的代码库有开发权限，那么可直接使用git clone命令将代码库下载到本地
对团队的代码库没有开发权限，那么需要先fork团队的仓库到自己的仓库中，接着克隆自己的仓库到本地

在本地进行编码和测试工作

新建分支。在稳定分支上（develop分支/master分支/release分支，具体问导师）新建开发分支(feature分支/fix分支)。–> git checkout
在新建分支上进行编码和单元测试工作。–> git add && git commit
将单元测试后的代码分支推送到远程仓库。–> git push
a.如果出现了冲突，需要先用git fetch命令，将远程仓库拉下来
b. 使用git merge命令合并冲突
c. 使用git push 再次推送。
d.也可直接git pull(直接进行了git fetch 和git merge操作)， 然后git push。

在github上发起PR/gitlab上发起MR，请求别人review自己的代码，然后将自己的代码合并到测试分支(develop分支)上。
将develop分支的代码应用到测试环境中，如果有问题则回退到第2步继续进行开发
将develop分支测试稳定的代码，提交PR/MR到稳定分支(master/release)上，进而在生产环境中应用该代码。

在发起PR/MR时，要求提交历史仅有1个

使用git rebase命令
使用git reset命令

开发进行一半，需要同步远端主分支的最新代码

git status 查看当前项目的状态，如果有未保存的修改，就git add . 和 git commit -m $message保存下来
git pull --rebase origin develop 使用这个指令将远端的主分支以 rebase 的形式 “合进”当前分支
也可使用git fetch + git rebase的形式

git log 查看当前分支下的 commit message 是否符合预期
总结：下游需要上游代码，使用git rebase获取上游最新代码，进而保证下游分支提交历史清晰、简洁。