最近有不少读者和鲁哥反映可以学习git了。 无论是开源项目网站还是团队协作，都离不开git版本控制的使用。 另外，在学校很多同学都没有太多接触过git，所以路哥决定从最基本的开始，这个基础的内容还请见谅。
由于git涉及的内容太多，写一篇文章就太长了，从阅读体验上来说不太友好，所以分成两篇来写。 本文主要分享git的一些常用操作以及命令背后的原理。
什么是版本控制？
当我们在做一个项目的时候，需要来回更改项目功能和代码。 一般我们修改的内容都会覆盖之前的内容，但是突然有一天，老板要的不是新的需求，而是原来的功能。 我应该怎么办？ 只能把最新的代码稍微删掉，然后重写原来的函数。
如果项目变得庞大，需要多人开发，而每个人开发的功能又不同，那么在合并项目时，就必须手动合并。 万一出现各种Bug，大家就得更改整体项目，删除或添加部分代码，一旦出现合并错误，整个项目就处于未知的状态，此时项目代码就变得极其混乱。
版本控制就是为了解决以上两种情况。 您所做的更改将由版本控制系统记录。 对于上面的第一种情况，我写的新功能的老大不想要。 我可以回滚到之前没有修改过的状态。 对于上面的团队协作，可以直接通过版本控制进行合并，无需手动复制粘贴。
git 的兴起
谈论 Git 的兴起特别有趣。 最早的版本控制来自于公司。 并且应用于最大的开源系统Linux。 Linux的作者Linus长期以来一直将Linux视为全世界的开源项目。 Linux的诞生离不开全球众多开源贡献者的参与。
由于贡献的开发者来自世界各地，因此会出现上述问题。 早期，Linus 只能手动合并代码。 后来系统越来越大，就不得不使用公司的版本控制。 但是公司看到他们这么喜欢开源的话，就让Linux开发者免费使用吧。
面对来自世界各地的Linux开发者，别说这些人都是伟人，而且到处都是风波，所以我不得不计划做点什么。 于是我就开始了公司的版本控制，对公司内部的协议进行了逆向工程（反编译），但不幸的是，被别人知道了。
这很棒。 本来公司是让你免费试用的，但是你非要破解他们的东西，并且让他们知道。 Linux的作者Linus不得不道歉，但Linux的道歉并没有妥协。 最终，公司收回了无偿使用权。
兄弟们，既然人家不让你用，那就自己动手吧，吃饱穿暖。 才华横溢的Linus只用了十天的时间，就用C语言写出了第一个版本的git，我和我的朋友们都惊呆了！
几年后，git 开始流行。 不愧是Linux高手。 git不仅性能得到了很大的提升，而且还是开源、免费的。 很多开发者都爱上了git，现在git也被誉为最流行的分布式版本控制系统。
git之前的版本控制是SVN和CVS，但这两个都有明显的缺点，都是集中式版本控制，什么是集中式？ 需要提供一台服务器，团队工作围绕这台服务器进行融合。 它是基于局域网的。 例如，有些公司仍在使用SVN。 一旦他们在家工作，写好的代码就无法提交到这个服务器上。
但 git 不同。 任何地方、任何地点、不同的局域网下，您可以随时提交，而且提交速度非常快。 过一段时间你就会知道它有多快。
上面暂时介绍了git的历史和特点。 如果感兴趣的童鞋可以去网上查一下更多相关的git内容。
本地版本库
对于git的安装，不要浪费太多时间，直接去官网下载即可。
我们直接从本地版本仓库开始吧。 我们通过以下命令创建本地git版本仓库。
1git init
执行该命令后会发生什么？ 我们可以把它理解为初始化当前项目，创建一个空仓库，我们称之为1号仓库。我们可以对这个仓库进行添加、删除等一系列操作。
此时，当前目录下会生成一个.git文件，这个文件是记录当前版本库中内容变化的。
我们完全可以把这个仓库看成是现实中存放货物的仓库。 当然，仓库必须有一个管理员，这个管理员就是上面的.git同学。
提交货物
然后我在此目录中创建一个名为“.md”的项目文件，然后执行以下命令。
1git add project.md
上面的过程就相当于，此时，陆哥开着拖拉机，拉着一批货物，他想在仓库里存放一批货物。 但管理员说必须要老板同意后才能让我存放，所以这批货暂时存放在2号仓库。
2号仓库也称临时仓库。 只能存放临时物品。 二号临时仓库的内容经老板签字承诺后即可正式存放在大仓库中。 然后add添加到2号临时仓库中。
我们可以让仓库管理员输入以下命令，查看Luge的货物是否已经存放在2号临时仓库中。
1git status
是的，没错，就是陆哥的货。
这时老板同意可以将2号仓库暂存的货物放入1号正式仓库，然后管理员开始输入命令将暂存的货物转入正式仓库。
1git commit -m '2020 3/24 鹿哥的货物 10吨'
表示正式提交，-m是提交内容的信息。 正式开发中，每次提交代码的时候，都要对提交的内容进行说明，是修改了，还是增加了功能，而且这个东西一定要说明，因为如果项目出现问题，就会通过回滚提交的信息。
是的，这些提交记录都是管理员记录的。 我们通过下面的命令来看看管理员的日志本。
1git log
这条记录，包括谁提交了代码，什么时候提交的，提交了哪些信息，都会记录在管理员的小本子里。
随后，陆兄陆续囤积了数吨货物，记录如下：
版本回滚
有时候我们的程序员可能会喝酒提交代码，一不小心就提交了未完成的功能代码。 第二天，酒醒后，我猛然发现自己贱了，怎么办？
不要惊慌，我们可以在醉酒之前撤消（也称为回滚）代码的状态。 我们以货物为例来说明，比如陆哥不想存这20吨，怎么办？ 执行以下命令。
1git reset --hard HEAD^
这个命令的意思是回滚到上次提交代码之前，也就是醉酒之前的状态。 这个时候，鲁哥的20吨就相当于没有存放在仓库里了。 我们正在查看管理员的记录。
1git log
那么问题来了，路哥，如果你遇到一个能喝酒、喝醉、一次性提交好几次代码、还需要回滚好几次的程序员，你这次就太慢了。
没错，如果我们想随时回滚，该怎么办呢？ 我们可以先通过一个命令来查看我们的管理员执行该命令的记录。
1git reflog
每个命令前面都有一个提交的id。 我们使用这个id来执行下面的命令并回滚到我们想要回滚的任何时间。
1git reset --hard 3cc34bb(提交 ID) 取消更改
另外，我们在写代码的时候，经常会出现两种情况。
如果我们提交完成了，老板让我加一个功能。 这时候我写了一天，老大告诉我，在提交（git add）之前我不需要这个功能，那么这时候我们该怎么办呢？ 别怕，我们执行下面的命令，直接放弃对工作空间（当前项目）的修改。
1git checkout -- project.md(文件名)
但我们已经提交到临时存储库了，然后修改了内容，老大告诉我不再需要这个功能了，所以我们用上面的回滚方法放弃缓存区的添加。
1git reset HEAD project.md(文件名)
如果我们不小心删除了我们项目的部分代码，而本地项目与仓库中的项目不一致，我们该怎么办？
要么删除仓库里的物品，要么直接正常提交修改。 要么恢复本地项目误删除的文件，然后使用我们上面提到的命令。
1git checkout -- project.md(文件名)
远程仓库
上面只是你本地玩并提交代码。 以后公司里一个大项目必须由很多人来完成。 那么就必须有一个统一的远程仓库来存放各个开发人员从本地仓库提交的代码进行合并。 当项目开发完成后，我们可以直接使用远程仓库的代码上线。
是的，你一定想到了，你可以创建一个远程仓库，并且这个仓库可以由任何人提交，也可以让某些开发人员可见（私有仓库和公共仓库）。
在以下位置创建远程存储库：
然后我们就可以配置仓库的相关信息了，如下：
我们创建之后，必须将本地仓库和远程仓库关联起来，只有关联之后才能提交本地代码。
本地仓库和远程仓库之间的通信需要通过SSH加密，并且需要设计相同的密钥来通信。
创建密钥：
本地仓库设置密钥需要与远程仓库通信并逆行加密。 下面创建一个 SSH Key，一路按 Enter 键。 在用户的主目录中找到 .ssh 目录。 有两个文件：.pub 和 .pub。 这两个是SSH Key的秘钥对。 它们是私钥，不能泄露。 .pub 是公钥，因此您可以安全地告诉任何人。
1ssh-keygen -t rsa -C "youremail@example.com"
设置键：
在远程仓库中设置一个或多个公钥，以了解本地仓库应该与哪里进行通信。
登录后，打开“ ”、“SSH Keys”页面。 然后，单击“Add SSH Key”，填写任意Title，将.pub文件的内容粘贴到Key文本框中，单击“Add Key”，您应该会看到添加的Key。
我们通过上面设置之后，就可以将本地仓库和远程仓库关联起来了。
1git remote add origin 远程仓库地址
通过这个命令可以关联远程仓库，远程仓库的地址在这里。
我们现在只是连接远程仓库，并没有推送本地分支。 分支的概念涉及到的内容比较多，本节暂时不展开。
1git push -u origin master
通过上面的命令，将本地仓库的分支与远程分支关联起来（可以理解为当前版本代码会有一个指向当前版本的指针）。 这样，如果本地有变化，通过提交到远程仓库，远程仓库的分支内容也会发生变化。
克隆存储库
有时候，你可能没有参与项目的创建，但老板临时派你到其他项目组一起协助项目。
这时候你本地还没有项目，就需要把远程仓库中其他组的项目拉下来，然后进行快速开发。 我们拉取远程仓库项目的过程称为克隆仓库。 使用以下命令执行此操作。
1git clone 远程仓库地址
至此我们就可以愉快的开发了。
概括
本文主要涉及一些基本的git操作，以及如何解决代码冲突和分支的各种概念，以及遇到项目bug时如何暂时保存手头的工作等。
今天的文章就到这里了。 这篇文章的内容虽然接近基础，但是确实很难写。 我考虑过周一发布它。 我看到文章涉及的太少了，然后第二天又补充了很多。 全文共4230字。 大家帮忙，欢迎点赞留言，路哥仅存的动力就靠你们了！
一个从三本书里走出来的程序员，维护着一个既有技术又有温情的原创账号，一直认为能够把复杂的事情解释清楚是一件非常牛逼的事情。
肝爆不容易
我在看，谢谢！
