[TOC]

git正则删除多个分支

1
2
3
4
5
6
7

git branch |grep "202202"|xargs git branch -d 
---
Deleted branch feature-20220211-73776-storeDuplicateInput (was 9a90acb).
Deleted branch feature-20220214-74360-nullExceptionFix (was 39d0bf8).
Deleted branch feature-20220222-74701-lineConfig (was 7078a0e).
Deleted branch feature-20220222-74743-danbianche_0222 (was 0ec74b1).
Deleted branch feature-20220223-74730-projectCargoApplyOptimizin (was d3da632).

git重命名包后还原

对于文件重命名时 不能对文件名直接修改

1

$ git mv file_from file_to

运行 git mv 就相当于运行了下面三条命令：

1
2
3

$ mv README.md README
$ git rm README.md
$ git add README

1. 此时需要放弃缓存中的文件

1

git reset HEAD .

参考：https://www.jianshu.com/p/b74ee1f4135f

2. 清理未被track的文件或者文件目录

1
2
3
4

# 删除未跟踪的文件和目录。
$ git clean -fd
# 删除前如果想要先查看哪些文件可能会被删除，而不执行删除动作，可以在命令后加n，例如：
$ git clean -fdn

参考：https://www.jianshu.com/p/36a5c137a6d2

git合并某分支某次commit到另一个分支

将新分支dev2的一次提交，合并到dev1中

1、切到分支dev2

1
2
3
4
5
6

#切到分支dev2
$ git checkout dev2
#第一步：拿commit id
admin@DESKTOP MINGW64 /d/ideaws/paas (dev2)
$ git log 
commit d9ca57a4ca1xxxxxx (HEAD -> dev2, origin/dev2)

2、切换分支到dev1

1
2
3
4
5

#切换分支到dev1
$ git checkout dev1
#第二步：合并git cherry-pick {commitId}
admin@DESKTOP MINGW64 /d/ideaws/paas (dev1)
$ git cherry-pick d9ca57a4ca1xxxxxx 

上面结束之后，如果不想合并可以用 git cherry-pick –abort 放弃本次合并，否则直接push到远程库 push到远程git仓库

1
2
3

#push到远程git仓库
admin@DESKTOP MINGW64 /d/ideaws/paas (dev1)
$ git push

在本地删除远程分支

比较科学的practice：

1

git push test local:local

將本地local分支的代碼推送到遠程的local分支，前面的test就是指遠程倉庫的名字。第一个local是本地分支的名字，第二个local 是远程分支的名字。名字不一定是lcoal，其它名字都可以的。

平时不太科学，但是能够work的practice：

1

git push

这里运行git push时候省略了一些参数。通常我们只有一个远程repo，所以就默认推送到了远程的origin这个地方。分支的话，就是推送远当前分支到远程分支，如果远程分支上没有当前分支，还需要我们设定远程分支的upstream。

• 如果没有设定远程仓库的名字，就默认推送当前分支绑定的远程分支，如果没有绑定的远程分支，则会报错。
• 如果没有设定分支名字，则自动推送当前分支到远程repo中同名的分支中去。

奇怪的操作，在本地删除远程分支：

通常我们删除远程的分支是在git的服务器端（如gitlab的网页，github的网页）进行的，实际实际上我们也可用通过推送一个空白的分支到某一个远程分支，实现删除某一个远程分支的目的。

1
2
3

[20-10-06 20:30:53 chinglin@macbookpro /Users/chinglin/test/git-test] git:(local) git push test :test1       
To github.com:ChinglinTHU/git-test.git
 - [deleted]         test1

参考：https://zhuanlan.zhihu.com/p/83793718

git reset

https://blog.csdn.net/qq_36431213/article/details/78858848

https://www.cnblogs.com/yaozhongxiao/p/3811130.html

git pull

在公司团队中写完代码就要提交到git上面，因为多人合作，先要将远端的代码pull更新到本地。往往这时候因为大家对同一个文件同一个地方做了操作，导致pull代码冲突发生，工程崩溃。提示错误信息如下：

1
2

error: Your local changes to 'c/environ.c' would be overwritten by merge.  Aborting.
Please, commit your changes or stash them before you can merge.

这个提示意思就是说更新下来的内容和本地修改的内容有冲突，先提交你改变的内容或者先将你本地修改的内容暂时存起来。 下面我们就分几步解决处理这个pull冲突问题.

1.存储本地修改的内容

2.pull内容

3.还原备份暂存的代码

1

git stash pop stash@{0}

stash@{0}是你刚刚备份存储的标记 这时候系统会提示类似以下的信息：

1
2

Auto-merging c/environ.c
CONFLICT (content): Merge conflict in c/environ.c

这个提示内容意思就是系统自动合并修改的内容，但是当中会有冲突，需要解决其中的冲突。

4.解决文件中的冲突内容

打开上面提示的冲突文件，会看到类似的内容：

其中Updated upstream和=======之间的内容是从远端pull下来的代码，=======和Stashed changes之间的内容则是你本地修改的内容。这时候，需要你修改决定留下哪些需要的内容。

最后，解决完冲突，就可以正常git提交了。

git checkout

大体上两个用处：

• 切换或者新建分支
• 将暂存区或者指定commit内容覆盖到工作区。

从暂存区检出到工作区（如果暂存区没有该文件则再从版本库中还原），直接使用git checkout命令会将工作区的文件都覆盖，等价于放弃工作区的更改，当然如果文件没有trace则不会变化

如果你在commit的层面使用check out而非分支层面，HEAD的内容将会是一个commit哈希而非引用。这就是为什么Git能获悉它处在独立的状态的原因。

多数情况，HEAD仅仅是一个你可以直接使用的引用。其他仅仅在使用Git内部工作的底层脚本时才会用到。

mac上git gui查看分支历史报没有gitk

There are two ways to fix this:

1. Unix Way (simple and recommended)
2. Homebrew Way

1. Unix Way: In 4 simple steps

1. Execute which git in the terminal to know the location of your git executable. Open that directory & locate gitk inside the bin folder. Copy the path — typically /usr/local/git/bin
2. Edit your ~/.bash_profile to add the location of local git & gitk in the paths or, simply copy-pasta from the sample written below.

Sample bash_profile:

1
2

# enabling gitk
export PATH=/usr/local/git/bin:$PATH

If you don’t have a bash_profile want to learn how to create one, then click here.

1. This step is relevant if you’re using El Capitan or higher & you run into an unknown color name “lime” error. Locate gitk executable (typically at /usr/local/bin/gitk), take a backup & open it in a text editor. Find all occurences of lime in the file & replace them with "#99FF00".
2. Reload bash: source ~/.bash_profile

Now, run gitk

代码回滚

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

#回退
#仅仅只是撤销已提交的版本库，不会修改暂存区和工作区
git reset --soft <commitid>
#仅仅只是撤销已提交的版本库和暂存区，不会修改工作区
git reset --mixed <commitid>
#彻底将工作区、暂存区和版本库记录恢复到指定的版本库
git reset --hard <commitid>

#回滚
git revert -n <commitid>

关于回滚，一般步骤是

1. 使用 git log 命令，查看分支提交历史，确认需要回退的版本
2. 使用 git reset 或者 git revert 命令，进行版本回退
3. 使用 git push 命令，推送至远程分支（必须！！否则只能本地回退）

这里就重点说一下 git reset 和 git revert 的区别

举个例子，比如在master分支，有以下提交历史（PS：该示例出自这篇文章）:

1
2
3
4

42eae13 (HEAD -> master) 第四次修改
97ea0f9 第三次修改
e50b7c2 第二次修改
3a52650 第一次修改

git revert

在使用git管理代码过程中，很多人应该遇到过一些场景：我已经提交了commit信息，但是我想反悔，不想提交了这个信息，或者公共分支上我提交了commit信息，别人也提交了commit，但是我的commit的代码有些问题，想撤回来不提交。

这种情况下有很多的方式来解决，无非是操作多少和风险的大小而已，比如：

• 公共分支上找到不同分支的父节点，reset以后才重新提交，但是当commit信息混合到一起后，你想找都commit信息都困难。
• 还有一种相对省事的方法你在自己的分支上把不要的都干掉后重新提交，但是如果是上线时候，这样风险也很大。
• 当然还有其他的一些方式方法

还有一种相对简单的方式，那就是 revert 方式（反做撤销）。也就是这篇文章的主角。

git revert基础用法

基础语法

1

git revert -n commit-id

• 只会反做commit-id对应的内容，然后重新commit一个信息，不会影响其他的commit内容

反做多个commit-id

1

git revert -n commit-idA..commit-idB

• 反做commit-idA到commit-idB之间的所有commit
• 注意：使用-n是应为revert后，需要重新提交一个commit信息，然后在推送。如果不使用-n，指令后会弹出编辑器用于编辑提交信息

冲突的相关操作

• 在git操作过程中，最不想看到的一种情况就是冲突，但是，冲突就是一个狗皮膏药，永远避免不了，revert也跑不了这个魔咒，那么我们改怎么处理这个情况

合并冲突后退出

1

git revert --abort

• 当前的操作会回到指令执行之前的样子，相当于啥也没有干，回到原始的状态

合并后退出，但是保留变化

1

git revert --quit

• 该指令会保留指令执行后的车祸现场

合并后解决冲突，继续操作

• 如果遇到冲突可以修改冲突，然后重新提交相关信息

1
2

git add .
git commit -m "提交的信息"

总结

Git reset和git revert的区别

• git reset 是回滚到对应的commit-id，相当于是删除了commit-id以后的所有的提交，并且不会产生新的commit-id记录，如果要推送到远程服务器的话，需要强制推送-f
• git revert 是反做撤销其中的commit-id，然后重新生成一个commit-id。本身不会对其他的提交commit-id产生影响，如果要推送到远程服务器的话，就是普通的操作git push就好了

tag管理

Commitid不容易记住，能不能用一种比较独特的方式去记住每个版本？答：Commitid相当于IP，Tag相当于域名。

1
2
3
4
5
6

#查看当前仓库的标签列表
git tag
#创建分支
git tag <tag name> <branch name>
#删除分支
git tag -d <tag name>

可以看到，master最新版本为第四次修改。

如果发现，在第四次修改有错误，需要回滚到第三次修改，就可以用reset命令来回退。

执行 git reset –hard 97ea0f9,这个时候，git的提交历史变为:

1
2
3

97ea0f9 (HEAD -> master) 第三次修改
e50b7c2 第二次修改
3a52650 第一次修改

可以看到master当前指向97ea0f9这个版本，我们回到了第三次修改。

使用 reset 命令，Git 会把要回退版本之后提交的修改都删除掉。要从第四次修改回退到第一次修改，那么会删除第二、三、四次的修改。【注：这里并不是真正的物理删除】

那如果发现第三次修改有错误，想要恢复第三次修改，却要保留第四次修改呢？

这个时候就可以用revert命令：

1
2

git revert -n 97ea0f9
git commit -m "恢复第三次修改"

Git提交历史会变成：

1
2
3
4
5

33b8b30 (HEAD -> master) Revert "恢复第三次修改"
42eae13 第四次修改
97ea0f9 第三次修改
e50b7c2 第二次修改
3a52650 第一次修改

实际上，Git把第三次修改从提交中剔除(还原)了，还保留了第四次修改，并且产生了新的commit_id。

在实际生产环境中，代码是基于master分支发布到线上的，会有多人进行提交。可能会碰到自己或团队其他成员开发的某个功能在上线之后有Bug,需要及时做代码回滚的操作。

在确认要回滚的版本之后，如果别人没有最新提交，那么就可以直接用reset命令进行版本回退，否则，就可以考虑使用revert命令进行还原修改，不能影响到别人的提交。或者说，除非在非常有把握的情况下，否则不要使用reset强推。

gitignore

1
2
3
4

.gitignore本身就需要忽略，所以此文件也要写进去
.gitignore 文件中可以使用“#”字符开头表示注释，文件夹路径是用“/”字符，文件名可以使用通配符“*”，另外还可以使用“!”字符表示排除。比如 * .class
.gitignore只能忽略那些原来没有被追踪的文件，如果某些文件已经被纳入了版本管理中，则修改.gitignore是无效的。那么解决方法就是先把本地缓存删除（改变成未被追踪状态），然后再提交
每一个文件夹沟可以创建自己的“.gitignore”文件，如果它上层的文件夹也有“.gitignore”文件，这个文件夹也会受到它的影响

CRLF将被LF替换问题

解决步骤：

1. 安装dos2unix

   https://macappstore.org/dos2unix/

2. 转换文件

   

3. 使用说明：https://www.jianshu.com/p/d2e96b2ccab9

git合并冲突后回退

多人合作开发时，将feature合到dev产生冲突，是别人的需要别人去解决冲突，此时可以放弃这次merge让别人去解决即可

1

$ git merge --abort

git stash用法总结

https://www.cnblogs.com/zndxall/archive/2018/09/04/9586088.html

常用git stash命令：

（1）git stash save “save message” : 执行存储时，添加备注，方便查找，只有git stash 也要可以的，但查找时不方便识别。

（2）git stash list ：查看stash了哪些存储

（3）git stash show ：显示做了哪些改动，默认show第一个存储,如果要显示其他存贮，后面加stash@{$num}，比如第二个 git stash show stash@{1}

（4）git stash show -p : 显示第一个存储的改动，如果想显示其他存存储，命令：git stash show stash@{$num} -p ，比如第二个：git stash show stash@{1} -p

（5）git stash apply :应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，git stash apply stash@{$num} ， 比如第二个：git stash apply stash@{1}

（6）git stash pop ：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下,默认为第一个stash,即stash@{0}，如果要应用并删除其他stash，命令：git stash pop stash@{$num} ，比如应用并删除第二个：git stash pop stash@{1}

（7）git stash drop stash@{$num} ：丢弃stash@{$num}存储，从列表中删除这个存储

（8）**git stash clear** ：删除所有缓存的stash

git撤销本地修改

 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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

如果在修改时发现修改错误，而要放弃本地修改时：

一，未使用 git add 缓存代码时：

可以使用 git checkout -- filepathname (比如： git checkout -- readme.md  ，不要忘记中间的 “--” ，不写就成了检出分支了！！)。

放弃所有的文件修改可以使用 git checkout .  命令。

此命令用来放弃掉所有还没有加入到缓存区（就是 git add 命令）的修改：内容修改与整个文件删除。

但是此命令不会删除掉刚新建的文件。因为刚新建的文件还没已有加入到 git 的管理系统中。所以对于git是未知的。自己手动删除就好了。

或者使用下面的命令（git clean命令只适用于当前文件夹，记得切换文件夹）：

# 删除 untracked files

git clean -f

# 连 untracked 的目录也一起删掉

git clean -df

 

二，已经使用了  git add 缓存了代码：

可以使用  git reset HEAD filepathname （比如： git reset HEAD readme.md）来放弃指定文件的缓存，放弃所有的缓存可以使用 git reset HEAD . 命令。

此命令用来清除 git  对于文件修改的缓存。相当于撤销 git add 命令所在的工作。在使用本命令后，本地的修改并不会消失，而是回到了如（一）所示的状态。继续用（一）中的操作，就可以放弃本地的修改。

 

三，已经用 git commit  提交了代码：

可以使用 git reset --hard HEAD^ 来回退到上一次commit的状态。此命令可以用来回退到任意版本：git reset --hard  commitid 

你可以使用 git log 命令来查看git的提交历史。

git log命令总结

•    git log --all 查看所有分支的历史

•    git log --all --graph 查看图形化的 log 地址

•    git log --oneline 查看单行的简洁历史。

•    git log --oneline -n4 查看最近的四条简洁历史。

•    git log --oneline --all -n4 --graph 查看所有分支最近 4 条单行的图形化历史。

•    git help --web log 跳转到git log 的帮助文档网页

 

 

四，git提交命令

git add -u：将文件的修改、文件的删除，添加到暂存区。

将工作空间被修改和被删除的文件添加到暂存区(不包含没有纳入Git管理的新增文件)

git add .：将文件的修改，文件的新建，添加到暂存区。

git add -A：将文件的修改，文件的删除，文件的新建，添加到暂存区。

工作中一般是用到 git add . 或者 git add -A,。今天学习更进一步解了 git add -u 以及他们之间的区别

git add -A相对于git add -u命令的优点 ： 可以提交所有被删除、被替换、被修改和新增的文件到数据暂存区，而git add -u 只能操作跟踪过的文件

git add -A 等同于git add -all

 

总结：

·  git add -A  提交所有变化

·  git add -u  提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)

·  git add .  提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件

 

修改重命名文件：

git mv files Files 只需要一个操作

mac安装git-gui

1
2
3
4

git clone https://github.com/prati0100/git-gui.git
cd git-gui
make
make install

git rebase操作记录

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

1. git log 查看提交日志
2. //以下命令表示合并 6f9b8ecc 往后的 commit(不包括 6f9b8ecc)
git rebase -i 6f9b8ecc
3. 将 被合并的分支 前面的 pick 改为 s 
4. 保存退出后进入提交信息修改界面
5. 改完之后， 本地commit已经合并成了一次提交，此时需要本地push， 分两种情况：
	5.1.feature分支只有你一个人在开发
		直接 git push --force
	5.2. feature分支有多人开发
		git push --force-with-lease origin feature 
		使用该命令在强制覆盖前会进行一次检查如果其他人在该分支上有提交会有一个警告，此时可以避免福改代码的风险。
建议：不管当前分支是否只有自己在使用，在rebase之后，需要强制推送到远端分支时，使用  git push --force-with-lease origin feature  参数来保证分支安全。

git add 与 git commit -am

git add命令是个多功能命令，根据目标文件的状态不同，此命令的效果也不同：可以用它开始跟踪新文件，或者把已跟踪的文件放到暂存区，还能用于合并时把有冲突的文件标记为已解决状态等

我们需要用git add命令来跟踪新文件，但如果使用git commit -am可以省略使用git add命令将已跟踪文件放到暂存区的功能，但是不会对新文件起作用。

远程分支版本回退

1. git clone 远程分支master
2. git checkout 提交错误的分支
3. git reflog
4. 根据操作日志查看想要回退的版本号（或远程提交记录里的版本号）
5. git reset –hard 需要回退到的版本号
6. git push -f

upstream

建立分支与分支之间的流通道

git push -u和git branch –set-upstream-to指令之间的区别

git push -u origin mybranch1 相当于 git push origin mybranch1 + git branch –set-upstream-to=origin/mybranch1 mybranch1

- - depth 1

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

当项目过大时，git clone时会出现error: RPC failed; HTTP 504 curl 22 The requested URL returned error: 504 Gateway Time-out的问题
解决方法很简单，在git clone时加上--depth=1即可解决

克隆的项目只包含最近的一次commit的一个分支，体积很小，即可解决文章开头提到的项目过大导致Timeout的问题，但会产生另外一个问题，他只会把默认分支clone下来，其他远程分支并不在本地，所以这种情况下，需要用如下方法拉取其他分支：

$ git clone --depth 1 https://github.com/dogescript/xxxxxxx.git
$ git remote set-branches origin 'remote_branch_name'
$ git fetch --depth 1 origin remote_branch_name
$ git checkout remote_branch_name

克隆的时候也可以指定版本，例如
git clone --depth=1 -b master https://github.com/apache/xxxx.git xxxProject

清空github仓库而不是删除重新创建

1
2
3
4
5
6
7
8
9

-- Remove the history from
rm -rf .git
-- recreate the repos from the current content only
git init
git add .
git commit -m "Initial commit"
-- push to the github remote repos ensuring you overwrite history
git remote add origin git@github.com:lienhui68/lienhui68.github.io.git
git push -u --force origin master

commit完成之后再修改沿用上次commit log

重新git add， commit改成git commit –amend, 这样就还是一条git log信息

反向忽略

1
2
3

* #忽略所有
!*/ # 取消忽略*/
!.vim/plugin/*

参考：http://www.voidcn.com/article/p-dlwytwql-btn.html

Summary

本节摘取于微信公众号码农田小齐, 作者小齐本齐

CVCS和DVCS

1. 集中化版本控制系统 Centralized Version Control Systems (CVCS)， 比如CVS, Subversion, Perforce, etc. 这种模式相对本地版本控制系统是有所改进的，但是缺点也很明显，如果服务器宕机，那么轻则耽误工作、重则数据丢失。于是分布式版本控制系统应运而生。

2. 分布式版本控制系统 Distributed Version Control Systems (DVCS)， 比如：Git, Mercurial, Bazaar, etc. 分布式的版本控制系统会把代码仓库完整地镜像下来，这样任何一个服务器发生故障，都可以用其他的仓库来修复。

什么叫“把代码仓库完整地镜像下来” CVCS 每个版本存放的是当前版本与前一个版本的差异，因此也被称作基于差异的版本控制 (delta-based)； Git 存储的是所有文件的一个快照 (snapshot)，如果有的文件没有修改，那就只保留一个 reference 指向之前存储的文件。

更进一步，这种模式可以更方便的和不同公司的人进行同一项目的开发，因为两个远程代码仓库可以交互，这在之前的集中式系统中是无法做到的。

Git的数据模型

1. 什么是快照 (snapshot) 首先我们来学两个 Git 中的术语：

• blob, 就是单个的文件；
• tree, 就是一个文件夹。

快照则是被追踪的最顶层的树。 比如我的“公众号”文件夹的这么一个结构： 那么一个快照就是追踪的“公众号”这颗树。

2. 本地库的数据模型 Git 记录了每个快照的 parent，也就是当前这个文件夹的上一个版本。 那么快照的迭代更新的过程就可以表示为一个有向无环图。 每个快照其实都对应了一次 commit。

1
2
3
4
5
6

class commit {
  array<commit> parents
  String author
  String message
  Tree snapshot
}

这就是 Git 的数据模型。 blob, tree, snapshot 其实都一样，它们在 Git 中都是对象，都可以被引用或者被搜索，会基于它们的 SHA-1 hash 进行寻址。

git cat-file -t: 查看每个 SHA-1 的类型; git cat-file -p: 查看每个对象的内容和简单的数据结构。

但是通过这个哈希值来搜索也太不方便了，毕竟这是一串 40 位的十六进制字符，就是第二部分 git log 里输出的那个编码。 因此，Git 还给了一个引用 reference。比如，我们常见的 HEAD 就是一个特殊的引用。本地库就是由 对象 和 引用 构成的，或者叫 Repositories. 在硬盘上，Git 只存储 对象 和 引用，所有的 Git 命令都对应提交一个快照。

远程分支、远程跟踪分支、跟踪分支

远程分支就是在远程仓库上的普通分支。远程跟踪分支是在本地的只读的记录远程分支状态的分支，其指向用户无法移动，当使用git fetch等指令时其指向会依照远程仓库自动移动。跟踪分支是从远程跟踪分支上生成的本地分支，跟踪分支提供了本地分支与远程分支更紧密的联系，可以看出本地分支与对应的远程分支的超前落后情况，也可以使用git pull 指令轻松的将远程分支拉取到对应的跟踪分支。

git命令

git reflog 显示单行log git reset –hard xxx 三个区都同步，都跳到这个 xxx 的版本上。 git reset –soft xxx 工作区和暂存区不同步，本地仓库跳到这个版本 git reset –mixed xxx 暂存区同步 git pull = fetch + merge git fetch 这个操作是将远程库的数据下载到本地库，但是工作区中的文件没有更新。 merge 是 git pull 默认的选项，合并其实还有另外一种方法：rebase，中文叫做变基。 git rebase rebase 的作用更多的是来整合分叉的历史，可以将某个分支上的所有修改都移到另一分支上，就像是变了基底。 git help eg:git help pull