目录
一、Git是做什么的?
Git(读音为/gɪt/)是一个开源的分布式版本控制系统,可以有效、高速地处理从很小到非常大的项目版本管理。 也是Linus Torvalds为了帮助管理Linux内核开发而开发的一个开放源码的版本控制软件。
当然了,对于我们来说就是管理代码的工具,很适合多人协作开发。
stage(或者叫index)的暂存区。
二、Git常用命令:
循序渐进的介绍Git主要命令:
基础篇
1.Git Add
把本地代码添加到暂存区,常用命令【git add .】添加所有改动文件到暂存区。
2.Git Commit
git仓库中的提交记录保存的是你的目录下所有文件的快照,就像是把整个目录复制,然后再粘贴一样,但比复制粘贴优雅许多!
git希望提交的记录尽可能的轻量级,因为在你每次进行提交时,它并不会盲目的肤质整个目录。条件允许的情况下,它会将当前版本与仓库中的上一个版本进行比对,并把所有的差异打包到一起作为一个提交记录。
git还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有父节点的原因。对于项目组的成员来说,维护提交历史对大家都有好处。
我们可以简单的把提交记录看作是项目的快照,提交记录非常轻量,可以快速的在这些提交记录之间切换。
git commit -m “说明文字” #创建一个新的提交记录
3.Git Branch
git的分支非常轻量,他们只是简单的指向某个提交记录--仅此而已。所以许多git爱好者传颂:早建分支!多用分支!
这是因为即使创建再多的分支也不会造成存储或内存上的开销,并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。
在将分支和记录结合起来后,我们会看到两者如何协作。
现在只要记住使用分支其实就相当于在说:“我想基于这个提交以及它所有的父提交进行新的工作”。
git branch <name> # 创建新分支
git checkout <name> # 切换分支
git checkout -b <name> # 创建并切换新的分支
git switch <name> #git 2.33版本中引入的新命令,最终会替代git checkout <name>
4.Git Merge
如何将两个分支合并到一起呢?就是说我们新建一个分支,在其上开发某个新功能,开发完后再合并到主线上。
咱们先来看一下第一种方法 -- git merge。
在git中合并两个分支时会产生一个特殊的提交记录,它有两个父节点。翻译成自然语言就是“我要把这两个父节点本身及他们所有的祖先都包含进来。”
我们准备了两个分支C2、C3,每个分支上各有一个独有的提交。这 意味着没有一个分支包含了我们修改的所有内容。咱们通过合并这两个分支来解决这个问题。我们需要把bugFix合并到main里,该怎么做呢?(*代表当前所在的分支)
git merge bugFix # 把bugFix合并到main
现在main指向了一个拥有两个父节点的提交记录。假如从main开始沿着箭头向上看,在到达起点的路上会经过所有的提交记录。这意味着main包含了对所有代码库的修改。但是bugFix分支还没有包含所有的修改,该怎么办呢?
git checkout bugFix # 切换到bugFix分支
git merge main # 把main合并到bugFix
因为main继承自bugFix,git什么都不用做,只是简单的把bugFix移动到main所指向的那个提交记录即可,这样每一个分支都包含了代码库的所有修改。
5.Git Rebase
第二种合并分支的方法是git rebase。
rebase实际上就是取出一系列的提交记录,“复制”他们,然后在另一个地方逐个的放下去。
rebase的优势就是可以创造更线性的提交历史,这听上去有些难以理解。如果只允许使用rabase的话,代码库的提交历史将会变得异常清晰。
上图中有两个分支C2、C3,当前所在分支为bugFix。我们想要把bugFix分支里的工作直接移到main分支上。移动后会使的两个分支的功能看起来像是按顺序开发,但实际上他们是并行开发的。
git rebase main
怎么样?!现在 bugFix 分支上的工作在 main 的最顶端,同时我们也得到了一个更线性的提交序列。
注意,提交记录 C3 依然存在(树上那个半透明的节点),而 C3' 是我们 Rebase 到 main 分支上的 C3 的副本。
现在唯一的问题就是 main 还没有更新,下面咱们就来更新它吧……
现在我们切换到了 main
上。把它 rebase 到 bugFix
分支上……
git rabase bugFix
好了!由于 bugFix
继承自 main
,所以 Git 只是简单的把 main
分支的引用向前移动了一下而已。
在线练习地址:Learn Git Branching