学会git，看这篇就够了

文章目录

• 集中式和分布式

• 1、git 初始化设置和入门

• 2、基本概念

• 3、如何把工作区的文件提交到暂存区

• 4、如何将暂存区的所有内容提交到当前分支

• 5、如何查看工作区和仓库之间的差异

• 6、如何撤销修改

• • 6.1 修改还没放入暂存区，如何撤销
  • 6.2 修改已加入暂存区，如何撤销
  • 6.3 修改已提交，如何撤销

• 7、删除文件

• • 7.1 确实要删
  • 7.2 误删

• 8、分支管理

• • 8.1 创建和使用分支

  • • 8.1.1 创建并使用分支
    • 8.1.2 合并分支到当前分支
    • 8.1.3 删除分支

  • 8.2 解决多分支分别有了新提交后由于分支合并导致的冲突

  • • 8.2.1 解决分支合并冲突

  • 8.3 Bug 分支

  • 8.4 多人协作

  • • 8.4.1 多人协作分支管理策略
    • 8.4.2 多人协作场景模拟
    • 8.4.3 多人协作冲突

• 9、标签

• • 9.1 创建和使用标签
  • 9.2 删除标签

内容参考自 廖雪峰

集中式和分布式

集中式版本控制系统：将版本库存放置于中央服务器，在处理工作时，系统会从中央服务器获取最新的版本并发送至本地电脑，在处理完毕后会立即推送回中央服务器。

*缺点：中央服务器出现问题导致整个团队的工作效率完全受限。这种系统架构依赖网络进行操作，在实际应用中存在一定的局限性。具体来说，在局域网环境下运行时能够充分释放系统的性能优势——即网络带宽充足且传输速度较快；然而在广域网或互联网环境下使用时则会面临性能瓶颈——即如果互联网连接速度较慢，则会导致提交操作延迟显著增加。

分布式版本控制平台是一个无需中央服务器支持的系统，在每个用户的本地电脑上运行一个完整的版本库

1、git 初始化设置和入门

在 linux 或 windows 下安装好 git 后，便可进行初始化操作。

1、设置用户名和邮箱

如果在 windows 下，那么打开 git bash

    git config --global user.name '你在GitHub注册的用户名'
    git config --global user.email '你在GitHub注册的邮箱'

2、生成 ssh 公钥

    ssh-keygen -t rsa -C '你在GitHub注册的邮箱'

3、github 配置 ssh 公钥

用户主目录下，到 .ssh 所在目录，找到 id_rsa.pub 文件

• 用 cat 命令查看并复制里面的内容

访问 github 平台上的设置界面后，在底部单击新生成的 SSH密钥选项卡（ title 可自由设定），接着将复制生成的公钥粘贴至密钥字段中

假设你拥有若干台电脑，在这些设备上统一将所有这些关键名加入GitHub之后，则每个设备都可以安全地同步文件至该平台；借助这些关键名的存在，则其他人无法轻易获取你的账号权限；而位于这些关键名对应设备上的人们，则可通过这些设备实现对你账号的安全访问

4、建仓远程仓库

5、提交的基本流程

    git init
    git add readme.txt
    git commit -m 'git test'
    git remote add origin https://github.com/GogoingDzh/Git_test.git
    git push -u origin master

2、基本概念

1、工作区

也就是在电脑上能看到的目录

2、版本库 .git

在版本库中包含了暂存区stage、master分叉以及一个指向当前主分支的HEAD指针，在使用git init命令创建版本库时，默认情况下会生成唯一的master分叉

3、如何把工作区的文件提交到暂存区

在创建版本库之后进行操作的话，在修改该 readme 文件后使用 git status 查看会显示出来一个标志位被标记为已更改的字样。

当前阶段，请您执行 git add <文件名> 命令以完成将修改过的文件加入暂存区，并观察标志变为绿色以确认该文件已成功提交至暂存区。

4、如何将暂存区的所有内容提交到当前分支

在将需要提交的文件通过 git add 操作将它们放到暂存区之后，在提交前使用 git commit -m <message> 一次性提交所有修改内容，并将暂存区的所有内容包含在内地提交到当前分支。

在提交以后，如果没有再对工作区做修改，那么工作区是干净的。

在提交之前，请确保你的修改内容已经被正确地添加到暂存区中；如果这次提交无法完成，则此次提交将无法成功

5、如何查看工作区和仓库之间的差异

比如 2020年6月19号 20点 我提交了一次修改

今天的早晨第20天,我做了些修改;但现在已经不知道19日做了哪些修改了;那么通过git diff <文件名>就能比较明显的区别.

• 新增的代码将在前面显示 +，而去掉的代码将显示 -

6、如何撤销修改

比如，我们在 readme 中加入了一行

如果未晚察觉到问题，并未晚手动删除新增的内容，在git status中没有显示修改

6.1 修改还没放入暂存区，如何撤销

通过 git checkout -- <文件名> 这一操作能够撤销这一次工作区的修改，并使这个文件回到修改前的状态

6.2 修改已加入暂存区，如何撤销

如果你已经将某个修改加入暂存区，请问正确的做法应该是使用 git reset HEAD <file> 来撤销该暂存区的修改。请注意，在此操作后，该文件的 'modified' 标记变为红色（或显示为红色），这表明该文件尚未被提交到暂存区。

又回到了最初的阶段，在工作区中执行git checkout -- <文件名>命令以删除尚未被暂存到暂存区的修改。

6.3 修改已提交，如何撤销

假如你已经提交了一个版本，则可以通过git log命令查看从最新到最早的各个版本的历史提交记录，并注意到我们在过去三天内依次发布了A版、B版和C版这三次新更新。

如果觉得输出了太多信息，可以加上 --pretty=online 参数，可以看到：

• HEAD 指针指向最新的修改
• 前面的一堆数字是使用 SHA1 计算的版本号

现在，我们想撤销 C，回到 B ，那么使用

• git reset --hard HEAD^
• 回退两个版本，用两个^；回退n个版本，用 HEAD~n

现在，就退回到 B 版本了，而再使用 git log 发现此时已经没有了 C 版本

如果你想再回到 C版本，那怎么办呢？

• 使用 git reflog 查看记录，找到 C版本提交时的版本号 d8c878f

• 使用 git reset --hard 版本号，可以看到，又回到了 C版本

说白了，就是 HEAD 指针在几个版本之间来回游走的问题。

7、删除文件

我们通常会使用rm命令来删除某个文件。这将导致工作区与版本库之间出现不一致，在git状态窗口中显示'deleted'字样。

7.1 确实要删

使用 git rm <文件名> 删除这个文件，并且要 commit 提交来更新版本库

7.2 误删

使用 git checkout -- <文件名> 将其恢复

假设您的文件已存放在版本库中，则无需担心文件被意外删除。可以通过以下命令恢复该操作。

8、分支管理

当多个参与者共同开发时，在协作环境中分支扮演着关键角色。假设你负责完成一个模块，在提交后其他人将无法顺利推进工作。

现在你创建了专属于自己的独立分支这一项工作内容不被他人看见你在自己管理维护的分支上完成工作内容完成后提交到该分支结束的位置最终将该分支归并到原有的项目主干线上即可完成整个操作流程

最初的时候每次提交git都会形成一条时间轴称这条轴为分支HEAD指针指示当前分支而master指向前者最后一次提交

8.1 创建和使用分支

8.1.1 创建并使用分支

目前情况下，请采用 git checkout -b <分支名> 或 git switch -c <分支名> 这两种命令来创建并切换至 dev 分支（这会导致 git 生成一个指向该分支的 dev 指针），这样操作后会看到图中的变化。

当然，也可以分步执行

• 生成与"dev"相关的分支（使用命令"git branch dev"）。
  • 切换至"dev"分支（使用命令"git checkout dev"）。
  • 切换到开发分支（使用命令"git switch dev"）。
  • 列出所有分支信息（使用命令"git branch"），其中星号指示当前位置。

当下，在我们的开发过程中所进行的修改与提交都是基于dev分支完成的。每一次提交后, dev分支会顺着时间线向前推进;与此同时,在此过程中master分支始终保持不变状态。

8.1.2 合并分支到当前分支

那么，在实现了一个功能模块后；建议您先将代码提交至版本控制系统；随后切换至 master 分支；此时会发现修改内容并未被显示于本地文件中；为了实现代码的统一管理；下一步操作应当是使用

• git merge dev

8.1.3 删除分支

在此时审阅文件的内容时，则会发现它与 dev 分支的最新提交完全一致；因此，在此情况下建议你删除 dev 分支

• git branch -d dev

如果分支还没有被合并，要强行删除的话，需要使用 -D 参数

• git branch -D dev

8.2 解决多分支分别有了新提交后由于分支合并导致的冲突

8.2.1 解决分支合并冲突

当最初创建分支时，在方向上一致的新分支都指向最新的提交记录。

现在，新分支和 master 分支都有了新的提交，就变成了这个样子

下面模拟出这种场景：

创建并切换 feature1 分支上，修改文件并提交

• 使用git命令切换到名为feature1的分支
  • 在文件中加入与feature1相关的描述
  • 对readme.txt文件进行添加操作
  • 提交带有与feature1相关的注释的信息

切换到 master 分支，修改文件并提交

• git switch master
• 当前文件状态变为master分支的版本
• 未进行add by feature1操作
• 同时，在master分支下新增了两个条目：分别是1.add by master和2.add by master
• 将修改后的内容保存到暂存区，并提交给远程仓库

目前情况下，我们已生成了上图所示的场景。目前我们计划合并分支，并且这可能造成一定的冲突情况。

目前的文件结构已经发生了变化。可以看到，在Git的作用下, 该系统会力图将两个分支的提交内容进行整合, 并用特定的标记符如<<<<<<<, =======\$, 和>>>>>>>$来区分不同版本的内容.

目前需要手动处理冲突的情况。如果希望合并相关内容，则应删除<<<<<<<、=======以及>>>>>>>这些标记；如果不想合并，则应在本文件中进行相应的修改并最终完成提交操作即可

最终文件是这样，因为我们保留了两个分支所做的提交。

整个过程如图所示

当不采用默认的 Fast forward 模式时，在 merge 过程中将导致的结果即为当前状态，在 merge 操作中不会生成新的提交记录

• git merge --no-ff -m "merge with no-ff" feature1

查看分支合并情况的指令是：

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

8.3 Bug 分支

采用分支管理策略，并将其应用于日常开发工作。当遇到编号为 101 的 bug 疑似修复任务时，请创建一个 issue-101 分支以进行修复工作。修复完成后，请将该临时分支归并回去，并删除此用于处理 bug 的临时分支即可。

但是遇到了问题，在你的 dev 分支上尚未完成开发进度的一半，在线提交预计需1天时间；与此同时你需要尽快解决 bug 预计耗时2小时）。那么此时该怎么办？

过于繁琐，贴上链接

8.4 多人协作

在远程仓库进行克隆操作时，在本地操作 master 分支之前，请确保该分支能够与远程仓库中的 master 分支建立关联关系；因此，在本地操作 master 分支时需要与远程进行同步以保持一致性

远程仓库的默认名称是 origin。

• git remote -v 可以查看有权限的抓取和推送的 origin 地址

8.4.1 多人协作分支管理策略

在团队协作中，通常建议避免在主分支（master）上直接执行任务。相反地，请每位成员独立完成各自的工作分支，并定期将修改或增量提交至开发分支（dev）中。等到软件版本即将发布时，在完成后将开发版本提交至主版本库（master）即可完成整个开发流程。

8.4.2 多人协作场景模拟

在多人协作的情况下，在远程仓库中目前有两个分支：master 和 dev 分支。

构建 michael 和 bob 合作开发的场景。使用 git clone 在本机两个不同目录下进行复制。

现在在本地，我们是看不到 dev 分支的，只能看到本地的 master 分支

现在，bob 要在 dev 分支上开发，所以要创建远程 origin 的 dev 分支到本地

• git checkout -b dev origin/dev

现在，Bob 就可以在 dev 分支上修改，并且把 dev 分支 push 到远程。

git push origin <分支名> 用于将该分支上所有的本地提交文件传输至远程存储库。

观察到，在远程仓库的 dev 分支中新增了贡献者 bob 的修改。值得注意的是，在后续版本发布时将与主分支进行合并，在主分支仍保持原有状态的情况下不再引入新的更改。

8.4.3 多人协作冲突

假如 Micheal 于 origin/dev 分支下对同一份文件于相同位置进行过改动，并有意将其提交至远程仓库的 dev 分支时，则会引发冲突现象；因为 Micheal 并未意识到位于此处的改动是由 bob 所执行的。“远程这一版本的 dev 支持比你的本地版本更为先进。

必须注意的是，在Michael本地工作区中也包含着一个dev分支，并且同时与远程端的dev分支相关联

此时可以执行 git pull 命令来获取最新提交内容，并尝试将其合并到本地 dev 分支上。如果未预先指定本地 dev 分支及其对应的远程 origin/dev 分支链接，则会引发错误提示：no tracking information

• git branch --set-upstream-to=origin/dev dev

拖动至同一位置后进行操作时如果会导致冲突则需要通过之前的步骤进行手动处理无需处理即可最后提交

因此：参与人员在同一代码分支上进行协作开发时,通常会遇到冲突问题.若要实现后续提交（push）成功,则需先执行pull操作,在本地完成代码整合;如果遇到冲突,则需手动解决后再进行push操作以确保成功.

9、标签

比如某个版本准备发布, 你当然不能为这个版本分配一个冗长且不优雅的commit ID, 而替代方案就是使用v1.0标签, 这与传统的commit ID类似, 并被关联起来。

9.1 创建和使用标签

首先切换到想要打标签的分支上，使用下面命令即可

• 使用 git 命令为特定提交添加版本号 v1.0（可选参数用于指定提交的 commit）
  • 使用 git 命令在特定提交上添加指定的版本号并附带说明（可选参数用于指定提交的 commit）
  • 使用 git 命令列出当前所有的版本号（可选参数用于指定要查看的版本号）
  • 使用 git 命令显示关于该版本的信息（可选参数用于指定要查看的版本号）
  • 如果某个提交同时属于两个不同的分支，则该提交在两个分支中都能被标记

9.2 删除标签

生成的标签均保留在本地，并不会发送至远程服务器。删除本地标签的操作可执行于命令行界面：使用 git tag -d 标签名 命令删除本地存储的标签。

如果需要将文件远程推送，请使用 git push origin tag_name 执行操作；而如果希望批量推送所有修改，则可以执行 git push origin --tags 命令。

推送后，再想删除，就需要先从本地删除，在从远程删除

• git tag -d 标签名
• git push origin :refs/tags/标签名