关于前端:git操作与分支管理规范

41次阅读

共计 5761 个字符,预计需要花费 15 分钟才能阅读完成。

一、git 操作标准

git 操作流程数据流图

  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>

  • 场景 2:暂存区

当岂但改变了工作区的某个文件时,想复原批改前,还 git add 增加到了暂存区时,想抛弃批改,分两步,
第一步用命令 git reset HEAD <filename>,回到场景 1;
第二步按场景 1 操作。

git commit 进阶

  • 场景 1:更改 commit 信息

git commit –amend -m “ 新提交信息 ”

  • 场景 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

删除指定的 commit

  1. –mixed 默认选项,会把暂存区里的货色重置到指定的提交状态,并且指针指向这个提交。
  2. git reset –soft HEAD~1

批改版本库,保留暂存区,保留工作区;
将版本库软回退 1 个版本,软回退示意将本地版本库的头指针全副重置到指定版本,且将这次提交之后的所有变更都挪动到暂存区。

  1. git reset –hard HEAD~1 

批改版本库,批改暂存区,批改工作区;
将版本库回退 1 个版本,不仅仅是将本地版本库的头指针全副重置到指定版本,也会重置暂存区,并且会将工作区代码也回退到这个版本。

  1. git reset –hard commit_id 

git 版本回退,回退到特定的 commit_id 版本,能够通过 git log 查看提交历史,以便确定要回退到哪个版本(commit 之后的即为 ID) 

git revert

撤销某次操作,此次操作之前和之后的 commit 和 history 都会保留,并且把这次撤销作为一次最新的提交。

  1. git revert HEAD 

撤销前一次 commit 

  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 前是这样的:

如果是执行 git pull 后,提交线图会变成这样:

后果多出了 H 这个没必要的提交记录。如果是执行 git pull –rebase 的话,提交线图就会变成这样:

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

二、git 分支治理标准

git 分支治理数据流图

各主分支介绍

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 标准是社区中比拟正当且系统化的,如下图:

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

  1. 抉择 Source branch 和 Target branch

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

  1. Merge 操作与 Code Review


如果对于 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
https://www.cnblogs.com/cnundefined/p/7095368.html

Issues


Issues 能够有两个作用

  1. 团队再需要评审之后,把各个功能模块进行拆分,每个模块都能够创立一个 issue,并填写该 issue 的相干信息,最初指定 Assignee 对该模块进行开发可配合 git 的 commit 信息进行相干操作,当该模块开发实现,在 commit 能够指定相干 issue 进行敞开;
  2. 当需要开发实现并进行提测后,测试会测试出一些 bug,如果 bug 比拟多且是多人名下的,开发团队的治理能够把每个 bug 记录为一个 issue,实现一个 bug 的修复便可自行 close 对应的 issue。

总之,Issues 把每个需要间接挂载对应人的名下,能够间接看出该需要的责任人。并且通过观察所有的 Issues,能够直观的看出以后的开发进度,

正文完
 0