git常用操作

目录

• 安装
• 创建仓库
• 检出
• 界面介绍
• 提交
• 推送
• 拉取
• 总结操作流程
• 分支
• 回滚代码
• 忽略文件
• 工作规范
  • 开发新功能
  • 测试流程
  • 线上修复
  • 分支命名规则
  • 提交信息规范
  • 注意事项

安装

git 是需要安装的：安装地址

验证是否有安装

Unix

1
2
3

$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

Windows

打开 cmd 命令行界面输入 git 即可

使用方式

• 命令行
• GUI Client (图形客户端)
• ide 自带 Git 插件
• ……

使用 Git 的方式有很多

该篇文档主要使用 GUI Client 中的一款 Sourcetree

还有讲解 git 一些日常使用和提交规范

Sourcetree

它是的免费 Git 图形界面工具，可以操作任何Git库

支持多个操作系统，安装地址

创建仓库

先通过 Sourcetree 里的新建菜单来说明下 git 几个概念

仓库

先讲一下仓库的概念来说，分为本地仓库和远程仓库

本地仓库：代码是存在你本地文件夹上

远程仓库：代码是存在 git 服务器上

在这里可以说明一下代码冲突的产生本质

本地的代码与服务器的代码产生冲突

需要在本地把冲突解决完了才能把代码推送到远程服务器上

所以冲突的产生是在本地，不会对远程服务器造成影响

当你解决不了的时候可以回滚代码，让更熟悉这块冲突的同事解决

添加已经存在的本地仓库

已经存在的本地仓库证明文件夹已经执行了 git 初始化的动作了

本地仓库是否已经初始化的判断

• 文件夹里是否有 .git 隐藏文件夹
• 在 Sourcetree 添加本地仓库时提示需要创建

本质区别就是是否有执行过 git init 这个命令

从URL克隆

根据远程仓库地址将代码下载到本地

• 源URL：远程仓库地址
• 目标路径：要存放这个代码的文件夹路径 (必须是空文件夹)
• 名称：在sourcetree的备注名，在列表里显示的名称

对应的 git 命令行

1

git clone https://gitee.com/Double__C/demo.git my_file

命令行会自动创建文件夹 my_file，并将项目代码放进文件夹内

而 Sourcetree 是需要提前建好文件夹来存放代码后制定好路径

检出

初次克隆项目的时候默认只会拉取远程仓库中的主分支 (master)

假如远程仓库中还有其他分支也需要拉取到本地的话，操作如下：

这样操作后远程分支 develop 会被拉取下来本地

并在本地仓库创建同名分支 develop

界面介绍

• 左侧 - 分支：圆点代表当前处于哪条分支
• 左侧 - 文件状态：这个 tab 存放本地仓库当前文件的状态，如果有变动都会在这里显示
• 左侧 - 历史 ：显示历史提交信息

提交

这里主要演示日常开发如何提交文件到本地仓库中

涉及的相关命令行有

查看本地仓库当前分支是否有变化:

1

git status

将发生变化的所有文件都添加到缓冲区（暂存区）中

1

git add -A

将缓冲区的所有文件打包成一个 commit 提交到本地仓库中

1

git commit -m "feat:提交信息"

这样就把所有变更的文件的提交到本地仓库中

并为其生成一个唯一的commit id

推送

刚才我们提交的 commit 就会显示在提交记录里

这里由于我们还没推送到远程仓库

所以这里我们的本地仓库的 develop 分支会领先远程分支一个 commit

接着点击推送按钮就可以把刚才所有的改动推送到远程仓库上

对应的命令行是：

1

git push

拉取

当远程仓库里有新的文件更新的时候，可以点击拉取 / 抓取

• 拉取 ：将当前分支对应的远程仓库分支的代码拉取到本地，并且与当前的代码进行合并

  如果修改的文件和最新拉取的文件有冲突的话 git 就会提示冲突

对应的命令行：

1

git pull

总结操作流程

1. 初始化仓库
   • git init -> 适用于本地项目想使用 git 做版本控制
   • git clone 远程仓库链接
   • sourcetree -> 新建项目
2. 添加文件追踪
   • git add -A
   • sourcetree -> 未暂存文件列表里勾选文件
3. 将修改的文件提交到本地仓库
   • git commit -m “提交信息”
   • sourcetree -> 已暂存文件列表里勾选文件，填写提交信息，点击提交按钮
4. 当开发完毕后将所有文件推送到远程仓库里
   • 推送失败大概率是因为远程仓库有更新需要拉取和有文件变动并未提交
   • git push
   • sourcetree -> 推送

分支

创建分支

创建分支的时候 是会以当前分支为副本去新建新的分支

所以创建分支的时候需要注意当前所在分支

如上图所示，当前在 master上

sourcetree -> 左侧分支 tab -> 右键 -> 新建分支

这样操作就会出现截图新建分支的窗口

对应的命令行:

1

git checkout -b feature/test

以当前分支为副本创建新分支 feature/test 并切换到新分支上

切换分支

sourcetree -> 双击左侧分支tab下 对应的分支名即可切换分支

命令行切换分支：

1

git checkout 分支名

合并分支

sourcetree 合并分支操作如上图所示 ：develop 分支合并到 master

注意：当前分支需要切换到 master 上

对应的命令行是：

1
2

git checkout master  # 切换到 master 分支
git merge --no-ff develop

常用的合并分支的命令是 git merge

但是由于在多人合作开发，频繁创建功能分支的项目中

该命令在后续查看分支演变的 log 时会导致信息不明确

git merge --no-ff 分支名称 该命令是关闭快进式合并 (fast-farward merge)

关闭快进式合并

使用–no-ff参数后，会执行正常合并

在Master分支上生成一个新节点

为了保证版本演进的清晰，希望在合并时能遵守该规则

下面演示两种合并产生的结果

使用快进方式的合并后 develop 分支的提交记录都会变成在 master 上

这样的提交记录并不能直观看出版本演化

而且当上线发生问题想要回退时，不利于回滚

上图对应的命令行是：

1

git merge develop # 没带参数使用快进方式合并

注意：平时合并分支不能使用快进方式，要记得关闭快进方式！或使用正确带参数的命令

关闭快进方式后，可以很直观的看出 develop 分支之前的提交记录

并且会将 develop 的三个提交合并成一个 commit 显示在 master 分支上

这样当线上环境需要回滚时是以每次合并的 commit 去回滚

上图对应的命令行是：

1

git merge --no-ff develop # 关闭快进方式进行合并

sourcetree 关闭以快进方式进行合并如下图所示：

回滚代码

日常开发中有可能开发的代码有误，希望将代码回滚到某一次 commit 中

sourcetree 中操作如下，先选中要回滚到的 commit

接着执行回滚：

回滚常用的两种

• 混合合并：只是重置了当前的索引，代码无任何改变
• 强制合并：将代码还原到选中的代码状态，现有的代码会全部丢失

平时常用的回滚应该是指强制合并，抛弃当前代码将代码还原到指定 commit 时的状态

强制合并对应的命令行:

1

git reset --hard commit id

忽略文件

并不是项目里所有文件都希望被 git 跟踪

例如我们 ide 的配置文件

sourcetree -> 点击编辑后会弹出对应的文本出来

1
2

.idea/
.DS_Store

.idea/ 忽略 .idea文件夹

.DS_Store 忽略 .DS_Store

原理：git 会根据 .gitgnore 文件知道哪些文件不需要被跟踪

所以一个项目里每个目录下都可以拥有自己的 .gitgnore 文件

如果你忽略的文件已经存在于 git 仓库中的话

需要删除文件后 commit

之后再创建对应的忽略文件

git才会忽略

一般第三方包的文件夹是不上传到版本控制中
例如：

• PHP 中存放 composer 三方包的 vendor 文件夹
• npm 的 node_modules

工作规范

开发新功能

1. 以 master 分支为副本，新建对应的功能分支

   提示：功能分支命名必须以 feature/ 开头

2. 在功能分支上完成开发后将代码合并 test 分支提测

3. 测试通过后，再将功能分支合并到 master 上线

测试流程

1. 开发完成后合并 test 分支

2. 测试过程中，该功能模块禁止再向 test 分支合并代码 (封版本)

   • 当有影响测试流程的 bug 出现时，应立刻停止测试并通知开发紧急修复，保证测试工作正常进行

   需要保证测试过程中是一个稳定的版本

   而不能说当发现一个bug后修复完立刻合并

   修复的代码可能会影响到其他功能等突发情况

   导致测试人员需要不断重复测试

   作为开发人员，提交测试的版本最基本的要求是功能流程能正常走完

3. 当测试完成后根据 bug 列表里的 bug 进行修复
   • 在测试期间虽然不能合并代码，但是可以在对应的功能分支先进行 bug 修复
   • 修复的 bug 必须在开发环境中自检
4. 将修复 bug的相关代码合并到测试分支中，再次体测
5. 上述过程中重复执行直至测试通过后，结束测试流程，准备上线

线上修复

判断该 bug 复杂度，主要以修复时间作为判断标准

• 如果是比较简单的 bug 能在短时间内修复的直接在 master 分支上修复

  • 修复的代码先 commit 在本地仓库，不推送到远程仓库
  • 将修复代码合并到 test 分支，提测
  • 待测试通过后将本地仓库的提交推送到远程仓库 master 分支上

• 如果是比较复杂的 bug，且需要一定修复时间

  1. 以 master 分支为副本，新建对应的修复分支

     提示：功能分支命名必须以 fix/ 开头

  2. 修复完成后将代码合并到 test 分支，提测

  3. 待测试通过后将修复分支的代码合并到 master

分支命名规则

提交信息规范

团队开发中，会出现大量的 commit 信息，规范的提交信息我们可以区别出各个提交的内容

另外当产生冲突时，别人也可以根据最后的 commit 信息去对冲突进行判断

示例：

1
2

git commit -m "feat:登录功能"
git commit -m "fix:配置项有误"

注意事项

• 合并分支必须 关闭快进式合并