git 使用大全，所有关于git的问题看这一篇就够了。git 和 github关联，git 分支管理，gitflow ，git 常用命令等

开屏就是常用命令

Git 的工作流程

工作区：就是当前正在操作的文件夹
暂存区 staging Area/Index：需要提交的文件修改暂时放到暂存区，然后再一次性提 交到本地版本库中。

把文件添加到本地 Git 版本库里时，要执行以下两步：
第一步，执行“git add”命令把文件添加到暂存区；
第二步，执行“git commit”提交更改，把暂存区的所有内容提交到本地版本库 master 分支中。Git 在版本库会为项目自动创建的一个主分支 master，默认情况 下 git commit 会向 master 分支提交更改。

课堂实验：依次执行以下命令
git status：查看版本库的状态

在 GitTest 文件夹中创建一个 hello.text 文件，然后再次执行 git status 命令：

如上图所示，Git 发现在“GitTest”文件夹下有“untracke files”未跟踪的文件。
git add：把文件添加到暂存区

再次执行 git status：

从上图可以发现，当前文件状态已从 Untracked 变成了 new file，表明该文件已经被 安置到暂存区（staging Area/Index）。也可以执行以下命令：

Git add .txt -------- 把.txt 的文件加到暂存区

Git add --all 或 git add . ------把所有的文件都加到暂存区

注意：执行了 git add 命令后，如果又修改了 hello.txt 文件，需要再次执行 git add hello.txt 命令，把修改后的 hello.txt 加入暂存区

Git commit：把暂存区的内容提交到本地版本库中 Git commit -m “内容说明” ----把文件永久保存下来，并添加内容说明

创建本地版本库

版本库又名仓库，可以理解成一个目录，这个目录里面的所有文件都可以被 Git 管 理，每个文件的修改、删除，Git 都能跟踪，以便任何时刻都可以追踪历史，或者在将 来某个时刻可以“还原”。所以，首先应该创建一个本地版本库。

git和GitHub的关联

（1）GitHub

GitHub 是一个商业网站，是当前全球最大的 Git 服务器。

Git 和 GitHub 的区别：Git 是一款版本控制软件，而 GitHub 是一个商业网站， 其本体是一个 Git 服务器，但这个网站上的应用程序可以让大家通过 Web 操作，来 完成原本要用复杂的 Git 指令才能做到的操作。

GitHub 的具体使用步骤，可访问以下网页：

https://www.runoob.com/w3cnote/git-guide.html

也可以使用码云：https://gitee.com/ 作为远程仓库。

GitHub 支持团队协同开发，另外 Idea 中也支持 GitHub 的应用，可自行查阅相 关材料进行自学

Git配置SSH Key

git config --global user.name "用户名"
git config --global user.email "绑定的电子邮箱"
ssh -keygen -t rsa -C“绑定的电子邮箱”
cat ~/.ssh/id_rsa.pub
1
2
3
4

(2)git常用命令

git init   //初始化一个仓库：
git branch //查看分支：
git add [file] 或 git add . //将已修改或未跟踪的文件添加到暂存区：
git commit -m "提及记录 xxxx" //提交至本地仓库：
git push origin //本地分支推送至远程分支：
git status //查看当前工作目录和暂存区的状态: 
git log //查看提交的日志记录：
git pull //从远程分支拉取代码：
git merge xxx //合并某分支(xxx)到当前分支：
git checkout xxx //切换到分支 xxx：
git checkout -b xxx //创建分支 xxx 并切换到该分支：
git branch -d xxx  //删除分支 xxx：
git stash //将当前分支到改动保存到堆栈中：
git stash pop  //恢复堆栈中缓存的改动内容：
1
2
3
4
5
6
7
8
9
10
11
12
13
14

(3) git的分支管理

git remote -v 列出详细信息，在每一个名字后面列出其远程url，此时， -v 选项(译注:此为 –verbose 的简写,取首字母),显示对应的克隆地址。

git remote    //不带参数，列出已经存在的远程分支

git branch    //查看分支，一般克隆下来的默认只有一个master分支  前面加* 号的是当前的分支
git branch -a    //加上-a参数可以查看远程分支

git branch <name>     //创建分支

git switch <name>
git checkout <name>    //切换分支

git switch -c <name>        //创建分支的同时切换到该分支（写法1）
git checkout -b <name>     //创建分支的同时切换到该分支（写法2）

git branch -d <name>      //删除分支

git branch -r -d origin/branch-name  
git push origin :branch-name   //删除远程分支

git branch --set-upstream-to=origin/remote_branch your_branch  
 //将本地的仓库和远程的仓库关联起来

//如果远程新建了一个分支，本地没有该分支。可以利用
 git checkout --track origin/branch_name 
 //这时本地会新建一个分支名叫 branch_name ，会自动跟踪远程的同名分支 branch_name。

//如果本地新建了一个分支 branch_name，但是在远程没有。
//这时候 push 和 pull 指令就无法确定该跟踪谁，一般来说我们都会使其跟踪远程同名分支
//所以可以利用 
git push --set-upstream origin branch_name 
//这样就可以自动在远程创建一个 branch_name 分支，然后本地分支会 track 该分支。
//后面再对该分支使用 push 和 pull 就自动同步。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

多人开发场景

git pull     //如果是多人开发的话 需要把远程master上的代码pull下来
//然后合并冲突，然后再

git add .
git commit -m "balabala"
git push origin <name>   //提交到远程仓库

git merge dev  //将dev分支和现在分支的开发历史合并在一起，再自己手动解决分支
1
2
3
4
5
6
7
8

修改分支名字（分支名字敲错了或者不满意）

git branch -m <oldbranch> <newbranch>
1

如何将本地的项目上传到GitHub上?

git init  //把这个文件夹变成Git可管理的仓库

git add .
git commit -m "aaa"


//在Github上创建好Git仓库之后我们就可以和本地仓库进行关联了
 git remote add origin https://github.com/guyibang/TEST2.git
//或者
 git remote add origin git@github.com:GDUFS-IIIP-DEV/yunyin.git

git push -u origin master // 由于新建的远程仓库是空的，所以要加上-u这个参数

git push origin master //等远程仓库里面有了内容之后，下次再从本地库上传内容的时候只需这样就可以了


git pull --rebase origin master //当github上的仓库不是空的时，即在GitHub上创建仓库的时候勾选了创建README.md文件时，要先pull

git log --oneline --graph //以简洁的方式显示 git 记录


git log -最近提交的次数 //查看最近几次的 git 记录


Git rm 文件名 --cached //某个文件不再被 Git 控制


Git mv hello.txt world.txt //更新文件名

Git checkout 文件名 //找回已删除的文件： 

Git reset master^ //撤销某次 commit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

项目开发中使用git的标准

master分支：只有项目经理才能合并，是项目的最终版

dev开发分支：最后要合并到master分支上的，我们在开发分支上操作

开发：
先拉取dev分支到本地
然后在本地再建新分支开发新功能：

比如新建feature分支，在feature分支上写代码，运行没问题后再合并到dev分支上，dev分支检查下有没有问题，没有问题就可以推送到远程

//怎么合并分支，首先，我们要切换到dev分支上，然后输入
git merge feature //把feature分支的代码合并到dev
1
2

其他命令

git remote update origin --prune //更新远程分支列表
git branch -a //查看所有分支
git push origin --delete Chapater6 //删除远程分支Chapater6
git branch -d  Chapater6 //删除本地分支 Chapater6
1
2
3
4

测试分支：
项目开发完毕时，在远程的dev分支上新建出一个测试分支，用来测试，测试没问题后就可以将dev分支合并到master分支上，然后就能上线了

对 GitFlow 的理解？

GitFlow 重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题。重点是对各个分支的理解。

• master：主分支。
• develop：主开发分支，平行于master分支。
• feature：功能分支，必须从develop分支建立，开发完成后合并到develop分支。
• release：发布分支，发布的时候用，一般测试时候发现的 bug
  在该分支进行修复。从develop分支建立，完成后合并回develop与master分支。
• hotfix：紧急修复线上 bug 使用，必须从master分支建立，完成后合并回develop与master分支。

git版本回退

当修改出错的时候想回退到某个版本

git log //该命令显示从最近到最远的提交日志。每一次提交都有对应的 commit id 和 commit message。
git log --pretty=oneline //简化
git reset --hard id //根据 id 回退到指定的版本；
1
2
3

git 代码提交规范

在多人协作的背景下，git 仓库和 workflow 的作用很重要。而对于 commit 提交的信息说明存在一定规范，现使用 commitlint + husky 规范 git commit -m “” 中的描述信息。我们都知道，在使用 git commit 时，git 会提示我们填入此次提交的信息。可不要小看了这些 commit，团队中规范了 commit 可以更清晰的查看每一次代码提交记录，还可以根据自定义的规则，自动生成 changeLog 文件。
提交格式（注意冒号后面有空格）：

<type>[optional scope]: <description>
1

复制代码

type ：用于表明我们这次提交的改动类型。
optional scope：可选，用于标识此次提交主要涉及到代码中哪个模块。
description：一句话描述此次提交的主要内容，做到言简意赅。
1
2
3

Type 类型

build： //编译相关的修改，例如发布版本、对项目构建或者依赖的改动
chore：//其他修改, 比如改变构建流程、或者增加依赖库、工具等
ci：//持续集成修改
docs：//文档修改
feat：//新特性、新功能
fix：//修改bug
perf：//优化相关，比如提升性能、体验
refactor：//代码重构
revert：//回滚到上一个版本
style：//代码格式修改, 注意不是 css 修改
test：//测试用例修改
1
2
3
4
5
6
7
8
9
10
11

关于 commitlint + husky 的配置文章有很多，大同小异，请根据自己的实际情况配置。

git merge 和 git rebase 的区别？

相同点：

git merge和git rebase两个命令都⽤于从⼀个分⽀获取内容并合并到当前分⽀。

不同点：

git merge会⾃动创建⼀个新的commit，如果合并时遇到冲突的话，只需要修改后重新commit。

• 优点：能记录真实的commit情况，包括每个分⽀的详情
• 缺点：由于每次merge会⾃动产⽣⼀个commit，因此在使用⼀些可视化的 git
  工具时会看到这些自动产生的commit，这些commit对于程序员来说没有什么特别的意义，多了反而会影响阅读。

git rebase会合并之前的commit历史。

• 优点：可以得到更简洁的提交历史，去掉了 merge 产生的commit
• 缺点：因为合并而产生的代码问题，就不容易定位，因为会重写提交历史信息

场景:

当需要保留详细的合并信息，建议使⽤git merge, 尤其是要合并到master上
当发现⾃⼰修改某个功能时提交比较频繁，并觉得过多的合并记录信息对自己来说没有必要，那么可尝试使用git rebase

切换分支，代码暂存

在开发中经常会遇见：正在A分支开发，但是有紧急需求需要在B分支处理，此时A分支代码没有开发完整，又不能提交代码，这个时候暂存本地代码就非常的YYDS了！

* git status  查看当前修改的文件

* git stash  暂存当前未commit的代码

* git stash save "备注的内容"  暂存当前未commit的代码并添加备注

* git stash list  查看所有stash记录

* git stash apply  应用最近一次stash
* git stash apply stash@{序号} 应用指定的stash

* git stash pop 应用最近一次stash并删除其记录
* git stash pop stash@{序号} 应用指定的stash并删除其记录

* git stash drop  删除最近一次stash
* git stash drop  stash@{序号} 删除指定的stash
* git stash clear 删除所有stash记录
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

git 子仓管理

Git 子仓库（Git Submodule）是 Git 版本控制系统中的一个功能，用于将一个 Git 仓库作为另一个 Git 仓库的子目录。这使得你可以在一个项目中引用另一个项目，同时保持它们的版本控制独立。这在多个项目需要共享代码或资源时非常有用。

使用 Git 子仓库的主要优点如下：

1. 代码重用：子仓库允许你在不同的项目中重用相同的代码库，而不需要复制或创建新的副本。
2. 版本控制：子仓库保持了它自己的版本控制历史，这意味着它的更改不会影响到主仓库。
3. 独立开发：子仓库可以独立于主仓库进行开发和维护，这有助于团队在不同的项目中进行协作。
4. 易于集成：通过 Git 子仓库，你可以轻松地将外部项目集成到你的主项目中，同时保持版本控制的一致性。

在使用 Git 主仓库（主仓）和子仓库（子仓）时，需要注意它们之间的版本控制是相互独立的。这意味着主仓和子仓的代码提交是分开进行的。这里是如何理解并处理主仓和子仓之间的代码提交的：

1. 子仓的代码提交：

   当你在子仓中进行更改时，你需要在子仓的目录中执行 git add、git commit 和 git push 等操作。这样，子仓的更改将被推送到子仓的远程仓库。请注意，这些操作不会影响主仓的版本控制。

2. 主仓的代码提交：

   当你在主仓中进行更改时（包括添加、删除或修改子仓），你需要在主仓的目录中执行 git add、git commit 和 git push 等操作。这样，主仓的更改将被推送到主仓的远程仓库。

   如果你更新了子仓（例如，检出了子仓的新分支或提交了新的更改），你需要在主仓中提交子仓的引用更新。这是因为主仓实际上存储了指向子仓特定提交的引用，而不是子仓的整个代码。

如果需要更新子仓，则在项目里面，切换到子仓的目录下

git checkout master
git pull
git checkout -b dev/xxx

//修改子仓代码
git add .
git commit -m "fix : 修复XXX"
git push origin
1
2
3
4
5
6
7
8

然后主仓会生成一个子仓的提交记录

要提交子仓的引用更新，请在主仓中执行以下操作：

git add .
git commit -m "fix : 更新子仓"
git push origin

1
2
3
4

即可对子仓代码进行修改