Git介绍

date

Apr 19, 2022

slug

git

status

Published

配置代理

分辨需要设置的代理

HTTP 形式：

SSH 形式：

一、HTTP 形式

走 HTTP 代理

走 socks5 代理（如 Shadowsocks）

取消设置

二、SSH 形式

修改 ~/.ssh/config 文件（不存在则新建）：

设置账号密码

进入.git中，找到config文件

GitLab使用token拉代码

删除所有日志

git checkout --orphan tmp

Git分支

一、前言

看到掘金上，一篇Git相关的文章一千多个点赞把我羡慕的呀。

Git在工作中是很重要的一部分，如果操作不熟练或者使用不规范，很容易给工作造成很多麻烦

比如习惯所有功能写在一个分支，导致无法分开上线

比如提交了依赖目录，导致Git仓库的代码过大

比如合并分支出现错误，将不用上线的代码提交

比如分支命名不规范，导致误删分支

这一篇正好是前端工程化实践的一部分，既然重合了，就写点不一样的内容，基础的就不再过多的写。这篇文章会主要聊聊以下几个方面：

Git的一些使用场景

Git分支命名推荐

Git多人开发分支管理

Git记录提交规范

推荐Git的图形化界面SourceTree及使用方法

一、新同学使用Git常见的一些问题

最近在帮助新同学上手项目的时候，发现他们使用Git时，会有一些小问题，主要是不熟悉，这里提出来讨论下。

1、问题一：对Git概念、操作不熟悉

都见过这样的新手，刚开始启动项目，写好代码后给导师审核，竟然直接压缩代码发给导师，每更新一个版本就打一个包，这就很狂了。

这是典型的对Git不熟悉，有必要通过多看文档，强制自己使用来掌握。其实知道了原理，Git常用的就那几个命令，并不难。

2、问题二：代码合并、冲突和保存代码时没有利用好Git的强大特性

代码合并，容易搞错合并的方向，git merge到底是哪个分支合并到哪个分支，这个是易错点。

合并的时候容易失败，出现冲突或是没有拉取线上最新的代码，导致当前header落后于master，所以合并前一定要先git pull。

3、问题三：分支随便建，信息乱提交

分支虽然不要钱，但审核代码的时间和找分支的时间是要钱的。如果随意起名字，后期修改代码很容易忘记，需要花时间回忆，所以规范分支命名是很必要的。

提交信息随便写，什么test、暂存了，嗯，我也干过，但现在改了。优秀的信息说明要有一定的格式，方便查找历史提交记录，而且赏心悦目。

4、请问你觉得下面哪个代码提交更专业?

其实这些问题的解决并不难，只要态度到位，操作熟练加上点规范，分分钟钟变得优秀。

二、Git使用过程中的常见问题

Git一款分布式版本管理工具，本地安装Git，通过各种命令可以对代码进行拉取、合并、提交等，他也是程序员的基本技能。svn（小污龟）就不说了，写代码用Git准没错。

1、`.gitignore`的配置规则，允许使用正则

.gitignore文件可以让git提交的时候，过滤一些不需要提交的文件或文件夹，比如打包的文件、依赖安装包、编辑器的配置等。具体的过滤规则有：

/build/ 不提交整个文件夹

.zip 过滤所有.zip文件

/docs/do.txt 过滤某个具体文件

!src/ 不过滤该文件夹

具体语法：

以星号*通配多个字符；

以问号?通配单个字符

以方括号[]包含单个字符的匹配列表；

以叹号!表示不忽略(跟踪)匹配到的文件或目录；

从上到下执行，下面的命令会覆盖前面的

2、当前分支功能开发一半，需要终止修复线上Bug，怎么办？

通过git stash指令，保存临时修改的代码到本地，该操作将清空工作区，然后切换分支去处理bug，完成后切回原来的分支，通过git stash指令还原之前的修改，而不是直接提交写一半的代码到暂存区。

3、git冲突处理

在合并代码的时候出现冲突很正常，合并冲突也很简单，但也很容易搞混，那么出现了冲突，我一般会通过VSCode去解决，现在我们使用两个分支同时改一个地方，然后合并代码制造冲突，并解决它。

可以看到出现的冲突，在VSCode中看到提示，然后选择上面的选项处理冲突，如果两者对比不明显还可以选择Compare Changes，两栏对比

4、vscode安装插件，实时查看每行代码的修改信息

安装插件：GitLens — Git supercharged，可以展示如下图信息，修改人，修改时间，提交信息，这样就能很清晰的找到代码的作者

三、Git命名和管理规范

1、Git命名规范

Git由于分布式和通过指针定位版本的原理，带来的一个巨大优势就是新建分支的成本很低，既然如此，就要充分发挥分支的用途

首先，项目创建完成后会默认master分支（现在Github改成了main分支），作为生产环境的分支，特别重要的项目，这里可以设置为受保护的分支，只允许管理员操作，这样就能避免代码混乱，当然90%的代码估计都不太需要。

（1）稳定分支

master/main分支：生产环境代码，记录每个版本迭代，保持分支稳定，不能直接修改。

develop分支：开发分支，开发功能需要从当前分支检出，保持稳定，最新版本。

（2）不稳定分支

不稳定分支指的是更新频繁，并且有一定的生命周期。

release分支：预发布分支，当完成一个功能可以创建该分支用于测试，比如release/login release/account

feature分支：功能分支，当需要开发一个功能时，可以创建该分支，开发上线后删除。feature/login feature/register

hotfix分支：生命周期最短，发现bug后临时建立，修复bug后删除。分支命名：hotfix/login hotfix/register

2、开发流程

开发流程和各分支的关系图：

例如：当需要开发新功能登陆页面的时候

从develop分支检出feature/login，经过一段时间开发完毕

需要发布版本测试，此时从feature/login创建release/login，部署该分支代码，进行测试

测试中的bug，在feature/login修复，然后合并release/login分支，提交第二个测试版本，第三个测试版本等

测试通过后，合并release/login到develop分支

确认没问题，合并master分支，部署上线

删除feature/login release/login分支

当需要修复线上登陆页面bug的时候

从master分支检出hotfix/login，修复完成，合并master分支，验证没问题

合并develop分支

删除hotfix/login分支

这里根据实际开发需求，对网上常见的工作流进行了修改，具体差别往下看

3、实际工作中

（1）网上常见的分支管理和这里的区别

在查阅资料的过程中，发现很多分支管理如图所示，但在实际使用的过程中有个问题。

功能是不断迭代的，多人开发不同的功能，完成的先后顺序不一样，那么完成的功能合并到develop后再拉取预发布分支，容易将其他人的功能分支代码合并到一起，这样就会导致上线一些不应该上线的代码。

当然这里你也可以在不同的节点去处理，按版本号的方式检出预发布分支，但终究是容易混淆，因为很多版本的需求都是老板按心情提的，并不确定。

所以这里我首先不会去合并feature分支到develop，首先直接检出预发分支，然后测试迭代，最终没问题合并develop分支。

上线的时候可以选择合并develop到master也可以合并feature、release到master，都是可以的。

这里如果有不同的意见，欢迎交流。当然你也可以直接使用SourceTree获Gitlab等自带的分支管理策略。

（2）阉割版的分支管理

其实上面的分支管理策略已经很优秀了。

但是对于很多公司内部的项目而言，可能没有那么正式的分类。

比如一个内部项目，多人同时开发，基本每个人负责一个功能，然后还要负责修复线上的bug，预发环境只有一个，可能同时测试，那么这时候，搞那么多的预发布分支，切来切去好麻烦。

这时候，我会推荐阉割版的分支管理办法

master 和 develop 分支作为稳定分支不变，其他的分支命名格式：名字前缀/分支名称

张三要开发登陆功能：zs/feature-login

张三要修获取用户信息bug：zs/bugfix-userinfo

李四要开发注册功能：ls/feature-register

这样每个人的分支就很清楚了，而且不容易误删，也能分辨分支的作用，缺点是分支名字有点长。

三、Git信息提交规范

代码提交规范，其实重要性没那么高，只会在代码review和历史数据查询的时候使用，但规范的提交可以帮助你更好的记录代码的更新。

四、Git图形化工具推荐

Git有很多优秀的图形管理工具，比如SourceTree和SmartGit，这些工具帮助我们更容易对分支和更新内容进行操作，这里强烈安利这款工具，帮你不必使用Git命令行工具，一行行的输入命令，通过界面点击就可以实现这些操作命令。

这里我推荐SourceTree，他有以下优缺点：

首先免费，其次操作简单。

展示内容详细，实时监控代码的更新，不论远程仓库还是本地的变更

可以一个代码块一个代码库进行回滚操作

展示提交的历史信息和各个分支之间的关系

安全，不允许你删除没有合并的分支，除非你强制删除

缺点也有：对比命令行，有点慢，但不影响使用，毕竟他执行的命令更详细。

一、安装

下载地址：SourceTree

二、配置用户信息

1、配置用户名和电子邮件地址，作为后面提交代码的信息展示

2、SSH客户端配置

首先需要本机安装Git，并生成key，具体生成方式和服务器命令行一样。

生成key的方法这里有两种，不同系统有差别，都可以使用Git bash操作

1、通过Git命令行生成，具体过程可以参考章节Git生成sshkey

2、通过SourceTree，ssh助手生成key

通常Windows的key都在User\user.ssh\id_rsa下，选择协议使用OpenSSH

Linux电脑的key一般存在root/.ssh 目录，其中一个公钥一个私钥。

Mac的key一般存在/home/.ssh目录

三、创建或引入一个项目

1、添加已经存在的本地仓库，将本地的Git仓库用SourceTree管理起来

2、创建远程仓库，SourceTree 帮助你直接创建远程仓库

3、从URL克隆，相当于git clone，只要有项目地址就可以将项目clone到本地

4、添加本地已经存在的本地仓库，如果你本地有个git项目，那么你可以直接引入

5、创建本地仓库，选择一个不是仓库的文件夹，创建一个git仓库，相当于git init

6、这样我们就可以通过SourceTree使用git命令操作项目了。

7、引入成功后，是这个样子

四、工作区域说明

SourceTree 整个界面分成了多个区域，这里我们重点介绍下这6个区域，也是我们常用的地方

第一个工作区，最上面的部分，主要是Git的常用操作，包括

提交（git add）

拉取（git pull）

推送（git push）

获取（git fetch）

分支（git branch、git checkout、git push -d branch）

合并（git merge）

贮藏（git stash）

Git工作流，主要是自动创建不同的分支流程，帮助多人合作开发管理分支，类似我们章节分支管理中的内容

远端：点击展示当前项目远程仓库信息，提供git remote -v 和修改删除的功能

命令行模式，window下快速打开bash命令行

设置远程仓库配置和Git配置信息设置

这个区域有个很厉害的地方，只要线上代码更新，就会提示你当前版本落后的版本数，提醒你及时拉取代码，而不用每次都去使用命令拉取一下。

第二个工作区(WORKSPACE 工作区信息)

文件状态，主要展示当前项目你追踪的修改、删除的文件或未追踪，新建的文件，对应的命令git status

历史, 暂存文件提交的历史和说明，分支合并的路径等信息对应的命令 git log， git grash

搜索提供了对git log的封装

第三个工作区

分支：使用的命令包括 git branch -a，可以很直观的看到当前创建的分支

标签：展示所有的标签内容

远程分支：远程仓库所有的分支

贮藏区：相当于git stash，保存在本地的临时代码

第四个区域

主要配置，根据各个Tab切换展示不同的内容，筛选日志数据，文件状态分区，清晰的展示了各分支之间的关系和来龙去脉

同时对于修改的内容也会实时获取，这个就很方便了，比如你改动了一些代码，不需要在打开Gitlab网页，直接就能在这里看到。

出现冲突的界面

合并冲突会直接显示黄色感叹号。

第五工作区

上面主要展示了，git logs commit-id和两个版本之间的修改内容

第六个工作区

主要展示某个commit-id修改内容的差异如上图，右边还可以通过回滚区块，来操作小块代码的回滚，非常方便

注意：mac和window系统的SourceTree在界面上有一些不同

五、参考文章：

Git文档

我在工作中是如何使用git的

您必须知道的 Git 分支开发规范

阮一峰分支管理

作者：前端中后台

链接：https://juejin.cn/post/6975811088818372615

来源：稀土掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。