Git学习

目标：

了解Git基本概念

能够概述git工作流程

能够使用Git常用命令

熟悉Git代码托管服务

能够使用idea操作git

概述

开发中的实际场景

场景一：备份

小明负责的模块就要完成了，就在即将Release之前的一瞬间，电脑突然蓝屏，硬盘光荣牺牲！几个月来的努力付之东流

场景二：代码还原

这个项目中需要一个很复杂的功能，老王摸索了一个星期终于有眉目了，可是这被改得面目全非的代码已经回不到从前了。什么地方能买到哆啦A梦的时光机啊？

场景三：协同开发

小刚和小强先后从文件服务器上下载了同一个文件：Analysis.java。小刚在Analysis.java文件中的第30行声明了一个方法，叫count()，先保存到了文件服务器上；小强在Analysis.java文件中的第50行声明了一个方法，叫sum()，也随后保存到了文件服务器上，于是，count()方法就只存在于小刚的记忆中了

场景四：追溯问题代码的编写人和编写时间！

老王是另一位项目经理，每次因为项目进度挨骂之后，他都不知道该扣哪个程序员的工资！就拿这次来说吧，有个Bug调试了30多个小时才知道是因为相关属性没有在应用初始化时赋值！可是二胖、王东、刘流和正经牛都不承认是自己干的！

Git教程 - 廖雪峰的官方网站 (liaoxuefeng.com)

Git 是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。

Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。

Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持。

Git 不仅仅是个版本控制系统，它也是个内容管理系统(CMS)，工作管理系统等。

Git 是分布式的

Git 把内容按元数据方式存储

Git 没有一个全局的版本号

Git 的工作流程。

一般工作流程如下：

克隆 Git 资源作为工作目录。

在克隆的资源上添加或修改文件。

如果其他人修改了，你可以更新资源。

在提交前查看修改。

提交修改。

在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

Git是什么

Git是目前世界上最先进的分布式版本控制系统（没有之一）。

有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以，岂不是很方便？

这就是git。

集中式和分布式的区别

先说集中式版本控制系统，版本库是集中存放在中央服务器的，而干活的时候，用的都是自己的电脑，所以要先从中央服务器取得最新的版本，然后开始干活，干完活了，再把自己的活推送给中央服务器。中央服务器就好比是一个图书馆，你要改一本书，必须先从图书馆借出来，然后回到家自己改，改完了，再放回图书馆。

集中式版本控制系统最大的毛病就是必须联网才能工作。

分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题，所有人都没法干活了。

分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

其实都可以不用看，就是方便交换，和方便找回历史版本。

简易版本：

a、集中式版本控制工具

集中式版本控制工具，版本库是集中存放在中央服务器的，team里每个人work时从中央服务器下载代码，是必须联网才能工作，局域网或互联网。个人修改后然后提交到中央版本库。举例：SVN和CVS

b、分布式版本控制工具

分布式版本控制系统没有“中央服务器”，每个人的电脑上都是一个完整的版本库，这样工作的时候，无需要联网了，因为版本库就在你自己的电脑上。多人协作只需要各自的修改推送给对方，就能互相看到对方的修改了。举例：Git

Git是分布式的,Git不需要有中心服务器，我们每台电脑拥有的东西都是一样的。我们使用Git并且有个中心服务器，仅仅是为了方便交换大家的修改，但是这个服务器的地位和我们每个人的PC是一样的。我们可以把它当做一个开发者的pc就可以就是为了大家代码容易交流不关机用的。没有它大家一样可以工作，只不过“交换”修改不方便而已。

git是一个开源的分布式版本控制系统，可以有效、高速地处理从很小到非常大的项目版本管理。Git是LinusTorvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。同生活中的许多伟大事物一样，Git诞生于一个极富纷争大举创新的年代。

特点：

速度

简单的设计

对非线性开发模式的强力支持（允许成千上万个并行开发的分支）

完全分布式

有能力高效管理类似Linux内核一样的超大规模项目（速度和数据量）

创建版本库

创建一个版本库非常简单

首先，选择一个合适的地方，创建一个空目录：

第二步，通过git init命令把这个目录变成Git可以管理的仓库：

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 ~
$ cd C:/git

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git
$ git init
Initialized empty Git repository in C:/git/.git/

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$

瞬间Git就把仓库建好了，而且告诉你是一个空的仓库（empty Git repository），读者可以发现当前目录下多了一个.git的目录，这个目录是Git来跟踪管理版本库的.

把文件添加到版本库

所有的版本控制系统，其实只能跟踪文本文件的改动，比如TXT文件，网页，所有的程序代码等等，Git也不例外。版本控制系统可以告诉你每次的改动，比如在第5行加了一个单词“Linux”，在第8行删了一个单词“Windows”。而图片、视频这些二进制文件，虽然也能由版本控制系统管理，但没法跟踪文件的变化，只能把二进制文件每次改动串起来，也就是只知道图片从100KB改成了120KB，但到底改了啥，版本控制系统不知道，也没法知道。

不幸的是，Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的.如果要真正使用版本控制系统，就要以纯文本方式编写文件。

千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。建议你下载Visual Studio Code代替记事本，不但功能强大，而且免费！

我们编写一个readme.txt文件

第一步，用命令git add告诉Git，把文件添加到仓库：

1	$ git add readme.txt

执行上面的命令，没有任何显示，这就对了，Unix的哲学是“没有消息就是好消息”，说明添加成功。

第二步，用命令git commit告诉Git，把文件提交到仓库：

$ git commit -m "wrote a readme file"
[master (root-commit) eaadf4e] wrote a readme file
 1 file changed, 2 insertions(+)
 create mode 100644 readme.txt

简单解释一下git commit命令，-m后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

git commit命令执行成功后会告诉你，1 file changed：1个文件被改动（我们新添加的readme.txt文件）；2 insertions：插入了两行内容（readme.txt有两行内容）。

为什么Git添加文件需要add，commit一共两步呢？因为commit可以一次提交很多文件，所以你可以多次add不同的文件，比如：

1
2
3

$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

我们继续修改readme.txt文件，改成如下内容：

1 2	Git is a distributed version control system. Git is free software.

运行git status

结果：

$ 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:   readme.txt

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

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。

虽然Git告诉我们readme.txt被修改了，但如果能看看具体修改了什么内容，自然是很好的。

用git diff这个命令看看：

$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index d8036c1..013b5bc 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.
\ No newline at end of file

git diff顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令输出看到，我们在第一行添加了一个distributed单词。

知道了对readme.txt作了什么修改后，再把它提交到仓库就放心多了，提交修改和提交新文件是一样的两步，第一步是git add：

1	git add readme.txt

在执行第二步git commit之前，我们再运行git status看看当前仓库的状态：

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

	modified:   readme.txt

git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：

1
2
3

$ git commit -m "add distributed"
[master e475afc] add distributed
 1 file changed, 1 insertion(+), 1 deletion(-)

提交后，我们再用git status命令看看仓库的当前状态：

1
2
3

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

Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。

再练习一次，修改readme.txt文件如下：

1 2	Git is a distributed version control system. Git is free software distributed under the GPL.

然后尝试提交：

$ git add readme.txt
$ git commit -m "append GPL"
[master 1094adb] append GPL
 1 file changed, 1 insertion(+), 1 deletion(-)

现在有3个版本

版本1：wrote a readme file

1 2	Git is a version control system. Git is free software.

版本2：add distributed

1 2	Git is a distributed version control system. Git is free software.

版本3：append GPL

1 2	Git is a distributed version control system. Git is free software distributed under the GPL.

版本控制系统肯定有某个命令可以告诉我们历史记录，在Git中，我们用git log命令查看：

git log
commit 924531b540244b41d7864b5e9277a0dc1c473387 (HEAD -> master)
Author: Totoro <zwj12345_2020@qq.com>
Date:   Sat Feb 24 00:42:53 2024 +0800

    append GPL

commit 458011a8935b724e6018729b0cb74d4abe10f782
Author: Totoro <zwj12345_2020@qq.com>
Date:   Sat Feb 24 00:41:34 2024 +0800

    add distributed

commit 818bb5f0a4501f36b721b87413edbf9713e80a29
Author: Totoro <zwj12345_2020@qq.com>
Date:   Sat Feb 24 00:34:41 2024 +0800

    wrote a readme file

git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。

如果嫌输出信息太多，看得眼花缭乱的，可以试试加上--pretty=oneline参数：

 git log --pretty=oneline
924531b540244b41d7864b5e9277a0dc1c473387 (HEAD -> master) append GPL
458011a8935b724e6018729b0cb74d4abe10f782 add distributed
818bb5f0a4501f36b721b87413edbf9713e80a29 wrote a readme file

现在我们启动时光穿梭机，准备把readme.txt回退到上一个版本，也就是add distributed的那个版本，怎么做呢？

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交1094adb...（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。

我们要把当前版本append GPL回退到上一个版本add distributed，就可以使用git reset命令：

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git reset --hard HEAD^
HEAD is now at 458011a add distributed

看看readme.txt的内容是不是版本add distributed：

1
2
3

$ cat readme.txt
Git is a distributed version control system.
Git is free software.

还可以继续回退到上一个版本wrote a readme file，不过且慢，让我们用git log再看看现在版本库的状态：

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git log
commit 458011a8935b724e6018729b0cb74d4abe10f782 (HEAD -> master)
Author: Totoro <zwj12345_2020@qq.com>
Date:   Sat Feb 24 00:41:34 2024 +0800

    add distributed

commit 818bb5f0a4501f36b721b87413edbf9713e80a29
Author: Totoro <zwj12345_2020@qq.com>
Date:   Sat Feb 24 00:34:41 2024 +0800

    wrote a readme file

最新的那个版本append GPL已经看不到了！

办法其实还是有的，只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是924513b...，于是就可以指定回到未来的某个版本：

1
2
3

 git reset --hard 924531b
HEAD is now at 924531b append GPL

再小心翼翼地看看readme.txt的内容：

1
2
3

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.

又回来了

┌────┐
│HEAD│
└────┘
   │
   └──▶ ○ append GPL
        │
        ○ add distributed
        │
        ○ wrote a readme file
┌────┐
│HEAD│
└────┘
   │
   │    ○ append GPL
   │    │
   └──▶ ○ add distributed
        │
        ○ wrote a readme file

还有一种通用的

当你用$ git reset --hard HEAD^回退到add distributed版本时，再想恢复到append GPL，就必须找到append GPL的commit id。Git提供了一个命令git reflog用来记录你的每一次命令：

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git reflog
924531b (HEAD -> master) HEAD@{0}: reset: moving to 924531b
458011a HEAD@{1}: reset: moving to HEAD^
924531b (HEAD -> master) HEAD@{2}: commit: append GPL
458011a HEAD@{3}: commit: add distributed
818bb5f HEAD@{4}: commit (initial): wrote a readme file

Git 工作区、暂存区和版本库

工作区：就是你在电脑里能看到的目录。
暂存区：英文叫 stage 或 index。一般存放在 .git 目录下的 index 文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
版本库：工作区有一个隐藏目录 .git，这个不算工作区，而是 Git 的版本库。

图中左侧为工作区

右侧为版本库。

在版本库中标记为 "index" 的区域是暂存区（stage/index）

标记为 "master" 的是 master 分支所代表的目录树。

图中我们可以看出此时 "HEAD" 实际是指向 master 分支的一个"游标"。所以图示的命令中出现 HEAD 的地方可以用 master 来替换。

图中的 objects 标识的区域为 Git 的对象库，实际位于 ".git/objects" 目录下，里面包含了创建的各种对象及内容。

当对工作区修改（或新增）的文件执行 git add 命令时，暂存区的目录树被更新，同时工作区修改（或新增）的文件内容被写入到对象库中的一个新的对象中，而该对象的ID被记录在暂存区的文件索引中。

当执行提交操作（git commit）时，暂存区的目录树写到版本库（对象库）中，master 分支会做相应的更新。即 master 指向的目录树就是提交时暂存区的目录树。

当执行 git reset HEAD 命令时，暂存区的目录树会被重写，被 master 分支指向的目录树所替换，但是工作区不受影响。

当执行 git rm --cached 命令时，会直接从暂存区删除文件，工作区则不做出改变。

当执行 git checkout . 或者 git checkout -- 命令时，会用暂存区全部或指定的文件替换工作区的文件。这个操作很危险，会清除工作区中未添加到暂存区中的改动。

当执行 git checkout HEAD . 或者 git checkout HEAD 命令时，会用 HEAD 指向的 master 分支中的全部或者部分文件替换暂存区和以及工作区中的文件。这个命令也是极具危险性的，因为不但会清除工作区中未提交的改动，也会清除暂存区中未提交的改动。

工作区（Working Directory）

就是你在电脑里能看到的目录，比如我的git文件夹就是一个工作区：

版本库（Repository）

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库。

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。

我们再练习一遍，先对readme.txt做个修改，比如加上一行内容：

1
2
3

Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.

然后，在工作区新增一个nih文本文件（内容随便写）。

先用git status查看一下状态：

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

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

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

readme.txt被修改了，而nih还从来没有被添加过，所以它的状态是Untracked。

使用两次命令git add，把readme.txt和LICENSE都添加后，用git status

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   nih.txt
        modified:   readme.txt

![git-stage]/images/0-1708708125974-5.jpeg)

git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$  git commit -m "understand how stage works"
[master a73f933] understand how stage works
 2 files changed, 3 insertions(+), 1 deletion(-)
 create mode 100644 nih.txt

如果你又没有对工作区做任何修改，那么此时工作区就是“干净”的：

1
2
3

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

Git跟踪并管理的是修改，而非文件。

举例：

第一步，对readme.txt做一个修改

1	git add readme.txt

添加：

再修改readme.txt：

不添加

提交：

1	$ git commit -m "git tracks changes"

第二次的修改没有被提交

怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

撤销修改

分为add之前，add之后，commit之后

你正在赶一份工作报告，你在readme.txt中添加了一行：

$ cat readme.txt
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.

你可以删掉最后一行，手动把文件恢复到上一个版本的状态。如果用git status查看一下：

$ 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:   readme.txt

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

而git checkout -- file可以丢弃工作区的修改：

1	$ git checkout -- readme.txt

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

让这个文件回到最近一次git commit或git add时的状态。

git add到暂存区了：

git status查看一下，修改只是添加到了暂存区，还没有提交：

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

	modified:   readme.txt

用命令git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区：

1
2
3

$ git reset HEAD readme.txt
Unstaged changes after reset:
M	readme.txt

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

再用git status查看一下，现在暂存区是干净的，工作区有修改：

$ 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:   readme.txt

还记得如何丢弃工作区的修改吗？

$ git checkout -- readme.txt

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

假设你不但改错了东西，还从暂存区提交到了版本库，怎么办呢？还记得[版本回退]吗？可以回退到上一个版本。不过，这是有条件的，就是你还没有把自己的本地版本库推送到远程。

删除文件

你通常直接在文件管理器中把没用的文件删了，或者用rm命令删了：

1	$ rm test.txt

这个时候，Git知道你删除了文件，

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:    test.txt

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

一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit：

$ git rm test.txt
rm 'test.txt'

$ git commit -m "remove test.txt"
[master d46f35e] remove test.txt
 1 file changed, 1 deletion(-)
 delete mode 100644 test.txt

文件就从版本库中被删除了。

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

1	$ git checkout -- test.txt

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

远程仓库

只要注册一个GitHub账号，就可以免费获得Git远程仓库。

你已经在本地创建了一个Git仓库后，又想在GitHub创建一个Git仓库，并且让这两个仓库进行远程同步，这样，GitHub上的仓库既可以作为备份，又可以让其他人通过该仓库来协作，真是一举多得。

首先，登陆GitHub，然后，在右上角找到“Create a new repo”按钮，创建一个新的仓库：

在Repository name填入git，其他保持默认设置，点击“Create repository”按钮，就成功地创建了一个新的Git仓库：

在本地的git仓库下运行命令：

就可以把本地库的所有内容推送到远程库上

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git remote add origin git@github.com:4512abc/git.git

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git push -u origin master
Enumerating objects: 13, done.
Counting objects: 100% (13/13), done.
Delta compression using up to 20 threads
Compressing objects: 100% (9/9), done.
Writing objects: 100% (13/13), 1.04 KiB | 533.00 KiB/s, done.
Total 13 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), done.
To github.com:4512abc/git.git

 * [new branch]      master -> master
   branch 'master' set up to track 'origin/master'.

推送成功后，可以立刻在GitHub页面中看到远程库的内容已经和本地一模一样：

从现在起，只要本地作了提交，就可以通过命令：

1	$ git push origin master

把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！

分支管理

分支不是解决分工问题的，是解决质量问题的。

比如：一个任务，两个人做。

其一，开两个分支，谁的分支先上来，我合并谁的。

其二，两个分支，如果其中一个人的分支有后期bug，那么我可以切换到另一个人的分支上。

其三，同一个人开两个分支，就是两个方案。

首先，我们创建dev分支，然后切换到dev分支：

1 2	$ git checkout -b dev Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：

1
2
3

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后，用git branch命令查看当前分支：

1
2
3

$ git branch
* dev
  master

我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行并提交

dev分支的工作完成，我们就可以切换回master分支：

1 2	$ git checkout master Switched to branch 'master'

现在，我们把dev分支的工作成果合并到master分支上：

$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

合并完成后，就可以放心地删除dev分支了：

1 2	$ git branch -d dev Deleted branch dev (was b17d20e).

删除后，查看branch，就只剩下master分支了：

1 2	$ git branch * master

切换分支这个动作，用switch更科学。因此，最新版本的Git提供了新的git switch命令来切换分支：

创建并切换到新的dev分支，可以使用：

1	$ git switch -c dev

直接切换到已有的master分支，可以使用：

1	$ git switch master

使用新的git switch命令，比git checkout要更容易理解。

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

实战一下--no-ff方式的git merge：

首先，仍然创建并切换dev分支：

1 2	$ git switch -c dev Switched to a new branch 'dev'

修改readme.txt文件，并提交一个新的commit：

$ git add readme.txt 
$ git commit -m "add merge"
[dev f52c633] add merge
 1 file changed, 1 insertion(+)

我们切换回master：

1 2	$ git switch master Switched to branch 'master'

合并dev分支，--no-ff参数，表示禁用Fast forward`：

$ git merge --no-ff -m "merge with no-ff" dev
Merge made by the 'recursive' strategy.
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

，我们用git log看看分支历史：

$ git log --graph --pretty=oneline --abbrev-commit
*   e1e9c68 (HEAD -> master) merge with no-ff
|\  
| * f52c633 (dev) add merge
|/  
*   cf810e4 conflict fixed
...

Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

1 2	$ git stash Saved working directory and index state WIP on dev: f52c633 add merge

现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'

现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交：

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git switch master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

$ git switch dev
Switched to branch 'dev'

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

工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

1 2	$ git stash list stash@{0}: WIP on dev: f52c633 add merge

工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

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

	new file:   hello.py

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:   readme.txt

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)

再用git stash list查看，就看不到任何stash内容了：

1	$ git stash list

你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：

1	$ git stash apply stash@{0}

dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

只需要把4c805e2 fix bug 101这个提交所做的修改“复制”到dev分支。

1	git cherry-pick 4c805e2

1 2	点“Fork”就在自己的账号下克隆了一个bootstrap仓库，然后，从自己的账号下clone： git branch -d feature-vulcan

如果要强行删除，需要使用大写的-D参数。。

现在我们强行删除：

1	$ git branch -D feature-vulcan

要查看远程库的信息，用git remote：

1 2	$ git remote origin

用git remote -v显示更详细的信息：

$ git remote -v
origin  git@github.com:4512abc/git.git (fetch)
origin  git@github.com:4512abc/git.git (push)
上面显示了可以抓取和推送的origin的地址。

推送分支

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

1	$ git push origin master

如果要推送其他分支，比如dev，就改成：

1	$ git push origin dev

标签管理

Git有commit，为什么还要引入tag？

“请把上周一的那个版本打包发布，commit号是6a5819e...”

“一串乱七八糟的数字不好找！”

如果换一个办法：

“请把上周一的那个版本打包发布，版本号是v1.2”

“好的，按照tag v1.2查找commit就行！”

首先，切换到需要打标签的分支上：

$ git branch
* dev
  master
$ git checkout master
Switched to branch 'master'

然后，敲命令git tag <name>就可以打一个新标签：

1	$ git tag v1.0

可以用命令git tag查看所有标签：

1 2	$ git tag v1.0

历史提交的commit id，打上标签

再用命令git tag查看标签：

$ git log --pretty=oneline --abbrev-commit
a73f933 (HEAD -> master, tag: v1.0, origin/master, dev) understand how stage works
924531b append GPL
458011a add distributed
818bb5f wrote a readme file

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git tag v0.9 458011a

86150@▒▒▒▒▒▒▒▒▒▒ MINGW64 /c/git (master)
$ git tag
v0.9
v1.0

1
2
3

$ git tag
v0.9
v1.0

git show <tagname>查看标签信息

git show v0.9
commit 458011a8935b724e6018729b0cb74d4abe10f782 (tag: v0.9)
Author: Totoro <zwj12345_2020@qq.com>
Date:   Sat Feb 24 00:41:34 2024 +0800

    add distributed

diff --git a/readme.txt b/readme.txt
index d8036c1..013b5bc 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.
\ No newline at end of file

1 2	用-a指定标签名，-m指定说明文字： git tag -a v0.1 -m "version 0.1 released" 1094adb

删除标签

如果标签打错了，也可以删除：

1 2	$ git tag -d v0.1 Deleted tag 'v0.1' (was f15b0dd)

如果要推送某个标签到远程，使用命令git push origin <tagname>：

1	$ git push origin v1.0

次性推送全部尚未推送到远程的本地标签：

1	$ git push origin --tags

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

1	$ git tag -d v0.9

从远程删除。删除命令也是push，但是格式如下：

1	$ git push origin :refs/tags/v0.9

参与一个开源项目

michaelliao是github用户名，

bootstrap.git是克隆的仓库

点“Fork”就在自己的账号下克隆了一个bootstrap仓库，然后，从自己的账号下clone：

1	git clone git@github.com:michaelliao/bootstrap.git