Git笔记(ydl)

发布于 2022-08-06  1129 次阅读


img

第一章 理论基础

一 、Git安装

windows安装:进入网站https://git-scm.com/下载安装,然后在cmd命令行配置

直接去腾讯软件中心下载也可以!

> git config --global user.name "itnanls"
> git config --global user.email "[email protected]"

git config --list 

ubuntu配置:apt-get install git

centos配置:yum install git

二、三种状态

  • 已修改 表示修改了文件,但还没保存到数据库中。
  • 已暂存 表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。
  • 已提交 表示数据已经安全地保存在本地数据库中。

这会让我们的 Git 项目拥有三个阶段:工作区、暂存区以及 Git 目录。

image-20220802160725021

工作目录、暂存区域以及 Git 仓库.

工作区 是对项目的某个版本独立提取出来的内容。 这些从 Git 仓库的压缩数据库中提取出来的文件,放在磁盘上供你使用或修改。

暂存区 是一个文件,保存了下次将要提交的文件列表信息,一般在 Git 仓库目录中。 按照 Git 的术语叫做“索引”,不过一般说法还是叫“暂存区”。

Git 仓库目录 是 Git 用来保存项目的元数据和对象数据库的地方。 这是 Git 中最重要的部分,从其它计算机克隆仓库时,复制的就是这里的数据。

基本的 Git 工作流程如下:

  1. 在工作区中修改文件。
  2. 将你想要下次提交的更改选择性地暂存,这样只会将更改的部分添加到暂存区。
  3. 提交更新,找到暂存区的文件,将快照永久性存储到 Git 目录。

如果 Git 目录中保存着特定版本的文件,就属于 已提交 状态。 如果文件已修改并放入暂存区,就属于 已暂存 状态。 如果自上次检出后,作了修改但还没有放到暂存区域,就是 已修改 状态。

三、Git 保证完整性

Git 中所有的数据在存储前都计算校验和,然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。

Git 用以计算校验和的机制叫做 SHA-1 散列(hash,哈希)。 这是一个由 40 个十六进制字符(0-9 和 a-f)组成的字符串,基于 Git 中文件的内容或目录结构计算出来。 SHA-1 哈希看起来是这样:

24b9da6552252987aa493b52f8696cd6d3b00373

Git 中使用这种哈希值的情况很多,你将经常看到这种哈希值。 实际上,Git 数据库中保存的信息都是以文件内容的哈希值来索引,而不是文件名。

第二章 基本命令

一、配置信息 git config

既然已经在系统上安装了 Git,你会想要做几件事来定制你的 Git 环境。 每台计算机上只需要配置一次,程序升级时会保留配置信息。 你可以在任何时候再次通过运行命令来修改它们。

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。

在 Windows 系统中,Git 会查找 $HOME 目录下(一般情况下是 C:\Users\$USER )的 .gitconfig 文件。

你可以通过以下命令查看所有的配置以及它们所在的文件:

$ git config --list 
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=D:/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager-core
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
[email protected]
user.name=rick
gui.recentrepo=C:/Users/贺启衡/Desktop/仓库/rickapi

二、当前状态 git status

我们怎么知道哪些文件是新添加的,哪些文件已经加入了暂存区域呢?总不能让我们自己拿个本本记下来吧? 当然不,作为世界上最伟大的版本控制系统,你能遇到的囧境,Git 早已有了相应的解决方案。随时随地都可以使用git status查看当前状态

$ git status
On branch master
nothing to commit, working tree clean

如果代码报错:git上传代码报错-The file will have its original line endings in your working directory

原因是因为文件中换行符的差别导致的。

这里需要知道CRLF和LF的区别:

windows下的换行符是CRLF而Unix的换行符格式是LF。git默认支持LF。

上面的报错的意思是会把CRLF(也就是回车换行)转换成Unix格式(LF),这些是转换文件格式的警告,不影响使用。

一般commit代码时git会把CRLF转LF,pull代码时LF换CRLF。

解决方案:

git rm -r --cached .
git config core.autocrlf false

然后重新上传代码即可。

为true时,Git会将你add的所有文件视为文本问价你,将结尾的CRLF转换为LF,而checkout时会再将文件的LF格式转为CRLF格式。

为false时,line endings不做任何改变,文本文件保持其原来的样子。

为input时,add时Git会把CRLF转换为LF,而check时仍旧为LF,所以Windows操作系统不建议设置此值。

输入git status命令,提示如下:

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ echo 1234 > b.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git add b.txt

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   b.txt


51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)

Untracked files 说明存在未跟踪的文件(下边红色的那个)

所谓的“未跟踪”文件,是指那些新添加的并且未被加入到暂存区域或提交的文件。它们处于一个逍遥法外的状态,但你一旦将它们加入暂存区域或提交到 Git 仓库,它们就开始受到 Git 的“跟踪”。

这里圆括号中的英文是 git 给我们的建议:使用 git add file 命令将待提交的文件添加到暂存区域。

F:\MyProject>git add LICENSE

F:\MyProject>git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   LICENSE(绿色)

再次添加到暂存区域,然后执行 git commit -m "b.txt" 命令:

修改数据

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ echo 123 > b.txt

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)

修改文件后,使用git status查看数据。

git log 查看历史操作记录

$ git log
commit 5da78a44017dda030d1fe273e2a470792534ba9a (HEAD -> master)
Author: zhangnan <[email protected]>
Date:   Sat Mar 13 16:01:01 2021 +0800

    123

commit c7c0e3bf6d64404e3e68632c24ca13eac38b02e2
Author: zhangnan <[email protected]>
Date:   Sat Mar 13 15:53:38 2021 +0800

    first

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
* d5a12d8a966da5bf36c1f4a080c5d507398f5f59 (HEAD -> master) first

结果中:有head代表当前所处的分之,master代表当前是master分支。可以按下不表。

两次的提交记录看到了。--pretty=oneline

head git 中的分支,其实本质上仅仅是个指向 commit 对象的可变指针。git 是如何知道你当前在哪个分支上工作的呢? 其实答案也很简单,它保存着一个名为 HEAD 的特别指针。在 git 中,它是一个指向你正在工作中的本地分支的指针,可以将 HEAD 想象为当前分支的别名。

三、时光回退 git reset

有关回退的命令有两个:reset 和 checkout

1、回滚快照

注:快照即提交的版本,每个版本我们称之为一个快照。

现在我们利用 reset 命令回滚快照,并看看 Git 仓库和三棵树分别发生了什么。

执行 git reset HEAD~ 命令:

注:HEAD 表示最新提交的快照,而 HEAD~ 表示 HEAD 的上一个快照,HEAD~~表示上上个快照,如果表示上10个快照,则可以用HEAD ~10

此时我们的快找回滚到了第二棵数(暂存区域)

记住:head永远指向当前分支的当前快照

$ git  --hard reset head~

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git log
commit c7c0e3bf6d64404e3e68632c24ca13eac38b02e2 (HEAD -> master)
Author: zhangnan <[email protected]>
Date:   Sat Mar 13 15:53:38 2021 +0800

    first

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)

可以看到,只剩下一个记录了。

image-20210316212457416

参数选择

--hard : 回退版本库,暂存区,工作区。(因此我们修改过的代码就没了,需要谨慎使用)

reset 不仅移动 HEAD 的指向,将快照回滚动到暂存区域,它还将暂存区域的文件还原到工作目录。

--mixed: 回退版本库,暂存区。(--mixed为git reset的默认参数,即当任何参数都不加的时候的参数)

--soft: 回退版本库。

就相当于只移动 HEAD 的指向,但并不会将快照回滚到暂存区域。相当于撤消了上一次的提交(commit)。

image-20210316214437985

2、回滚指定快照

reset 不仅可以回滚指定快照,还可以回滚个别文件。

命令格式为:

git reset --hard  c7c0e3bf6d64404e3e68632c24ca13eac38b02e2

这样,它就会将忽略移动 HEAD 的指向这一步(因为你只是回滚快照的部分内容,并不是整个快照,所以 HEAD 的指向不应该发生改变),直接将指定快照的指定文件回滚到暂存区域。

不仅可以往回滚,还可以往前滚!

这里需要强调的是:reset 不仅是一个“复古”的命令,它不仅可以回到过去,还可以去到“未来”。

唯一的一个前提条件是:你需要知道指定快照的 ID 号。

那如果不小心把命令窗口关了不记得ID号怎么办? 命令:git reflog

git reflog

Git记录的每一次操作的版本ID号

git reset --hard 7ce4954

四、版本对比 git diff

1、暂存区与工作树

目的:对比版本之间有哪些不同

git diff 997ae3c 401812c


diff --git a/aaaa.txt b/aaaa.txt
deleted file mode 100644
index ed7d9b3..0000000
--- a/aaaa.txt
+++ /dev/null
@@ -1 +0,0 @@
-好喜欢姐姐

来解释一下上面每一行的含义:

第一行:diff --git a/aaaa.txt b/aaaa.txt 表示对比的是存放在暂存区域和工作目录的b.txt

第二行:index 9ab39d5..4d37a8a 100644 表示对应文件的 ID 分别是 9ab39d5和 4d37a8a,左边暂存区域,后边当前目录。最后的 100644 是指定文件的类型和权限

第三行:--- a/aaaa.txt

--- 表示该文件是旧文件(存放在暂存区域)

第四行:+++ /dev/null 表示该文件是新文件(存放在工作区域)

第五行:@@ -2,3 +2,4 @@ 以 @@ 开头和结束,中间的“-”表示旧文件,“+”表示新文件,后边的数字表示“开始行号,显示行数”

内容:+代表新增的行 -代表少了的行

直接执行 git diff 命令是比较暂存区域与工作目录的文件内容:

五、删除文件 git checkout

不小心删除文件怎么办?

现在从工作目录中手动删除 b.txt 文件,然后执行 git status 命令:

$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    b.txt

no changes added to commit (use "git add" and/or "git commit -a")

提醒使用 checkout 命令可以将暂存区域的文件恢复到工作目录:

$ git checkout -- b.txt

文件就会重新返回。

那么如何彻底删除一个文件呢?

假如你不小心把小黄图下载到了工作目录,然后又不小心提交到了 Git 仓库:

新增一个c.txt文件

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ echo 123 > c.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git add .
51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git commit -m 'third'
[master 3bd84d8] third
 1 file changed, 1 insertion(+)
 create mode 100644 c.txt

还有方法:

执行 git rm a.txt 命令:

$ git rm c.txt
rm 'c.txt'

此时工作目录中的c.txt已经被删除……

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ ls
a.txt  b.txt  mintty.exe.stackdump

但执行 git status 命令,你仍然发现 Git 还不肯松手:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        deleted:    c.txt

意思是说它在仓库的快照中发现有个叫 c.txt 的东西,但似乎在暂存区域和当前目录不见了!

此时可以执行 git reset --soft HEAD~ 命令将快照回滚到上一个位置,然后重新提交,就好了:

注意:rm 命令删除的只是工作目录和暂存区域的文件(即取消跟踪,在下次提交时不纳入版本管理)

缓冲区和工作树的内容不一致,怎么删除

1、修改b.txt 添加至缓冲区

2、再修改b.txt

3、git rm c.txt

$ echo 123 > b.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git add b.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ echo 123 > b.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git rm b.txt
error: the following file has changes staged in the index:
    b.txt
(use --cached to keep the file, or -f to force removal)

因为两个不同内容的同名文件,谁知道你是不是搞清楚了都要删掉?还是提醒一下好,别等一下出错了又要赖机器…… 根据提示,执行 git rm -f b.txt命令就可以把两个都删除。

我只想删除暂存区域的文件,保留工作目录的,应该怎么操作?

执行 git rm --cached 文件名 命令。

六、重命名文件 git mv

直接在工作目录重命名文件,执行git status出现错误:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        modified:   b.txt

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    b.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        n.txt

正确的姿势应该是:

git mv 旧文件名 新文件名

$ git mv b.txt c.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        renamed:    b.txt -> c.txt

七、忽略文件 .gitignore

如何让Git 识别某些格式的文件,然后自主不跟踪它们? 比如工作目录中有三个文件1.temp、2.temp 和 3.temp,我们不希望后缀名为 temp 的文件被追踪,可是每次执行git status都会出现:

解决办法:在工作目录创建一个名为 .gitignore 的文件。

然后你发现 Windows 压根儿不允许你在文件管理器中创建以点(.)开头的文件。windows需要在命令行窗口创建(.)开头的文件。执行 echo *.temp > .gitignore 命令,创建一个 .gitignore 文件,并让 Git 忽略所有 .temp 后缀的文件:

$ echo *.temp > .gitignore
$ echo *.temp > .gitignore

在工作目录创建 a.temp

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        renamed:    b.txt -> c.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        .gitignore


51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master)

好了,Git 已经忽略了所有的 *.temp 文件(你还可以把 .gitignore 文件也一并忽略)。

八、创建和切换分支 git checkout

1、分支是什么?

假设你的大项目已经上线了(有上百万人在使用),过了一段时间

你突然觉得应该添加一些新的功能,但是为了保险起见,你肯定不能在当前项目上直接进行开发,这时候你就有创建分支的需要了。

image-20210316221252036

对于其它版本控制系统而言,创建分支常常需要完全创建一个源代码目录的副本,项目越大,耗费的时间就越多;而 Git 由于每一个结点都已经是一个完整的项目,所以只需要创建多一个“指针”(像 master)指向分支开始的位置即可。

2、创建分支 git branch ( 分支名)

执行git status查看状态:

$ git status
On branch master

创建分支,使用 git branch 分支名 命令:

没有任何提示说明分支创建成功(一般也不会失败啦,除非创建了同名的分支会提醒你一下),此时可以执行 git log --decorate 命令查看:

如果希望以“精简版”的方式显示,可以加上一个 --oneline 选项(即 git log --decorate --oneline),这样就只用一行来显示一个快照记录。

$ git log
commit 432621d36faf270eae133cfe2e976fc99df479a5 (HEAD -> master, feature01)
Author: zhangnan <[email protected]>
Date:   Sat Mar 13 17:43:53 2021 +0800

    1

commit 4c9e83b6d4ca3ca3d8b0b77bb5aca614dd755413
Author: zhangnan <[email protected]>
Date:   Sat Mar 13 17:11:51 2021 +0800

    123

可以看到最新的快照后边多了一个 (HEAD -> master, feature01)

它的意思是:目前有两个分支,一个是主分支(master),一个是刚才我们创建的新分支(feature),然后 HEAD 指针仍然指向默认的 master 分支。

$ git log --decorate --oneline
432621d (HEAD -> master, feature01) 1
4c9e83b 123
8af2e68 secong
c7c0e3b first

所以目前仓库中的快照应该是这样:head --》 master feature01

3、切换分支 git checkout (分支名)

现在我们需要将工作环境切换到新创建的分支(feature)上,使用的就是之前我们欲言又止的 checkout 命令。执行 git checkout feature 命令:

$ git checkout feature01
Switched to branch 'feature01'

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (feature01)
$ git status
On branch feature01
nothing to commit, working tree clean

4、新建远程分支

新建本地分支 git checkout -b 分支名
推送分支 git push origin 分支名:分支名
git branch -a查看所有分支

小松@Ϊ▒▒▒▒▒שjava MINGW64 ~/Desktop/gitts (master)
$ git branch dev2

小松@Ϊ▒▒▒▒▒שjava MINGW64 ~/Desktop/gitts (master)
$ git branch
  dev1
  dev2
* master

小松@Ϊ▒▒▒▒▒שjava MINGW64 ~/Desktop/gitts (dev2)
$ git push -f origin dev2:dev2
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
remote: Powered by GITEE.COM [GNK-6.4]
remote: Create a pull request for 'dev2' on Gitee by visiting:
remote:     https://gitee.com/rickblog/test/pull/new/rickblog:dev2...rickblog:master
To gitee.com:rickblog/test.git
 * [new branch]      dev2 -> dev2

小松@Ϊ▒▒▒▒▒שjava MINGW64 ~/Desktop/gitts (dev2)
$ git branch -a
  dev1
* dev2
  master
  remotes/origin/dev2
  remotes/origin/master

5、查看远程仓库

git remote -v

小松@Ϊ▒▒▒▒▒שjava MINGW64 ~/Desktop/gitts (dev2)
$ git remote  -v
origin  [email protected]:rickblog/test.git (fetch)
origin  [email protected]:rickblog/test.git (push)

6、查看远程分支

git branch -a

小松@Ϊ▒▒▒▒▒שjava MINGW64 ~/Desktop/gitts (dev2)
$ git branch -a
  dev1
* dev2
  master
  remotes/origin/dev2
  remotes/origin/master

九、合并分支 git merge

新建一个仓库

// 初始化一个仓库
$ git init
// 创建一个a.txt 文件,并且修改他的内容
$ touch a.txt

// 提交该分支
$ git add a.txt
$ git commit -m 'master'

// 切出一个分支
$ git branch feature1
// 切换到该分支
$ git checkout feature1
Switched to branch 'feature1'
// 随意修改a.txt的内容
。。。
// 切换回主分支
$ git checkout master
Switched to branch 'master'
// 合并分支
$ git merge feature1
Updating 540e027..cae5dfc
Fast-forward
 a.txt | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)
image-20210315100125472

当一个子分支的使命完结之后,它就应该回归到主分支中去。

$ git log --decorate --all --graph --online
fatal: unrecognized argument: --online

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (feature01)
$ git log --decorate --all --graph --oneline
* b134862 (HEAD -> feature01) feature01
* f5e0b68 feature01
| * baccb7f (master) master
|/
* 432621d 1
* 4c9e83b 123
* 8af2e68 secong
* c7c0e3b first

合并分支我们使用 merge 命令,执行 git merge feature01命令,将 feature 分支合并到 HEAD 所在的分支(master)上:

第一步 切出一个feature2分支,修改master分支中a.txt第一行数据,

// 先切出一个分支
$ git branch feature2

// 在master分支做修改,修改a.txt的第一行数据
$ git add a.txt

//提交master分支
$ git commit -m 'master'

// 切换到feature2 分支
$ git checkout feature2
Switched to branch 'feature2'

// 同样修改a.txt的第一行数据
$ git add a.txt
// 提交
$ git commit -m feature2
[feature2 0ebb84a] feature2
 1 file changed, 1 insertion(+), 1 deletion(-)

// 切换到master分支
$ git checkout master
Switched to branch 'master'

// 将feature2合并到master分支上
$ git merge feature2
// 发生了问题
Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.

a.txt内容变成了如下:

<<<<<<< HEAD
123123
=======
123345
>>>>>>> feature2

意思是说现在你需要先解决冲突的问题,Git 才能进行合并操作。所谓冲突,无非就是像两个分支中存在同名但内容却不同的文件,Git 不知道你要舍弃哪一个或保留哪一个,所以需要你自己来决定。 此时执行 git status 命令也会显示需要你解决的冲突:

$ git status
On branch master
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

        both modified:   a.txt

no changes added to commit (use "git add" and/or "git commit -a")

以“=======”为界,上到“<<<<<<< HEAD”的内容表示当前分支,下到“>>>>>>> feature”表示待合并的 feature 分支,之间的内容就是冲突的地方。

image-20210315100412732

我们就需要手动修改:

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master|MERGING)
$ git add a.txt

51018@DESKTOP-6R8BLO2 MINGW64 ~/Desktop/git-study (master|MERGING)
$ git commit -m '解决冲突'
[master 569943e] 解决冲突

十、删除分支 git branch -d

当一个功能开发完成,并且成功合并到主分支,我们应该删除分支

使用 git branch -d 分支名 命令:

执行 git log --decorate --all --graph --oneline 命令:

由于 Git 的分支原理实际上只是通过一个指针记载,所以创建和删除分支都几乎是瞬间完成。

注意:如果试图删除未合并的分支,Git 会提示你“该分支未完全合并,如果你确定要删除,请使用 git branch -D 分支名 命令。

十一、变基 git rebase

当我们开发一个功能时,可能会在本地有无数次commit

而你实际上在你的master分支上只想显示每一个功能测试完成后的一次完整提交记录就好了

其他的提交记录并不想将来全部保留在你的master分支上,那么rebase将会是一个好的选择,他可以在rebase时将本地多次的commit合并成一个commit,还可以修改commit的描述等

// 合并前两次的commit
git  rebase -i head~~

// 合并此次commit在最新commit的提交
git rebaser -i hash值

第四章 重要的命令

image-20220802175026090

git commit => git pull =>git push

第五章 提交规范

一、commit 内容

  • feat:提交新功能
  • fix:修复了bug
  • docs:只修改了文档
  • style:调整代码格式,未修改代码逻辑(比如修改空格、格式化、缺少分号等)
  • refactor:代码重构,既没修复bug也没有添加新功能
  • perf:性能优化,提高性能的代码更改
  • test:添加或修改代码测试
  • chore:对构建流程或辅助工具和依赖库(如文档生成等)的更改

二 、pr流程

1、自己先fork代码到自己账户

2、拉倒本地,写代码

3、推到远程仓库

4、提交issue

5、管理员测试,review后统一,就合并了

6、如发生冲突,解决冲突即可

第五章 idea使用git

配置

image-20220808205934848

可以下载码云插件 gitee

从远程仓库拉项目

image-20220808210024383

控制台查看分支提交等信息

image-20220808210111289

提交代码

image-20220808210207084
届ける言葉を今は育ててる
最后更新于 2022-08-08