【一起来学 Git】LearnGitBranching-基础篇【Learn Git Together】
前言
这是一个陆爻齐跟着
Learn Git Branching网站学习(复习) Git 的系列记录，会跟着其内容的步伐做学习记录，并结合自身浅薄的知识积累和几乎为零的实践经验做一点点的补充。私以为，该网站比较适合有一点 Git 基础来学习，如果是完全零基础，还是看看 Git 官网教程，在 GitHub 这样的代码托管网站走一遍流程比较好。
注意，由于下面的笔记不可避免地涉及到过关的答案，所以强烈建议，自行体验过网站内容再看本文。
正文-基础篇
循序渐进地介绍 Git 主要命令
- 太主要了，私以为省略了不少，这就是为什么说先看 Git 的官网教程比较好。嘛，下面也会把省略的部分简单带带的：）
Git Commit
commit，翻译过来就是“提交”，相当于为当前的 Git 仓库下的文件做了一个存档，而且每次 commit 并非对所有文件的拷贝，而是会保存该版本与上个版本的差异作为提交记录。
命令直接就是
git commit，实际上一般 commit 时会附上提交的注解信息，所以个人经常会写git commit -m "你想加的信息"。毕竟后期查起来，如果有一个 commit 的信息写着 “更新A功能”，而该功能正是排查对象，这不就方便多了嘛。不过实际应用时，会先用 add 命令来将文件加入到等待 commit 的列表中，再 commit，这样一来就可以选择性的更改，灵活美丽的设计。
查看仓库文件的状态用 status 命令，所谓的状态，主要有没有追踪（也就是没 add 过），待提交（刚 add），更改（commit 过，有变更），删除（这个一般看不到，毕竟都删了）等。有时候仓库结构比较复杂，该命令能够辅助快速查询需要处理的文件有哪些。
在网站中，一次 commit 视为一个版本，算是简化了些，也挺好，更能专注于 git 的特性。
Git Branch
核心！毕竟网站名都叫这个：）
branch，翻译过来是“分支”，该命令和名字一样，会从当前的分支分裂出一条新分支来，说是分裂，其实就多了个分支指针。
涉及到的命令多了一点，一点点来罢。
首先是
git branch dev，这个命令会创建一个名为dev的分支，不过还没切换过去。切换的命令为
git checkout dev或者git switch dev，后者是新命令，准备用来代替checkout在分支切换上的功能。不过，如果想新建分支后立即切换过去，可以用
git checkout -b dev实现，看着方便，其实用得不算多，不过建议还是记一记。网站中只要新建分支，然后在新分支 commit 一下就过了，没啥好讲的。
哦对，一般来说代码托管仓库（Github，Gitee等）默认分支叫
master或者main，这些分支会拿去当作主分支，开发的时候可以新建个dev分支，然后有什么开发任务就在dev先试验完成，差不多了就合并到主分支，这样子版本管理就方便点。
Git Merge
也是核心，或者说，灵魂！（
塔玛希）该命令就是把另外一条分支合并到本分支来（具体怎么合并，合并冲突如何解决建议看官方文档）
如果你对于命令中的分支名字是被合并还是合并的，那么就记住：merge 操作中，当前所处在的分支（当前分支）就是目标分支，要合并到哪个分支，就先切换过去。换句话，就是“merge 过来”。
如果当前处于
main分支，输入命令git merge dev，那么就会把dev分支的最新 commit 的部分合并到当前main来，该合并会产生一个新的 commit，commit 的内容就是合并。这个时候，再把分支切换到
dev，然后输入git merge main，就会把main的内容合并到dev。但是，因为现在的main已经合并了dev，所以实际上的处理会把dev的指针直接指到现在main最新的 commit。上面两段话如何看着绕，说明没看网站演示，建议实践看看。
以及，其实可以不切换分支就直接实现合并，比如现在处于
dev，想把dev合并到main上，可以输入命令git merge main dev中来实现。这一点也是刚刚查资料才看到的，涨知识力，下次实践下看看。
Git Rebase
也是一种合并分支的方法，相对 merge 而言，没那么瞩目（甚至在这之前，陆爻齐也没用过）
翻译过来其实可以叫“变基”，结合这个名字，命令的作用也会更好理解一点。
网站上简单说明了 rebase 的结果和作用，通过 rebase，会把一个分支的新 commit 复制到另一个分支中，从而避免 merge 那样分支交叉的样子，呈现出来线性的提交历史。
不过其实采用双参数的形式可能会更清晰，比如
git rebase main bugFix就会以main为基础，编辑两个分支分界点后的bugFix的新提交节点，编辑后直接放在main最新的提交后。注意，操作目标分支在这里，是“rebase 过去”的形式。比如，当前分支为
dev，现在已经在dev分支产生了几个 commit，而main主分支因为其他人的开发也产生了一个新的 commit。对于dev分支来说，除了使用git merge main来把main分支的新 commit 合并过来之外，可以先把当前分支切换到main上，再输入命令git rebase dev，用自然语言表示就是，把dev分支变基为main，这样一来，main的新 commit 就会复制到dev的最新 commit 上，避免了一次 merge 产生的分支交叉。实际运用中，十分忌讳对公共分支变基。继续沿用上面的例子，如果不用 merge 来把
dev合并到main上，而是 rebase，那将产生可怕的恶魔。设想一下，还有很多其它开发者基于main来在其他分支开发功能，而 rebase 突然往main上加了几十条 commit 记录，对于主分支的版本管理无异于从大师卡包里随机选取六十张卡片组成一个卡组那样混乱，而且其它开发者如果想排除主分支对自己分支开发影响，也会很麻烦。简单小结一下，rebase 可以避免分支交叉使得提交历史线性化一些，总得来说是用于避免一些不必要的 merge，但使用时需要避免对于公共节点的变基。
