Git 使用笔记

参考链接：

创建版本库 - Git教程 - 廖雪峰的官方网站

Git使用教程,最详细，最傻瓜，最浅显，真正手把手教 - 知乎

命令使用

cd f:        切换目录到 F 盘

cd gitCxl        切换目录到 gitCxl 文件夹

mkdir gitCxl        创建新文件夹 gitCxl

pwd        打印当前目录

git init        将当前目录设置为git可管理的仓库

git add readme.txt        将 readme.txt 添加到暂存区

git commit -m "提交说明"        把暂存区内的所有文件提交到仓库

常用的 git commit 参数和选项：

• -m <message> 或 --message=<message>
  • 直接在命令行上指定提交信息（commit message）。这是最常用的参数之一，因为它允许你快速附加一条描述性消息来解释更改。
• -a 或 --all
  • 自动将所有已跟踪文件的更改（包括那些没有被 git add 明确添加到暂存区的文件）提交。这通常用于快速提交所有更改，但请注意，它不会添加新文件到仓库中。
• -v 或 --verbose
  • 在提交时显示差异（diff）和提交信息。这有助于在提交前再次确认更改。
• --amend
  • 修改最近的提交。这允许你更改最近的提交信息或添加更多更改到该提交中，而不是创建一个新的提交。
• --signoff 或 -s
  • 在提交信息中添加一个签名行（Signed-off-by），这通常用于表示你同意某些开发准则或协议。
• --no-verify
  • 绕过提交前的钩子（hook）脚本。Git 允许你在提交前运行自定义脚本以检查代码风格、测试等。使用此选项可以跳过这些检查。
• --allow-empty
  • 允许创建一个空的提交（即没有更改的提交）。这通常用于记录项目状态或触发某些构建/部署流程。
• --allow-empty-message
  • 允许提交一个空的提交信息（即不附带任何描述）。通常，Git 会阻止这种提交以防止无意义的提交记录。
• --template=<file>
  • 使用指定的文件作为提交信息的模板。这可以帮助你遵循特定的提交信息格式或包含额外的信息。
• --author=<author>
  • 指定提交的作者信息。这通常用于修复错误的作者信息或代表其他人提交更改。
• --date=<date>
  • 指定提交的日期和时间。这可以用于调整提交的时间戳，但通常不建议这样做，因为它可能会混淆项目的历史记录。

git status        查看是否还有文件未提交(状态)

git diff readme.txt        查看readme.txt文件内的改动

git log        查看从近到远的提交日志(历史记录)

git log --pretty=oneline        只查看提交说的注释信息

————

回退到上一个版本：git reset --hard HEAD^

回退到上上个版本：git reset --hard HEAD^^

回退到前100个版本：git reset --hard HEAD~100

注：

--hard会回退到上个版本的已提交状态，

--soft会回退到上个版本的未提交状态，

--mixed会回退到上个版本已添加但未提交的状态。

————

cat readme.txt        查看readme.txt的内容(实验发现是本地文件的内容，不是仓库中文件的内容)

git reflog        获取版本号；

git reset --hard 版本号        回退到版本号对应的那个版本

git diff HEAD -- readme.txt        查看工作区和版本库里面最新版本的区别

git checkout -- readme.txt        丢弃工作区的修改，把readme.txt文件在工作区做的修改全部撤销，有两种情况：（其实就是检出）（也可以把checkout换成resrore）

1. 若自修改后未放到暂存区，则回退到版本库的状态；
2. 若修改后已经放入暂存区，则回退到添加暂存区后的状态。

• 注意：命令git checkout -- readme.txt 中的 -- 很重要，若没有 -- 的话，则命令变成创建分支(切换到另一个分支)。

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

git restore <file>        丢弃工作区的更改

git restore --staged <file>        撤销暂存区提交(只会删除暂存区的文件，不会影响工作目录)

rm b.txt        删除工作区的b.txt文件

git rm b.txt        从版本库中删除 b.txt 文件(删除后记得 git commit 提交)

———— 【添加/删除远程库 & 从远程库克隆】

ssh-keygen -t rsa -C "youremail@example.com"        创建SSH Key

git remote add origin https://github.com/chxin14160/gitCxl.git        在本地的 gitCxl 仓库下运行，关联GitHub仓库

git push -u origin master        初次提交，把本地master分支的最新修改推送到github上

git push origin master        把本地master分支的最新修改推送到github上

git remote -v        查看远程库信息

git remote rm origin        删除远程库 origin（解除了本地和远程的绑定关系）

git clone https://github.com/chxin14160/gitCxl2        从GitHub的对应地址中克隆一个本地库

———— 【分支管理】

git branch dev        创建分支

git checkout dev        切换分支dev（或者 git switch name）

git checkout -b dev        创建并切换分支dev（或者 git switch -c name）

（git checkout -b dev 相当于 git branch dev 创建分支dev + git checkout dev 切换分支dev）

git branch        查看当前分支，会列出所有的分支，当前分支前面会添加一个星号 “*”

git merge dev        在master上运行，把dev的内容和合并到当前分支master上(合并指定分支到当前分支)

git branch –d dev        删除分支dev

也就是：

• 切换分支：git checkout name 或者 git switch name
• 创建+切换分支：git checkout –b name 或者 git switch -c name

👉初始创建版本库

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

因为Git是分布式版本控制系统，所以需要填写用户名和邮箱作为一个标识。

注意：git config --global 参数，有了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然你也可以对某个仓库指定的不同的用户名和邮箱。

cd 是 "change directory" 的缩写，意为“切换目录”；

mkdir 是 "make directory" 的缩写，用于创建新目录（文件夹）；

pwd 是 "print working directory" 的缩写，意为“打印当前工作目录”，用于显示当前的目录；

git init 把当前的这个目录变成 git可以管理的仓库。

git add readme.txt 将版本库gitCxl目录下的记事本文件 readme.txt添加到暂存区里面去(没有任何提示，则说明已经添加成功)。

git commit 告诉Git，把文件提交到仓库 (-m后" "里的内容为本次提交的注释说明)。

git commit命令执行成功后会告诉你：

• 1 file changed：1个文件被改动（我们新添加的readme.txt文件）；
• 2 insertions：插入了两行内容（readme.txt有两行内容）。

git status 来查看是否还有文件未提交。

• 黄色：说明没有任何文件未提交；
• 蓝色：告诉我们 readme.txt 文件已被修改，但是未被提交的修改。

git diff readme.txt 查看readme.txt文件到底改了什么内容，如下：

如上可看到，readme.txt文件内容从二行改成 三行 添加了一行22222222内容。

知道了对readme.txt文件做了什么修改后，我们可以放心的提交到仓库了，提交修改和提交文件是一样的2步(第一步是git add 第二步是：git commit)。

输入git add readme.txt，

报错1：fatal: not a git repository (or any of the parent directories)。

原因：Git命令必须在Git仓库目录内执行（git init除外），在仓库目录外执行是没有意义的。

报错2：fatal: pathspec 'readme.txt' did not match any files。

原因：添加某个文件时，该文件必须在当前目录下存在，用ls或者dir命令查看当前目录的文件，看看文件是否存在，或者是否写错了文件名。

• 总结：

初始化一个Git仓库，使用git init命令。

添加文件到Git仓库，分两步：

1. 使用命令git add <file>，（可反复多次使用，添加多个文件）；
2. 使用命令git commit -m <message>，完成。

👉版本管理

1、查看提交日志

git log 查看历史记录，显示从最近到最远的提交日志。

文件修改内容：

初始：（版本一）
Git is a version control system.
Git is free software.

第一次修改后：（版本二）
Git is a version control system.
Git is free software.
22222222
33333333

第二次修改后：（版本三）
Git is a version control system.
Git is free software.
22222222

如果嫌输出的信息太多，则可加上--pretty=oneline参数。

即，使用命令 git log --pretty=oneline 演示：

黄色一大串类似1094adb...的是commit id（版本号）。

和SVN不一样，Git的commit id不是1，2，3……递增的数字，而是一个SHA1计算出来的一个非常大的数字，用十六进制表示。commit id以自己的为准。

commit id需要用这么一大串数字表示是因为：

Git是分布式的版本控制系统，后面我们还要研究多人在同一个版本库里工作，如果大家都用1，2，3……作为版本号，那肯定就冲突了。

每提交一个新版本，实际上Git就会把它们自动串成一条时间线。如果使用可视化工具查看Git历史，就可以更清楚地看到提交历史的时间线。

2、版本回退

若想把当前的版本回退：

回退到上一个版本：git reset --hard HEAD^

回退到上上个版本：git reset --hard HEAD^^

回退到前100个版本：git reset --hard HEAD~100

注：

--hard会回退到上个版本的已提交状态，

--soft会回退到上个版本的未提交状态，

--mixed会回退到上个版本已添加但未提交的状态。

使用示例：(回退到上一个版本，也就是版本二)

cat readme.txt 查看readme.txt的内容。

cat 是“concatenate”的缩写，意为“连接”或“串联”。其原意是用来将文件内容连接并输出到标准输出设备（通常是屏幕），被广泛用于查看文件内容。

（此时查看文件内容发现，确实已经回退到上一个版本了。）

此时，再用 git log 查看历史记录信息，看下现在版本库的状态：

发现第二次修改的那个 “删除内容333333，只剩222” 看不到了。

若现在想回退到最新的版本（版本三），也就是刚刚看不到的那个版本，则可通过版本号进行回退。

git reflog 可获取版本号；

git reset --hard 版本号，用于回退到版本号对应的那个版本。

（版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，否则Git可能会找到多个版本号，就无法确定是哪一个了。）

到此，已经又回到了最新那个版本（版本三）。

————

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针。

当你回退版本的时候，Git仅仅是把HEAD从指向（版本三），改为指向（版本二）。

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。

• 总结：

1. HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
2. 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
3. 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本(利用其版本号)。

3、工作区和暂存区

工作区：就是在电脑上能看到的目录。比如：

1. 目录下gitCxl里的文件(.git隐藏目录版本库除外)。
2. 以后需要再新建的目录文件等等都属于工作区范畴。

版本库(Repository)：工作区有一个隐藏目录.git，这个不属于工作区，而是Git的版本库。

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

我们前面说过使用Git提交文件到版本库有两步：

• 第一步：是使用 git add 把文件添加进去，实际上就是把文件添加到暂存区。
• 第二步：使用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支上。

因为创建Git版本库时，Git自动为我们创建了唯一一个master分支，

所以现在，git commit就是往master分支上提交更改。

可以简单理解为，需要提交的文件修改通通放到暂存区，然后一次性提交暂存区的所有修改。

• demo演示如下：

修改 readme.txt 的内容，新增加 addnew.txt 文件。

1、先用命令 git status来查看下状态：

Git非常清楚地告诉我们：

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

2、使用git add 命令把2个文件都添加到暂存区中，再使用git status来查看下状态：

add之后，此时两个文件皆处于暂存区中。

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），

然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。

3、执行git commit就可以一次性把暂存区的所有修改提交到分支：

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的，如上。

4、管理修改

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

• 举个例子：

1、修改内容后使用 git add 添加到暂存区中；

2、在暂存区中 的前提下，再修改内容；

3、使用 git commit 提交到仓库。

也就是说，过程是【第一次修改 -> git add -> 第二次修改 -> git commit】 。

提交后会发现，第二次的修改并没有被提交。

• 因为：

Git管理的是修改。

当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交。

但是，在工作区的第二次修改并没有放入暂存区。

所以，git commit只负责把暂存区的修改提交了，

也就是第一次的修改被提交了，第二次的修改不会被提交。

————

提交后，

git diff HEAD -- readme.txt 可以查看工作区和版本库里面最新版本的区别，如上。

若提交第二次修改，可以：

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

即可把第二次修改提交。

所以，每次修改，若不用git add到暂存区，则不会加入到commit中。

5、撤销修改

git checkout -- readme.txt 丢弃工作区的修改，把readme.txt文件在工作区做的修改全部撤销，有两种情况：（其实就是检出）（也可以把checkout换成resrore）

1. 若自修改后未放到暂存区，则回退到版本库的状态；
2. 若修改后已经放入暂存区，则回退到添加暂存区后的状态。

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

————

撤销修改还有另外两种方法：

1. 若知道要删掉哪些内容，可直接手动更改去掉那些需要的文件，然后add添加到暂存区，最后commit掉。
2. 可以按以前的方法直接恢复到上一个版本。使用 git reset --hard HEAD^

使用示例：

1、在readme.txt文件里面增加一行内容为5555，通过cat命令查看文件内容，并用git statue查看下当前的状态如下：

2、用git checkout -- readme.txt 丢弃工作区的修改，把readme.txt文件在工作区做的修改全部撤销，并用cat查看文件内容，如下：

会发现工作区的修改 “增加的一行5555” 没了，也就是文件在工作区的修改已被撤销。(情况一)

再测试下情况二：

会发现撤销后，文件内容是回退到了暂存区中的状态，也就是情况二。

注意：命令git checkout -- readme.txt 中的 -- 很重要，若没有 -- 的话，则命令变成创建分支(切换到另一个分支)。

————

git reset HEAD readme.txt 把暂存区的修改撤销掉（unstage），重新放回工作区。

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

• 总结：

1. 场景1：当改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
2. 场景2：当改乱了工作区某个文件的内容，且添加到了暂存区时，想丢弃修改，分两步：
   1. 第一步用命令git reset HEAD <file>，就回到了场景1，
   2. 第二步按场景1操作。
3. 场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节（回退到上一个版本：git reset --hard HEAD^），不过前提是没有推送到远程库。

6、删除文件

假如我现在版本库testgit目录添加一个文件b.txt，然后提交。如下：

直接在文件目录中把文件删了，或者使用如上rm命令：rm b.txt，此时工作区的b.txt文件已被删除。

这个时候，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你哪些文件被删除了，如下：

此时有两个选择：

1. 一是确实要从版本库中删除该文件，那就用命令git rm删掉，并且git commit
2. 另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本

• 情况一：将版本库中的对应也删除。

git rm b.txt 从版本库中删除 b.txt 文件，然后 git commit 提交，如下图：

注：

‘删除’也是一种‘修改’操作，先手动删除文件，然后使用 git add <file> 或者使用 git rm<file> 效果都是一样的。

• 情况二：删错了，需从版本库中将对应文件恢复。

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

👉远程仓库

1、GitHub 中添加 SSH Key

需先注册github账号。

由于你的本地Git仓库和github仓库之间的传输是通过SSH加密的，所以需要一点设置：

• 第1步：创建SSH Key。

在用户主目录下，看看有没有 .ssh 目录。（C盘—>用户—>"用户名"—>.ssh文件夹）

如果有，再看看这个目录下有没有 id_rsa 和 id_rsa.pub 这两个文件，如果已经有了，可直接跳到下一步。

如果没有，打开Shell（Windows下打开Git Bash），创建SSH Key：

ssh-keygen -t rsa -C "youremail@example.com"

把邮件地址换成自己的邮件地址，然后一路回车，使用默认值即可，由于这个Key也不是用于军事目的，所以也无需设置密码。

若一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对。

id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。

• 第2步：登陆GitHub，打开“Account settings”，“SSH Keys”页面：

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴 id_rsa.pub 文件的内容：

点击 Add Key，你就应该可以看到已经添加的key。

为什么GitHub需要SSH Key呢？
因为GitHub需要识别出你推送的提交确实是你推送的，而不是别人冒充的，
而Git支持SSH协议，所以，GitHub只要知道了你的公钥，就可以确认只有你自己才能推送。

当然，GitHub允许你添加多个Key。
假定你有若干电脑，你一会儿在公司提交，一会儿在家里提交，
只要把每台电脑的Key都添加到GitHub，即可在每台电脑上往GitHub推送了。

最后友情提示，
在GitHub上免费托管的Git仓库，任何人都可以看到喔（但只有你自己才能改）。
所以，不要把敏感信息放进去。

如果你不想让别人看到Git库，有两个办法：
一个是交点保护费，让GitHub把公开的仓库变成私有的，这样别人就看不见了（不可读更不可写）。
另一个办法是自己动手，搭一个Git服务器，因为是你自己的Git服务器，所以别人也是看不见的。
自己动手搭Git服务器这个方法我们后面会讲到的，相当简单，公司内部开发必备。

2、添加远程库

如何添加远程库？
现在的情景是：

我们已经在本地创建了一个Git仓库后，又想在github创建一个Git仓库，并且希望这两个仓库进行远程同步，这样github的仓库可以作为备份，又可以其他人通过该仓库来协作。

• 首先，登录github上，然后在右上角找到“create a new repo”创建一个新的仓库。如下：

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

目前，在GitHub上的这个testgit仓库还是空的，GitHub告诉我们：

可以从这个仓库克隆出新的仓库，

也可以把一个已有的本地仓库与之关联，然后把本地仓库的内容 推送到GitHub仓库。

现在，我们根据GitHub的提示，在本地的 gitCxl 仓库下运行命令：

git remote add origin https://github.com/chxin14160/gitCxl.git

千万注意，把上面的 chxin14160 替换成自己的GitHub账户名。

否则，你在本地关联的就是我的远程库，关联没有问题，但是你以后推送是推不上去的，

因为你的SSH Key公钥不在我的账户列表中。

添加后，远程库的名字就是origin，这是Git默认的叫法，也可以改成别的，但是origin这个名字一看就知道是远程库。

• 下一步，就可以把本地库的所有内容推送到远程库上：

把本地库的内容推送到远程，使用 git push 命令，实际上是把当前分支master推送到远程。

git push -u origin master 初次提交，把本地master分支的最新修改推送到github上

由于远程库是空的，我们第一次推送master分支时，加上了 –u参数，Git

不但会把本地的master分支内容推送到远程新的master分支，

还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

推送成功后，可以立刻在github页面中看到远程库的内容已经和本地一模一样了，上面的要输入github的用户名和密码如下所示：

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

git push origin master

把本地master分支的最新修改推送到github上了，现在你就拥有了真正的分布式版本库了。

---

SSH警告

当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

这个警告只会出现一次，后面的操作就不会有任何警告了。

如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。

---

删除远程库

如果添加的时候地址写错了，或者就是想删除远程库，可以用git remote rm <name>命令。使用前，建议先用git remote -v查看远程库信息：

$ git remote -v
origin  git@github.com:michaelliao/learn-git.git (fetch)
origin  git@github.com:michaelliao/learn-git.git (push)

然后，根据名字删除，比如删除origin：

$ git remote rm origin

此处的“删除”其实是解除了本地和远程的绑定关系，并不是物理上删除了远程库。远程库本身并没有任何改动。

要真正删除远程库，需要登录到GitHub，在后台页面找到删除按钮再删除。

---

• 总结：

1. 要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
2. 关联一个远程库时必须给远程库指定一个名字，origin是默认习惯命名；
3. 关联后，使用命令git push -u origin master第一次推送master分支的所有内容；
4. 此后，每次本地提交后，只要有必要，就可以使用命令git push origin master推送最新修改；

分布式版本系统的最大好处之一是在本地工作完全不需要考虑远程库的存在，也就是有没有联网都可以正常工作。

而SVN在没有联网的时候是拒绝干活的！

GitHub当有网络的时候，再把本地提交推送一下即可完成同步。

3、从远程库克隆

如何从远程库克隆？

上面我们了解了先有本地库，后有远程库时候，如何关联远程库：

1. 登录github，创建一个新的仓库 gitCxl；
2. 在本地的 gitCxl 仓库下运行命令 git remote add origin https://github.com/chxin14160/gitCxl.git，关联GitHub仓库；
3. 初次提交，使用 git push -u origin master 把本地库的所有内容推送到远程库上 (实际上是把当前分支master推送到远程)；
4. 后续提交，皆只需使用 git push origin master 把本地master分支的最新修改推送到github上。

现在，远程库有新内容，想将其克隆到本地来，如何克隆呢？

• 首先，登录github，创建一个新的仓库，名字叫 gitCxl2 ，如下：

勾选Initialize this repository with a README，GitHub会自动为我们创建一个README.md文件。创建完毕后，可以看到README.md文件。

• 此时，远程库已经准备好了，下一步是使用命令git clone克隆一个本地库了。如下所示：

git clone https://github.com/chxin14160/gitCxl2 从GitHub的对应地址中克隆一个本地库

如此，本地目录下便会生成生成 gitCxl2 目录了，如下所示：

若有多个人协作开发，则每个人各自从远程克隆一份即可。

GitHub给出的地址不止一个，还可以用https://github.com/michaelliao/gitskills.git这样的地址，或 git clone git@github.com:michaelliao/gitskills.git 。

实际上，Git支持多种协议，默认的git://使用ssh，但也可以使用https等其他协议。

使用https除了速度慢以外，还有个最大的麻烦是每次推送都必须输入口令。

但是在某些只开放http端口的公司内部就无法使用ssh协议，而只能用https。

• 总结：

1. 要克隆一个仓库，需知道仓库的地址，然后使用git clone命令克隆。
2. Git支持多种协议，包括https，但ssh协议速度最快。

👉分支管理

1、创建与合并分支

在版本回退里，已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。

截止到目前只有一条时间线，在Git里，这个分支叫主分支，即master分支。

HEAD严格来说不是指向提交，而是指向master。master才是指向提交的。

所以，HEAD指向的就是当前分支。

下面开始实战。

• 首先，创建dev分支，然后切换到dev分支上。如下操作：

git checkout -b dev 创建并切换分支dev

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

git branch dev 创建分支dev
git checkout dev 切换分支dev

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

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

git branch 查看分支，会列出所有的分支，当前分支前面会添加一个星号 “ * ”。

• 然后，我们在dev分支上继续做demo，并正常提交。

比如，我们现在 在readme.txt再增加一行 7777。

首先我们先来查看下readme.txt内容，接着添加内容77777777，如下：

此时，dev分支上的内容已提交，也就是dev分支的工作已完成。

• 现在我们切换回到主分支master上，继续查看readme.txt内容如下：

git checkout master 切换到分支master

切回master后发现dev分支修改的7777不见了。

因为7777的修改提交在了dev分支上，而此时master分支的提交点并没有变：

• 现在我们可以把dev分支上的工作成果，也就是内容合并到主分支master上了。

可以在master分支上，使用如下命令 git merge dev 如下所示：

、

可以看到，将dev合并进来之后，master的readme中多了一条7777。

git merge 命令用于合并指定分支到当前分支上。

合并后，再查看readme.txt内容，可以看到，和dev分支最新提交的是完全一样的。

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

• 合并完成后，我们可以接着删除dev分支了，操作如下：

git branch –d dev 删除分支dev

删除后，git branch 查看分支，就只剩下master分支了，如上图。

因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。

————

switch

我们注意到切换分支使用git checkout <branch>，

而前面讲过的撤销修改则是git checkout -- <file>。

同一个命令，有两种作用，确实有点令人迷惑。

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

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

$ git switch -c dev

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

$ git switch master

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

• 总结 创建与合并分支 命令如下：

查看分支：git branch
创建分支：git branch name
切换分支：git checkout name 或者 git switch name
创建+切换分支：git checkout –b name 或者 git switch -c <name>
合并某分支到当前分支：git merge name
删除分支：git branch –d name

2、解决冲突

• 先制造冲突测试demo

1. git checkout -b fenzhi1 先创建并切换到分支fenzhi1
2. cat readme.txt 查看增加内容前的readme
3. readme中增加内容8888
4. 继续查看增加内容后的readme
5. 将readme添加到暂存区，并提交到仓库(此时仍在分支fenzhi1上)

​​​​​​​

• 在分支fenzhi1中提交修改内容后，切换回分支master：

在分支master中也在最后一行添加内容，内容为9999，如下所示：

此时，master分支 和 fenzhi1分支 各自都分别有新的提交，变成了这样：

• 现在我们需要在master分支上来合并fenzhi1，如下操作：

（两个分支都分别有各自的提交，这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突。）

​​​​​​​

Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，其中：

<<<<<<<HEAD是指主分支修改的内容，

>>>>>>>fenzhi1 是指fenzhi1上修改的内容，

我们可以修改如下后保存，再提交：

此时，master分支 和 feature1分支 变成了下图所示：

• 若想查看分支合并的情况的话，需要使用命令 git log 命令行演示如下：

或者用带参数的git log也可以看到分支的合并情况：

git log --graph --pretty=oneline --abbrev-commit

git log 命令是 Git 版本控制系统中用于显示项目提交历史记录的命令。通过添加不同的选项，你可以定制输出的格式和包含的信息。下面是对你提到的命令选项的解释：

--graph：这个选项会在输出中显示一个 ASCII 图形，用以表示分支和合并的历史。图形中的每一行代表一个提交，分支点会以竖线（|）和分叉（* 或 /）来表示。这使得你可以直观地看到项目的分支和合并情况。
--pretty=oneline：这个选项将每个提交的记录格式化为单行显示。默认情况下，git log 会显示每个提交的哈希值、作者、日期和提交信息。使用 --pretty=oneline，只会显示提交的哈希值（通常是简短的，如果使用了 --abbrev-commit 选项）和提交信息，而且这两部分会在一行内显示，便于快速浏览。
--abbrev-commit：这个选项会让 Git 使用简短的提交哈希值（通常是前几个字符）而不是完整的 40 个字符的哈希值。这样做可以减少输出的长度，使得输出更加简洁。
综上所述，git log --graph --pretty=oneline --abbrev-commit 命令的作用是：以单行格式简洁地显示项目的提交历史，包括简短的提交哈希值和提交信息，并且使用 ASCII 图形表示分支和合并的历史。这个命令非常适合快速查看项目的提交历史和分支结构。

1

3、分支管理策略

拓展

git的命名窗口关闭之后，继续使用之前创建的仓库

无需重新创建。

在你创建仓库文件夹内鼠标右键有个 Git Bash Here打开就好，

或者按住shift加鼠标右键有个 `在此处打开Powershell窗口`，都可以直接 使用git命令。