git操做与分支管理规范

时间  2020-11-10
标签 javascript html java git github app ide 工具 gitlab 性能 栏目 Git 繁體版
原文   原文链接

1、git操做规范

git操做流程数据流图

image.png

  1. Remote：远程主仓库
  2. Repository：本地仓库
  3. Index：Git追踪树，暂存区
  4. workspace：本地工做区

代码正常的提交流程

// 工做区
git status                         // 查看状态
git add .                          // 将全部修改修改加入暂存区
git commit -m "提交描述"            // 将代码提交到本地仓库
git pull origin <共同开发的远程分支> // 拉取共同开发的远程分支，并合并到本地分支
git push                            // 将本地仓库代码更新到远程仓库

git add 进阶

  • 场景1：工做区

当改动了工做区的某个文件时，想恢复修改前，用命令 git checkout -- <filename>javascript

  • 场景2： 暂存区

当不但改动了工做区的某个文件时，想恢复修改前，还 git add 添加到了暂存区时，想丢弃修改，分两步，
第一步用命令 git reset HEAD <filename>，回到场景1；
第二步按场景1操做。
html

git commit 进阶

  • 场景1：更改 commit 信息

git commit --amend -m "新提交信息"java

  • 场景2：漏提交
  1. git add <filename> git commit -m "提交信息" // git上会出现两次 commit
  2. git add <filename> git commit --amend --no-edit // --no-edit 表示提交消息不会更改，在 git 上仅为一次提交
  • 场景3：提交了错误文件，则须要 git reset或 git revert

git reset

删除指定的 commitgit

  1. --mixed 默认选项，会把暂存区里的东西重置到指定的提交状态，而且指针指向这个提交。
  2. git reset --soft HEAD~1

修改版本库，保留暂存区，保留工做区；
将版本库软回退1个版本，软回退表示将本地版本库的头指针所有重置到指定版本，且将此次提交以后的全部变动都移动到暂存区。 github

  1. git reset --hard HEAD~1 

修改版本库，修改暂存区，修改工做区；
将版本库回退1个版本，不只仅是将本地版本库的头指针所有重置到指定版本，也会重置暂存区，而且会将工做区代码也回退到这个版本。app

  1. git reset --hard commit_id 

git版本回退，回退到特定的 commit_id 版本，能够经过 git log 查看提交历史，以便肯定要回退到哪一个版本( commit 以后的即为 ID ) 
ide

git revert

撤销某次操做，这次操做以前和以后的commit和history都会保留，而且把此次撤销做为一次最新的提交。  工具

  1. git revert HEAD 

撤销前一次 commit gitlab

  1. git revert HEAD^ 

撤销前前一次 commit 性能

  1. git revert commit-id 

撤销指定的版本，撤销也会做为一次提交进行保存。 


git revert 是提交一个新的版本，将须要revert的版本的内容再反向修改回去， 版本会递增，不影响以前提交的内容

git branch

  1. git branch ，git checkout -b [name_new_branch] 

查看,建立并查看项目分支。 

  1. git branch -d [name_branch] 

删除分支。

  1. git checkout [branch-name] 

切换分支。 

  1. git merge [your_branch] 

合并分支。 注意：须要到主合并分支下合并，例如要合并某分支到master ,首先须要切换到master 分支下再进行合并。

  1. git diff [branch] [branch] 

分支比较。 比较两个分支上最后 commit 的内容的差异

  1. git branch -m [branch] [new_name_branch]

重命名branch

git stash

可以将全部未提交的修改（工做区和暂存区）保存至堆栈中，用于后续恢复当前工做目录。

  • git stash save

git stash save 和 git stash 的做用相同，区别在于前者能够加一个对应stash的名称

  • git stash list

查看当前 stash列表中的内容

  • git stash pop

将当前 stash 中的内容弹出，并应用到当前分支对应的工做目录上。该命令会将堆栈中最近保存的内容删除。
若是从 stash 中恢复的内容和当前目录中的内容发生了冲突，会提示出错，能够经过建立新分支以解决冲突。

  • git stash apply

将堆栈中的内容应用到当前目录，该命令不一样于 git stash pop 会将内容从堆栈中删除。
可使用 git stash apply <stash_name> （如 stash@{1}）指定恢复哪一个 stash 到当前的工做目录。

  • git stash drop <stash_name>

从堆栈中移除某个指定的 stash。

  • git stash clear

清除堆栈中的全部内容。

  • git stash show

查看堆栈中最新保存的 stash 和当前目录的差别。
git stash show stash@{1} 查看指定的 stash 和当前目录的差别。
能够经过 git stash show -p 查看详细的不一样。

  • git stash branch

从最新的 stash 建立分支，可用于解决 stash 中的内容和当前工做区内容冲突。

远程remote

  1. git remote add origin [git_address] 

添加远程地址 

  1. git pull 

拉取远程主机某分支的更新，再与本地的指定分支合并（至关与fetch加上了合并分支功能的操做） 

  1. git push origin master 

分支推送到远程的版本 

优化操做

  • 拉取代码 git pull --rebase

假设提交线图在执行 pull 前是这样的：
image.png
若是是执行 git pull 后，提交线图会变成这样：
image.png
结果多出了 H 这个不必的提交记录。若是是执行 git pull --rebase 的话，提交线图就会变成这样：
image.png
F G 两个提交经过 rebase 方式从新拼接在 C 以后，多余的分叉去掉了，目的达到。

  • tip：rebase 在 git 中，算得上是『危险行为』

使用 git pull --rebase 比直接 pull 容易致使冲突的产生，若是预期冲突比较多的话，建议仍是直接 pull。 

  • 注意：

git pull = git fetch + git merge
git pull --rebase = git fetch + git rebase

2、git分支管理规范

git 分支管理数据流图


bigpicture-git-branch-all.png

各主分支介绍

master 分支

  • master 分支为主分支，具备稳定性，代码是通过测试的且已具有部署生产环境的条件；
  • master 分支通常由 develop 分支或者 hotfix 分支合并，禁止直接对 master 分支进行直接修改。

develop 分支

  • develop 分支为开发分支，能够做为合入 master 分支的备选分支，此分支保存最新完成开发的功能以及通过测试后 bug 已被修复的代码；
  • 通常开发新功能时，都是基于 develop 分支建立新的 feature 分支；
  • 从 develop 分支总能得到项目最新开发进展的代码。

feature 分支

  • feature 分支用于开发一个独立的新的功能，基于 develop 分支建立；
  • 开发新的功能须要建立新的功能分支，命名格式能够以 feature- 或 feature/ 做为开头，如 feature-login 或者 feature/login，不过最好在同一项目中统一开头命名格式；
  • feature 分支最终也归于 develop 分支或者被删除。

release 分支

  • release 分支基于 develop 分支建立，为预上线分支，在发布前的提测阶段，会以 release 分支代码为基准提测；
  • release 最终归于 develop 分支或 master 分支。分支命名能够以 relseae- 开头；
  • release 分支能够用来作版本号等元素的准备工做、bug的修复、发布前的准备，建立 release 分支最好的时机是 develop 分支已完成对应版本的功能开发，新功能 feature 分支已合入 develop 分支且基本达到预期状态。若在测试过程当中存在 bug 须要修复，则可直接基于 release 分支修复并提交，此过程不作新功能的加入，新功能依旧基于 develop 分支开发；
  • 当测试完成并验证再无新 bug 后，将 release 分支合并进 master 分支和 develop 分支，此时 master 分支为具有上线条件的分支。

hotfix 分支

  • hotfix 分支基于 master 分支建立，用于处理项目上线后发现的紧急的非预期 bug;
  • hotfix 分支最终归于 develop 分支或 master 分支，分支命名能够以 hoxfix- 开头；
  • 设立 hotfix 分支的缘由，是为了不开发新功能的排期受到线上 bug 的影响。

操做规范

commit messages 规范

项目当中好的 commit messages 规范编写有助于多人维护项目和 review 项目，做为一名开发人员，也应该是一名项目的协做者，编写规范的 commit messages 是基本的要求。
Angular 团队的代码 commit messages 规范是社区中比较合理且系统化的，以下图：
image.png
Angular Git Commit Guidelines
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具体格式为
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
  • type: 本次 commit 的类型，诸如 bugfix docs style 等
  • scope: 本次 commit 波及的范围
  • subject: 简明扼要的阐述下本次 commit 的主旨，在原文中特地强调了几点：
  1. 使用祈使句，是否是很熟悉又陌生的一个词
  2. 首字母不要大写
  3. 结尾无需添加标点
  • body: 一样使用祈使句，在主体内容中咱们须要把本次 commit 详细的描述一下，好比这次变动的动机，如需换行，则使用 |
  • footer: 描述与之关联的 issue 或 break change，如 Closes #123 可关闭对应的 issue，详情可见

Closing issues using keywords
https://docs.github.com/en/free-pro-team@latest/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue，使用 jira 时，咱们在 commit message 中能够填写其影响的JIRA_ID，若要开启该功能须要先打通 jira 与 gitlab。参考文档：https://docs.gitlab.com/ee/user/project/integrations/jira.html
一次 commit 的过程中，type 和 subject 为必须描述的信息，其余信息能够根据本次提交改动的规模进行选择描述。

type 的类型说明
  • feat: 添加新特性
  • fix: 修复bug
  • docs: 仅仅修改了文档
  • style: 仅仅修改了空格、格式缩进、都好等等，不改变代码逻辑
  • refactor: 代码重构，没有加新功能或者修复bug
  • perf: 增长代码进行性能测试
  • test: 增长测试用例
  • chore: 改变构建流程、或者增长依赖库、工具等

利用 Gitlab 平台的能力

Merge Request && Code Review
  1. 合并远程分支代码时，使用 gitlab 平台上的 New merge request

image.png

  1. 选择 Source branch 和 Target branch

image.png

  1. 填写合并信息和选择Assignee

image.png

  1. Merge操做与Code Review

image.png
若是对于 Changes 中的代码有更好的方案，能够添加评论而且暂不点击 Merge 操做合并代码，等待代码优化后下次 push 代码的时候会自动继续走 Merge Request 的流程。
Code Review 不只仅是去看对方的代码写得规不规范、细节上有没有小问题，更多的是：

  1. 暂时忘记对方的代码，若是让你来实现这个需求，你会如何设计，跟对方的设计思路一致么？差别在哪里？谁的更优？
  2. 暂时忘记具体的需求（或者你本来就不知道需求），看着对方的代码，是否可以理解他想完成一件什么事情么？他理解需求了么？他完成的好么？

其实 CR 就是对设计和实现的再次确认，在反复较量的过程当中，相互学习和成长。若是以上两个问题存在否认的答案，那就有必要好好写写 CR 评语了。

PipeLines
持续集成是一种软件开发实践，即团队开发成员常常集成他们的工做，一般每一个成员天天至少集成一次，也就意味着天天可能会发生屡次集成。每次集成都经过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程能够大大减小集成的问题，让团队可以更快的开发内聚的软件。

在 PineLines 中，能够集成 Gitlab-CI 和 Gilab-Runner。GitLab-Runner 是配合 GitLab-CI 进行使用的。通常地，GitLab 里面的每个工程都会定义一个属于这个工程的软件集成脚本，用来自动化地完成一些软件集成工做。当这个工程的仓库代码发生变更时，好比有人 push 了代码，GitLab 就会将这个变更通知 GitLab-CI。这时 GitLab-CI 会找出与这个工程相关联的 Runner，并通知这些 Runner 把代码更新到本地并执行预约义好的执行脚本。
详细的介绍和使用能够阅读这篇文章 Gitlab-CI 和 Gitlab-Runner
http://www.javashuo.com/article/p-ttejewie-ev.html

Issues

image.png
Issues 能够有两个做用

  1. 团队再需求评审以后，把各个功能模块进行拆分，每一个模块均可以建立一个 issue，并填写该 issue 的相关信息，最后指定 Assignee 对该模块进行开发可配合 git 的 commit 信息进行相关操做，当该模块开发完成，在 commit 能够指定相关 issue 进行关闭；
  2. 当需求开发完成并进行提测后，测试会测试出一些 bug，若是 bug 比较多且是多人名下的，开发团队的管理能够把每一个 bug 记录为一个 issue，完成一个 bug 的修复即可自行 close 对应的 issue。

总之， Issues 把每一个需求直接挂载对应人的名下，能够直接看出该需求的责任人。而且经过观察全部的 Issues，能够直观的看出当前的开发进度，

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程