git本地删除后如何再pull下来_git操作与分支管理规范

git操作与分支管理规范

一、git操作规范

git操作流程数据流图

git本地删除后如何再pull下来_git操作与分支管理规范_第1张图片

  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 --

  • 场景2:暂存区

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

git commit 进阶

  • 场景1:更改 commit 信息

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

  • 场景2:漏提交

  1. git add git commit -m "提交信息" // git上会出现两次 commit

  2. git add 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 [namenewbranch] 

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

  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] [newnamebranch]

重命名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@{1})指定恢复哪个 stash 到当前的工作目录。

  • git stash drop

从堆栈中移除某个指定的 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下来_git操作与分支管理规范_第2张图片
如果是执行 git pull 后,提交线图会变成这样:git本地删除后如何再pull下来_git操作与分支管理规范_第3张图片
结果多出了 H 这个没必要的提交记录。如果是执行 git pull --rebase 的话,提交线图就会变成这样:git本地删除后如何再pull下来_git操作与分支管理规范_第4张图片
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 分支管理数据流图

git本地删除后如何再pull下来_git操作与分支管理规范_第5张图片

各主分支介绍

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 规范是社区中比较合理且系统化的,如下图:git本地删除后如何再pull下来_git操作与分支管理规范_第6张图片
Angular Git Commit Guidelines
https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines

具体格式为

():

  • 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

git本地删除后如何再pull下来_git操作与分支管理规范_第7张图片

  1. 选择 Source branch 和 Target branch

git本地删除后如何再pull下来_git操作与分支管理规范_第8张图片

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

git本地删除后如何再pull下来_git操作与分支管理规范_第9张图片

  1. Merge操作与Code Review

git本地删除后如何再pull下来_git操作与分支管理规范_第10张图片
如果对于 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

git本地删除后如何再pull下来_git操作与分支管理规范_第11张图片
Issues 可以有两个作用

  1. 团队在需求评审之后,把各个功能模块进行拆分,每个模块都可以创建一个 issue,并填写该 issue 的相关信息,最后指定 Assignee 对该模块进行开发可配合 git 的 commit 信息进行相关操作,当该模块开发完成,在 commit 可以指定相关 issue 进行关闭;

  2. 当需求开发完成并进行提测后,测试会测试出一些 bug,如果 bug 比较多且是多人名下的,开发团队的管理可以把每个 bug 记录为一个 issue,完成一个 bug 的修复便可自行 close 对应的 issue。

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

你可能感兴趣的:(请指定您要合并哪一个分支)