git本地删除后如何再pull下来_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: 本次 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，可以直观的看出当前的开发进度，