git stash 强制恢复_git操作与分支管理规范
git操作与分支管理规范
一、git操作规范
git操作流程数据流图
Remote:远程主仓库
Repository:本地仓库
Index:Git追踪树,暂存区
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:漏提交
git add git commit -m "提交信息" // git上会出现两次 commit
git add git commit --amend --no-edit // --no-edit 表示提交消息不会更改,在 git 上仅为一次提交
场景3:提交了错误文件,则需要 git reset或 git revert
git reset
删除指定的 commit
--mixed 默认选项,会把暂存区里的东西重置到指定的提交状态,并且指针指向这个提交。
git reset --soft HEAD~1
修改版本库,保留暂存区,保留工作区;
将版本库软回退1个版本,软回退表示将本地版本库的头指针全部重置到指定版本,且将这次提交之后的所有变更都移动到暂存区。
git reset --hard HEAD~1
修改版本库,修改暂存区,修改工作区;
将版本库回退1个版本,不仅仅是将本地版本库的头指针全部重置到指定版本,也会重置暂存区,并且会将工作区代码也回退到这个版本。
git reset --hard commit_id
git版本回退,回退到特定的 commit_id 版本,可以通过 git log 查看提交历史,以便确定要回退到哪个版本( commit 之后的即为 ID )
git revert
撤销某次操作,此次操作之前和之后的commit和history都会保留,并且把这次撤销作为一次最新的提交。
git revert HEAD
撤销前一次 commit
git revert HEAD^
撤销前前一次 commit
git revert commit-id
撤销指定的版本,撤销也会作为一次提交进行保存。 git revert 是提交一个新的版本,将需要revert的版本的内容再反向修改回去, 版本会递增,不影响之前提交的内容
git branch
git branch ,git checkout -b [namenewbranch]
查看,创建并查看项目分支。
git branch -d [name_branch]
删除分支。
git checkout [branch-name]
切换分支。
git merge [your_branch]
合并分支。注意:需要到主合并分支下合并,例如要合并某分支到master ,首先需要切换到master 分支下再进行合并。
git diff [branch] [branch]
分支比较。比较两个分支上最后 commit 的内容的差别
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
git remote add origin [git_address]
添加远程地址
git pull
拉取远程主机某分支的更新,再与本地的指定分支合并(相当与fetch加上了合并分支功能的操作)
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 的主旨,在原文中特意强调了几点:
使用祈使句,是不是很熟悉又陌生的一个词
首字母不要大写
结尾无需添加标点
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
合并远程分支代码时,使用 gitlab 平台上的 New merge request
选择 Source branch 和 Target branch
填写合并信息和选择Assignee
Merge操作与Code Review
如果对于 Changes 中的代码有更好的方案,可以添加评论并且暂不点击 Merge 操作合并代码,等待代码优化后下次 push 代码的时候会自动继续走 Merge Request 的流程。
Code Review 不仅仅是去看对方的代码写得规不规范、细节上有没有小问题,更多的是:
暂时忘记对方的代码,如果让你来实现这个需求,你会如何设计,跟对方的设计思路一致么?差异在哪里?谁的更优?
暂时忘记具体的需求(或者你原本就不知道需求),看着对方的代码,是否能够理解他想完成一件什么事情么?他理解需求了么?他完成的好么?
其实 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 可以有两个作用
团队在需求评审之后,把各个功能模块进行拆分,每个模块都可以创建一个 issue,并填写该 issue 的相关信息,最后指定 Assignee 对该模块进行开发可配合 git 的 commit 信息进行相关操作,当该模块开发完成,在 commit 可以指定相关 issue 进行关闭;
当需求开发完成并进行提测后,测试会测试出一些 bug,如果 bug 比较多且是多人名下的,开发团队的管理可以把每个 bug 记录为一个 issue,完成一个 bug 的修复便可自行 close 对应的 issue。
总之, Issues 把每个需求直接挂载对应人的名下,可以直接看出该需求的责任人。并且通过观察所有的 Issues,可以直观的看出当前的开发进度,
git stash 强制恢复_git操作与分支管理规范相关推荐
- git stash 强制恢复_git stash 保存和恢复进度
1. stash当前修改 git stash会把所有未提交的修改(包括暂存的和非暂存的)都保存起来,用于后续恢复当前工作目录. 比如下面的中间状态,通过git stash命令推送一个新的储藏,当前的工 ...
- git stash 强制恢复_git stash恢复
今天下午在使用Git命令进行代码管理时,因为自己一时疏忽直接把自己一天的劳动成果给弄丢了,这还了得,吓死宝宝了.真的,相信有代码丢失的朋友肯定能体会我当时的心情,不能体会我心情的那就祝你们也丢次代码, ...
- git stash 强制恢复_开发中必须要掌握的 Git 技巧
点击上方"Java知音",选择"置顶公众号" 技术文章第一时间送达! 作者:你喜欢吃青椒么 juejin.im/post/5d157bf3f265da1bcc1 ...
- git stash暂存的操作
git stash暂存的操作 多人开发,经常遇到开发某一个分支时,需要处理其他事情,这时就可以暂存手头的工作,进行其他工作,完事后再恢复,继续工作 1. 暂存操作 #查看当前状态git status ...
- linux git删除的文件怎么还原,从Git仓库中恢复已删除的分支、文件或丢失的commit...
从Git仓库中恢复已删除的分支.文件或丢失的commit 在使用Git的过程中,有时可能会有一些误操作 比如:执行checkout -f 或 reset -hard 或 branch -d删除一个分支 ...
- git分支管理规范和gitee上分支开发
git分支管理规范 分支开发图示: 初始化仓库 git init 初始化master vim Readme.md git add . git commit -m "init" 创建 ...
- eclipse git拉取失败_Git(四):分支
本文介绍Git分支的使用方法 查看分支 使用如下命令,会列出当前仓库的所有分支,并在当前分支的分支名前用 * 标示 git branch 添加 -a 参数可以同时查看,当前仓库的所有分支及远程仓库的分 ...
- Git学习系列(七)Bug和Feature分支管理详解
当咱们拿到一个新的bug或者feature(功能)时,首先应该想到通过分支来完成咱们的任务.因为在软件开发中,总是会根据客户的需求不断的添加新的feature进来,同时在做移动开发过程中bug也可以说 ...
- Git初学札记(五)————Branch分支管理
引言 正如之前的博客中提到的,Git区别于Svn的一个最明显的功能就是分支管理功能. 那么什么是分支?分支又能为我们的开发带来什么翻天覆地的变化呢?(为了使博客的内容更具权威性和专业性,以下部分内容摘 ...
最新文章
- 关于Visual C++ 2008中wprintf和wprintf_s输出中文乱码问题
- 计算机二级python基础知识总结-计算机二级python 知识点篇(程序的控制结构)...
- 项目: 用封装的方法实现飞机大战游戏
- 每天一道LeetCode-----找到给定数组的连续子数组,使这个子数组的和最大,要求复杂度为O(n)
- 《开源思索集》一如何更有效地学习开源项目的代码?
- java个人支付系统(springboot)
- 【渝粤教育】广东开放大学 PHP动态网站设计 形成性考核 (48)
- 前端学习(3167):react-hello-react之鼠标移入效果
- WPF:WPF显示PDF文档
- 使用selenium和phantomJS浏览器登陆豆瓣的小演示
- PM Basic Skill---project execute step
- xamarin.forms 绑定页面里指定元素的某个属性值
- 3. 请列举java ee的主要新特性_JavaEE考试题
- JAVA调用java执行,什么结果也没有
- LA 4670 Dominating Patterns,AC自动机
- Libero逻辑分析仪的使用(基本篇)
- 用Excel制作条形码
- django mongo engine
- Replication(上):常见复制模型分布式系统挑战
- VMWARE 虚拟机串口管道配置