故事辅助——快速入门Git实操

Git入门实操——常用命令合集

---

前言

初试结束，准备找份实习，近期会更些工作需要的实用工具or技能or框架，修行不易，感恩相伴~

---

一、Git是什么？

不上概念，通俗解释为分布式版本管理软件，就是在日常项目开发时，用来系统的管理一个项目产生的多个版本的一个工具。而分布式是相对于过去具有相似功能的软件而产生的分类（过去还有本地式、集中式），其主要差别在于项目版本所处的位置不同。

• 本地式：将项目各个版本存放在本地（多人共同开发不方便）；
• 集中式：将项目各个版本存放在服务器端（一端挂了，全挂）；
• 分布式：将项目各个版本存放在用户端与服务器端（目前最优解）。

Git官网传送门：自行下载合适版本

---

二、Git基本操作

2.1 基本操作

下方详细介绍的是初次使用Git对项目文件进行管理的一个大致流程的常用命令，1.2有情景代入，道友自行查阅~

• 进入需要管理的项目目录；
• 右击鼠标（安装好后会有Git Bash Here和Git GUI Here），可依据习惯选择是在命令行（Bash）或者图形化界面（GUI）下管理自己的项目（下述为Bash下的操作）；
• 通过初始化等一系列下述操作可实现对项目的管理。

• git init：初始化，此时项目中会生成一个隐藏的.git文件；
• git status：查看当前目录下项目文件状态，此时命令行会输出当前目录下标红的文件名；
• git add filenameorgit add .：向Git中添加需要用Git管理的项目文件，此时调用 git status命令可发现成功添加的文件颜色变绿；
• git config --global user.email "[email protected]":初次使用需要为Git指定邮箱；
• git config --global user.name "Your Name"：初次使用需要为Git指定用户名；
• git commit -m 'versionname'：将当前加入Git下的文件生成一个名为versionname的版本，此时调用 git status命令可发现绿色文件消失（此时已经成功管理）；
• git log：输出当前项目的版本记录，每个记录为该版本生成了对应的版本号（versionnumber），用于回滚；

• 此时已经成功将项目文件在本地进行管理，当文件进行修改时，调用git status命令会发现修改后的文件会有提示，如需将修改后的文件重新管理，则可重复上述步骤生成新的版本，如此便在本地保存了该项目的两个版本。

• git reset --hard 想要回到的versionnumber：将当前项目回滚到之前(or之后)的某一版本，版本号可通过git log命令查看；
• git reflog：查看全部针对版本的操作记录（包括执行回滚前后的操作），便于查看回滚前后的版本号。

• 上方对项目文件的状态描述有些不太规范，详细见下图：
• 上图展示了项目文件所处的三种状态：工作区、暂存区和版本库；其中工作区又可细分成两个分区：已被控制文件和新增/修改分区，其中颜色相同的分区可理解为串在一起；各分区内的文件可通过图示命令实现文件状态的切换；

2.2 情景代入

上述命令可能过于单调，为各位道友提供一个实际应用情景便于理解。

• 某公司老板要求员工A独自开发网站，要求有三个功能商城、支付和短视频；员工A使用Git进行项目维护，分别将三个功能作为三个模块各自开发，并且每个模块作为一个版本在Git上进行维护，三个版本分别名为V1、V2和V3。全部开发好后，老板临时起意，决定砍掉短视频功能，此时如果没有Git维护，则需要手动删除短视频的全部代码；而使用Git后，则可以调用git reset --hard V2的versionnumber命令，即可使项目状态还原到V2，快速实现砍掉短视频功能；故事没结束，后来某天老板看着短视频形势大好，决定加上短视频功能，如果没有用Git，员工A的心理阴影可想而知，但有了Git，可通过git reflog命令查看V3的versionnumber，再次调用git reset --hard V3的versionnumber命令，实现开发版本的再次回滚，从而实现短视频功能的轻松复现。

---

三、Git操作分支（紧急修复bug）

3.1 分支相关命令

• git branch：查看当前项目的分支状况，*号所在位置表示为当前正在操作的分支；
• git branch 分支名称：创建新的分支；
• git branch -d 分支名称：删除分支；
• git checkout 分支名称：转换到该分支；
• git merge 分支名称：将该分支合并到当前项目所在的分支位置；

3.2 情景代入

• 书接上文，老板要求员工A再为公司网站开发一个评论功能，并要求员工A保证之前功能可正常运行。员工A决定开辟一条新的分支dev，在其上进行新功能的开发（插入一点：默认情况下，原项目的不同版本V1、V2和V3在同一主线master上，如上图）。故员工A需要调用git branch dev和 git checkout dev命令实现创建新分支的工作。
• 评论功能开发到50%，短视频功能突发bug，需要倒霉蛋儿员工A紧急处理，无奈员工A只能暂时放下手头工作，转去处理短视频bug。此时，员工A通过 git add .和 git commit -m V4的命令将V4（开发到50%的评论功能）加入到版本库中，至此完成了上图的①部分；
• 接下来，员工A调用 git checkout master将当前所在分支切换回master分支，版本自动会回滚到V3版本；
• 之后，调用git branch bug和 git checkout bug命令创建新分支并转换到该分支上处理bug；
• 修复了短视频功能的bug，并通过 git add .和 git commit -m V5的命令将V5（短视频修复）加入到版本库中，至此完成了上图的②部分；
• 此时，修复好bug的短视频功能仍在bug分支上，故为了将bug分支合并到master分支上，首先需调用git checkout master命令转换到主分支上，之后需调用git merge bug命令使bug分支合并到master分支上，至此完成了上图的③部分；
• 由于接下来bug分不会再出现，此处可以调用git branch -d bug命令删除bug分支；
• 解决完bug分支问题，员工A继续开发评论功能，首先需要使当前所在分支转换到dev分支，故需调用 git checkout dev命令；
• 接下来，在V4的基础上继续开发评论功能开发到100%后，员工A通过 git add .和 git commit -m V6的命令将V6（开发到100%的评论功能）加入到版本库中，至此完成了上图的④部分；
• 最后，为了使评论功能合并到master分支上，首先需要调用git checkout master命令转换到主分支上，之后需调用git merge dev命令使dev分支合并到master分支上，至此完成了上图的⑤部分。
• 到此，即完成了当前的全部开发任务，倒霉蛋儿员工A可以稍微休息一下了~

3.3 补充说明

• 上述例子大致演示了一个开发者在已有产品上线的情况下为产品开发新的功能和紧急处理bug的一个大致流程，主分支master上的项目版本可理解为正在线上运营的产品，dev分支主要进行新功能的研发，bug分支主要进行bug的修复；
• 在分支合并的过程中很有可能会产生冲突，此时Git会将产生冲突的部分全部罗列出来，需要手动去处理冲的部分。

---

四、Git与GitHub的常用命令

4.1 Git与GitHub？

首先，做一个概念上的区分，Git是一个软件，用于分布式项目管理；GitHub是一个网站，用于线上存储代码（线上代码仓库），可与Git做到无缝衔接。之前的开发多是在本地进行的，如果员工A打算在家和公司两地“优雅”的开发，此时他该学习一下以下命令。

4.2 Git与GitHub交互的相关命令

在交互之前，首先需要注册GitHub的账号，并在自己的GitHub中开辟一个空间（创建新项目），用于存放自己的项目，以下命令是在默认完成上述任务后进行的。

• git remote add origin 远程仓库地址：该语句为远程仓库地址起个别名origin（便于接下来的使用），只需在初次使用时这么做即可；
• git push -u origin 分支名称：向GitHub推送该分支的代码，其中-u为指定origin所指代的地址为默认地址，一般只用一次即可在双端（家和公司）皆设置为默认，即之后的命令可简写为git push origin 分支名称；
• git clone 远程仓库地址：从GitHub上克隆该项目的代码，适合与初次电脑中没有该项目的时候使用；
• git pull origin 分支名称：从GitHub上拉下该分支的代码；

4.3 情景带入

公司老板对员工A的压榨是大家有目共睹的，这迫使员工A不得不在家中和公司持续007式的疯狂加班。曾经员工A随身携带的10T硬盘因为某些不可告人的原因装满了，为了能够更加优雅的写代码，员工A开始了一系列的骚操作。

• 首先员工A注册了GitHub账号，并在其上创建了一个新项目（当然这里要创建成私密的项目，毕竟是公司的网站，钱应该由公司来拿）；
• 拿到远程仓库地址后，他首先调用git remote add origin 远程仓库地址命令为仓库地址起了个别名origin；
• 之后，调用git push -u origin master和git push origin dev将自己在公司写好的网站全部推送到远程仓库中(bug分支已经被删除了)；
• 接下来回家，由于家中电脑本身没有网站代码，所以员工A需要在家中电脑中通过命令行，cd进入合适的路径，调用git clone 远程仓库地址的命令，将开发好的网站拷贝下来；
• 在家中通宵达旦后，员工A将自己新写好的代码生成新的版本，之后调用git push origin master和git push origin dev命令，将自己在家写好的代码全部推送到远程仓库中；
• 早上来到公司，员工A只需调用git pull origin master和git pull origin dev，将远程仓库的代码拉到公司电脑中，如此循环往复，员工A便实现了在家和公司两地优雅的书写代码。

4.4 补充说明

• 这个图上的命令，道友们可以自行学习参考；
• 补充两点：

• git pull origin 分支名称的功能等同于git fetch origin 分支名称+ git merge origin/分支名称的功能。
• git rebase中文直译为“变基”，拥有多种用法，但该命令的目的多是令记录变简洁，消除开发中一些不必要的分支，此处不做展开，道友自行查阅~

---

五、Gitflow工作流与多人协作开发

• 正式开启故事前，简单交代一下背景，一般的公司开发项目都会在github上有自己的组织，组织中可以管理成员，为成员分配权限，以及创建多个项目等等；接下来讲述的gitflow工作流，将默认在github组织已经存在的基础上进行讲解；
• 到此，故事中一直是员工A独自一人没日没夜的开发，为了让日子更有盼头，公司为员工A分配了两个小弟，而且员工A的职位也从普通的码农跃升称为项目经理，从此不在亲自写代码，只需要完成上图中的某几步操作即可，下面将详细介绍gitflow工作流；
• 首先，员工A将之前开发的项目版本进行整合，整合成了上图中的V1（调用git rebase命令）；然后创建了新分支dev以及小弟1和小弟2，用于后续开发新功能——客服，至此完成了上图①；
• 接下来，员工A将客服功能拆分成聊天和表情包两小部分，分别让小弟1和小弟2在自己的分支上独立开发，至此完成了上图②；
• 接到任务后，两个小弟开启了007工作模式没日没夜的加班码代码，直到某天，小弟1完成了聊天功能，通过github向员工A发送了pull request（github上的一个操作，用来向上级申请代码审核）申请，员工A一看，小弟代码写的不行啊，提了些问题让小弟改改；过了几天两个小弟经过无数次的修改，终于都完成了各自任务，员工A决定向测试部门提交这次开发的代码，到此完成了③④⑤三个部分；
• 员工A提交代码后，测试部门在新建的release分支上对新功能进行多种应用场景的测试，有问题，则修改相应的bug，直至没有问题为止，则准备并入master分支，正式上线；
• Ps：上述是一个公司在开发一个新项目的大致流程，可能某些公司会缺少其中的一些步骤，不过从规范上讲，应该按照上图的流程开发。上述的内容中缺少了具体的实操（因为鄙人能力有限，感觉这个过程很难用言语详尽的叙述），只是做了一个流程上的叙述，不过各位道友也可借此尝试着去自行动手实践一下~

---

六、其他边边角角

6.1 关于配置信息

• 说明一下在配置Git的用户名和用户邮箱时，常用到--local、--global和--system，三者区别以及各自对应的配置文件所在位置如下：
• --local表示配置信息只对当前项目生效，配置文件在“项目文件/.git/config”中，常用命令有：

• git config --local user.name '用户名'；
• git config --local user.email '用户邮箱'；

• --global表示配置信息对全局项目生效，配置文件在“~/.gitconfig”中，常用命令有：

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

• --system表示配置信息对当前系统生效，配置文件在“/etc/.gitconfig”中，常用命令有：

• git config --system user.name '用户名'；
• git config --system user.email '用户邮箱'；

6.2 关于免密登录github

• github在初次登录时会要求输入账号密码，之前版本的github甚至在每次传输文件时都需要验证账号密码，下面提供三种免密登录github的方法：
• Git自动管理凭证

• 之所以现在使用github时只用在初次使用时输入账号和密码，是因为当前版本的github支持自动管理凭证，故只需验证一次即可；

• URL中体现

• 直接在初次为远程仓库地址重命名时，将地址进行一定的修改，如下：
• git remote add origin https://用户名:密码@github.com/XXX/xxx.git

• SSH实现(公司常用)

• 生成公钥和私钥

• 在Git中输入命令ssh-keygen，会生成公钥和私钥；在~/.ssh目录下的文件中，id_rsa.pub为公钥、id_rsa私钥；

• 拷贝公钥的内容，并设置到github中。
• 在git本地中配置ssh地址

• git remote add origin [email protected]:XXX/xxx.git

• 以后使用和URL一样

• git push origin 分支名称

6.3 关于gitignore

• 用于在Git中设置一个不用Git管理的文件名单，其本身是一个文件，文件中写入不想让Git管理的文件名单即可。

七、总结

本文不知不觉写了小六千字，如果各位道友感觉不错，希望赏个三连关注，鄙人在此谢过，解释含糊的地方希望大家包容，新人up，愿与诸君携手共同进步~