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

最新推荐文章于 2024-04-27 17:13:24 发布

粥粥同学

最新推荐文章于 2024-04-27 17:13:24 发布

阅读量3.8k

点赞数 19

分类专栏： Linux命令学习文章标签： git

本文链接：https://blog.csdn.net/gui951753/article/details/119304320

版权

Linux命令学习专栏收录该内容

2 篇文章 2 订阅

订阅专栏

文章目录

引言
基本概念
基础命令
实际开发场景如何应用git
Reference

引言

刚刚进入团队的同学往往并不能很快适应团队化的开发，为了减少团队新同学的学习成本，本文将介绍git版本控制工具。值得注意的是，本文并非大而全的git说明文档，本文只是将工作中常用到的使用场景和命令提取出来，进而帮助团队新同学快速成长。

基本概念

git四个基本工作区域

在git中分为四个基本工作区域：
Workspace：工作区，就是你平时存放项目代码的地方
Index / Stage：暂存区，用于临时存放你的改动
Repository：仓库区（或版本库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本
Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中的一台电脑用于远程数据交换

四个基本区域的流转如图所示。
在这里插入图片描述

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

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

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

git分支开发规范

git中常见的分支包括以下几种分支，如图所示：
在这里插入图片描述

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

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

分支开发应用场景

遇到新需求

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

修复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分支上即可。

git commit 开发规范

日常开发中的每一次代码变更，都需要利用git commit命令来记录变更，为了使代码变更清晰易懂，应该使用一定的规范来commit的内容。

推荐的git commit提交格式

<type>(<scope>): <subject>

type [必须]。
用于说明git commit的类别，只允许使用下面的标识。
feat：新功能（feature）。
fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
docs：文档（documentation）。
refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
perf：优化相关，比如提升性能、体验。
test：增加测试。
chore：构建过程或辅助工具的变动。
revert：回滚到上一个版本。
merge：代码合并。
sync：同步主线或分支的Bug。

scope [可选]。说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同

subject [必须]。subject是commit目的的简短描述，不超过50个字符，可以是中文描述

commit 规范示例：

fix(DAO):用户查询缺少username属性
feat(Controller):用户查询接口开发

基础命令

知道了基本概念之后，在实际开发过程中需要掌握具体的命令和工具来将git应用到实际开发过程中，此处将介绍工程开发中常用的若干命令。此处的脑图为了方便记录常用的命令，然而本文并不会介绍所有的命令，尤其是基础的命令，只会介绍在开发过程中经常用到的不太好理解的命令。

在这里插入图片描述

强烈建议看Reference中的git 命令10大命令图解。

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。建议看Reference中的动图。 该命令会将master分支的变更同步到本地，同时，修改你feature分支的基础commit。

rebase前
在这里插入图片描述

rebase后
在这里插入图片描述

总结：在进行分支合并时，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 reaset 版本重置

当开发者不想要之前提交的修改时，就会用到这个命令。重置又分为软重置和硬重置。

软重置：

软重置会将 HEAD 移至指定的提交（或与 HEAD 相比的提交的索引），而不会移除该提交之后加入的修改！

git reset --soft HEAD~2  #还原到两个版本前
git reset --soft $COMMIT_ID #还原到指定版本

另：由于软重置会保留修改的内容，故也可用于合并多个提交为一个提交。具体操作为将git reset重置为自己的首次提交，然后重新使用git commit进行提交。该命令在本地提交历史极为复杂（产生了各种merge的结）时，依然十分有效。

硬重置：
该命令不会保存你提交过的修改，强制使代码回退到之前的某个版本。

git reset --hard $COMMIT_ID

实际开发场景如何应用git

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

此处分为两种场景。

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

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

新建分支。在稳定分支上（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)上，进而在生产环境中应用该代码。