目录

• • 传统艺能😎
  • 感受吧年轻人！🤔
  • git 是啥🤔
  • 版本控制？🤔
  • git 安装🤔
  • 分布式 vs 集中式🤔
  • 工作机制🤔
  • Git 常用命令🤔
  • • 设置用户签名🎉
    • 初始化本地库🎉
    • 本地库状态查看🎉
    • 添加暂存区🎉
    • 提交本地库🎉
    • 查看日志信息🎉
    • 修改文件🎉
    • 版本穿梭🎉
    • 分支操作🎉
    • 分支的正常合并🎉
    • 分支的冲突合并🎉

传统艺能😎

小编是双非本科大一菜鸟不赘述，欢迎大佬指点江山（QQ：1319365055）
此前博客点我！点我！请搜索博主 【知晓天空之蓝】

🎉🎉非科班转码社区诚邀您入驻🎉🎉
小伙伴们，打码路上一路向北，背后烟火，彼岸之前皆是疾苦
一个人的单打独斗不如一群人的砥砺前行
这是我和梦想合伙人组建的社区，诚邀各位有志之士的加入！！
社区用户好文均加精（“标兵”文章字数2000+加精，“达人”文章字数1500+加精）
直达： 社区链接点我

🎉🎉🎉倾力打造转码社区微信公众号🎉🎉🎉

---

感受吧年轻人！🤔

因为之前一直用的 TortoiseGit，所以没去接触 Git ，咱就是说用了以后还是俩字：真香，Git 确实好用所以欢喜来写个操作教程就当

随处可闻的 git 究竟有多重要？假如你是一个从茫茫人海脱颖而出的实习生苗子，来公司第一天老板丢给你分大文件叫你把里面代码 down 下来先看看，然而这时你连怎么去整合代码都不知道就无比尴尬了， git 其实已经是程序员自我修养的基础了，学会使用 git 未来进企业也会给前辈和同事减少不少麻烦工作，同事也为自己减负和加分。

git 是啥🤔

用一句话概括：git是目前世界上最先进的分布式版本控制系统，没有之一！

它是免费的，开源的分布式版本控制系统，可以高效的处理各种大小项目，他抑易于学习，占地小性能极快，有廉价的本地库。方便的暂存区和多个工作流分支。他的性能优于 Subversion，CVS 等版本控制工具。

版本控制？🤔

版本控制是一种记录文件内容变化一遍以便于查看特定历史版本修订情况的系统，他最大特点就是可以修改历史记录方便版本切换。

比如你负责维护一款 APP 的某个功能，而某一天他突然出现一个重大错误需要 hot fix ，这时又正好是用户使用的高峰期，怎么办呢？救星就是我们的 git ，他会从面对用户上的版本做一个 branch 分支，我们对这个分支进行修改，完事儿直接合并回去就行。这样麻烦也解决了又不产生业务损失。这就是神一般的版本控制系统。

git 安装🤔

官网链接

进入官网再根据自己配置进行下载即可们，但是由于官网下载速度过于缓慢，而且我还下载报错： 无法下载，需要某网站授权。

推荐在git下载的某宝镜像网站下下载，最新版本在网页下面，请各取所需：

镜像网站下载链接

分布式 vs 集中式🤔

为什么是分布式而不是集中式呢？很简单，假如一个项目有多个人来完成，集中式有一个集中管理的服务器，保存所有文件的修订版本，每个成员能看到各自的进度，管理员也轻松掌握每个成员的权限，而且管理一个集中化的系统远比在各个客户端上进行维护要轻松许多。

但是吧如果机器宕掉了或者坏掉了，无法提交更新也无法协同工作，那么就面临着全体干瞪眼儿的尴尬，所以这种架构有一个致命缺点就是他的中央服务器的单点故障。

所以这时以 git 为代表的版本控制工具就来了，他并不是文件快照，而是把代码仓库完整的镜像拷贝下来，每一次文件客户端的文件提取操作都是一次对整个文件仓库的完整备份。他不仅实现了不受断网环境影响的开发，还更加安全。

工作机制🤔

憋看咱 git 功能强大，其实底层工作机制很简单。

git 大概分为三个部分，工作区，暂存区和本地库。工作区指的是代码存放的磁盘目录的位置；暂存区是写完代码后，git 去追踪这个代码，其实就是让 git 知道咱有这么个代码，所以需要将工作区代码添加到暂存区；最后提交到本地库就会生成对应的历史版本，一旦生成他就是你抹不去的印记了（远程库）！

远程库就是所谓的代码托管中心，耳熟能详的 Github ， Gitee，这些是互联网托管中心，还有局域网托管中心比如 GitLab。

Git 常用命令🤔

因为 git 开发者是林纳斯，也就是 Linux 之父，所以命令也是承袭了 Linux 的指令，Linux我们都很容易上手，但是没接敢说自己精通 Linux 指令的，git 也是同理所以我只列出重点常用的。

命令哪里输入？你只需要戍边右键点开找到 git bash ，打开是像这样一个框框（初始是没有代码的，这时我截的我当前的）

设置用户签名🎉

git config --global user.name 用户名
git config --global user.email 邮箱

从咱安装好那一刻开始，只需要设置这一次用户签名就够了，如果没设置将来提交代码时是会报错的，签名的作用是区分不同操作者的身份，用户的签名信息在每一次提交信息中都可以看到。

初始化本地库🎉

git init

我们要让 git 来管理一个目录时，那就必须要让 git 获得该目录的管理权。我以我自己的本地库为例，我在 D 盘创建了一个名为 yunying 的文件夹，我想让当前文件夹成为我的本地库，那我就直接进入该文件夹，右键唤出 git bash ，输入 git init 就会创建出一个 master 分支(默认分支名为 master)，分支当前无操作所以 ll 指令查看分支内容为 0。

本地库状态查看🎉

git status

status 即状态，这个命令可查看当前库的状态

一但有个风吹草动比如创建了一个 hello.txt ，再使用 vim 编辑一下就会变成 “红码”， 就是因为我们做出来编辑动作，而对于他 git 还从来没追踪过，说明这个文件还在工作区。

添加暂存区🎉

要将文件从工作区添加到暂存区就要用 add 命令：

git add 文件名

添加完了他会显示两行警告：

这个警告的出现其实就是添加成功了，它是提醒你一下 git 帮你默认转换了一下行末换行符，就是把 Windows 环境下的 CRLF 替换为 Linux 中的 LF。并没有什么实际作用（和某局警告一样）

那么添加完了我们 git status 查看状态他的日志信息就会改变，红码变绿码：

这里面也告诉我们如何删除这个文件也就是这行：

git rm --cached 文件名

这个所谓的删除实质上是把暂存区的删掉而工作区的不会被连坐。

提交本地库🎉

这一步就是将暂存区文件提交到本地库，形成一个历史版本：

git commit -m "日志信息" 文件名

这个 -m 的作用是去写跟在他后面的一个日志信息，如果没有 -m 操作，在提交时 git 也会弹出一个提示框叫你添加，不然没法提交。提交成功后就是这样一个样子：

日志信 first commit 前面跟了一串数字：965c6a1，这就是提交的版本号，看到他就证明咱提交成功了。

查看日志信息🎉

那完事儿了我们咋查看历史版本信息呢？我们可以用 reflog （reference logs，即参考日志）
和 log

git reflog
git log

他俩都可以查看历史版本信息，但是 log 是查看详细版本日志信息，包括用户签名，提交时间以及完整的版本号：

修改文件🎉

如果我要对当前在暂存区中的文件进行修改，假如我 vim hello.txt ，在里面增加了几行代码，回来查看当前本地库状态就会变成这样：

这行红字 modified 就证明我们已经对 hello.txt 进行了修改操作，而且这次修改导致了文件不能被追踪到，掉出了暂存区，只需要再来一次 add 和 commit 即可，但是提交后的就是第二次版本信息了。

版本穿梭🎉

git reset --hard 版本号

既然我们有了历史版本，那么总有一天会像回到曾经那个版本，去对比去品鉴去驻足，就好像咱男人想回到曾经的某个过去

我们想跑到哪扇门就得先知道门牌号，直接 reflog 查看一手之前的各个版本号：

比如 e88c8a5 就对应一个头指针指向 master 分支，如果想跳到 second commit 这个二号版本，直接复制前面的版本号 e88c8a5 ，用 reset 命令就行，执行完后再次查看日志就会发现头指针已经指向了 master 分支：

原理：

假如有一个 version 版本，有一个 master 分支，那这个 master 分支一定指向 version 这个版本，git 会有一个 head 头指针指向这个分支，整体上 head 指向 master 这个躯干是不会动的，只需调整 master 的走向即可。

分支操作🎉

当下一个生产链上的分支结构大概就长这样：

版本控制中同时推进多个任务，每个任务我们可以创建其单独的分支，这就意味着我们可以将自己的工作从偌大的主线上抠出来，开发同时不影响主线分支运行。

git 中关于分支的操作并不是很多，所以不需要我们去劳神费力的记：

分支的正常合并🎉

如果我现在有两条分支 master 和 new ，如果我想把 new 分支合并到 master 分支上，就要 checkout 切换分支到 master 上，让 master 站在当前分支的角度进行合并，对 new 分支不会有影响：

git mrege new

这就是合并成功的样子，合并分支的底层原理依然是指针，和切换分支同理。

分支的冲突合并🎉

为什么会有冲突合并呢？因为合并分支时，两个分支在同一个文件的同一个位置有两套完全不同的修改， git 只是一个合并的工具他没办法替我们决定使用哪一个，所以必须进行人为指定。

比如我原始版本里面内容是 123，master 分支下我修改为 123 -4，hot-fix 分支下我修改为 123 +5。我切换到 master 分支，执行 merge hot-fix，这时的日志就会大不一样了：

这里报了一个自动合并失败的冲突，这就说明他并没有合并成功，需要我们手动搞定他，我们 vim 打开文件，这时 git 已经把不同点给我们写出来，我们只需要留下我们需要的，删除多余的包括系统用来标注不同点的符号（< ， = 和 >）,然后保存退出即可。

此时本地库状态依然是红色的，而且是 both modified，此时像原来一样进行 commit 是不行的，合并对象他依然无法决定，所以我们要强调一下merge 后提交不能带文件名，直接执行下列指令即可 ：

git commit -m “日志信息” 

报错信息：

今天就到这里吧，润了家人们。