大家好，欢迎来到停止重构的频道。
本期我们讨论Git。
Git是开源的版本控制系统，常用于代码管理、文件管理等场景。
需要提前说明的是，本期只讨论Git本身，至于实际项目中多人合作、多版本管理等问题。
实际上是团队工作流的问题，我们将在下一期展开。
提纲
我们按以下顺序展开讨论
1、Git介绍
2、Git工作原理
3、Git服务端、客户端安装
4、Git常用操作
Git介绍
首先介绍Git，Git是一个开源的版本控制系统，常用于代码管理等场景。
简单地说，可以将Git理解为存储文件的仓库，方便多个用户将文件集中存储到服务器中，或从服务器下载文件副本到本地磁盘。
文件的类型不受限制，可以是代码等文本文件，也可以是图片、视频等媒体文件。
当然，Git服务并不是简单地存储文件，它会记录每一次文件修改。用户可翻看历史版本的文件，或者删除某些历史修改以还原文件。
这也称为版本管理。
虽然听上去版本管理没有太大的作用，但是在多人参与或长时间开发的软件项目下，版本管理是必要的。
例如，在实际开发过程中，会经常出现一些功能回退。就是以前好用的，现在却出现BUG的情况。
通过翻看代码文件的历史版本，可较快速地定位哪次修改影响了这个功能，也能知道团队中哪个人做了这次修改。
当然，能做文件版本管理的当然不只有Git。
SVN也可以，不过，一般都认为Git是优于SVN的。毕竟Git的作者是因为受不了SVN才编写了Git。
相对于SVN，Git允许分布式部署。另外，Git需要的存储空间也会相对少一些，Git是按元数据存储的，而SVN则是按文件存储。
最重要的，Git服务是一个系统核心，用户可选择功能更加丰富的平台服务，如GitHub、Gitlab。
那么，Git、Gitlab、GitHub是什么关系呢。
Git可以理解为系统核心，是没有界面的。
Gitlab、GitHub是在Git基础上建设的平台，里面包含Git服务，这些平台拥有更加完善的后台管理网站。也拥有更加丰富的功能，如项目管理、版本视图、权限管理等。
所以我们一般不直接使用或部署Git服务，而是使用功能更加完善的Gitlab、GitHub平台服务，其中Gitlab支持私有化部署。
Git工作原理
接下来是Git的工作原理。
Git是c/s（客户端-服务端）架构的服务，整体结构分4个部分：远程服务、远程仓库、本地Git客户端软件、本地仓库副本。
远程服务是Git的服务端，更具体的说，就是Gitlab、GitHub等平台，或者是自己在服务器安装的Gitlab。
远程服务接受文件获取、上传等请求，并记录每个文件的修改。用户可通过远程服务提供的管理网站管理仓库、历史修改等。
远程服务端的文件是按仓库为单位存储的，用户可创建多个仓库，一个仓库可以简单地理解为一个文件夹，一个仓库下允许存储多个文件、创建多级文件夹目录。
且文件的类型不受限制，可以是代码等文本文件，也可以是图片、视频等媒体文件。
本地Git客户端是安装在本地的软件，Git客户端是同步远程仓库与本地仓库副本的关键。
用户需要通过Git客户端，从远程服务端克隆、更新本地仓库副本。也需要通过Git客户端，才能将本地仓库副本的修改同步到远程仓库。
本地仓库副本对应远程服务端中的一个仓库，实质上是根据远程仓库克隆到本地磁盘的一个文件夹。
文件夹内的文件对应远程仓库的文件，文件夹内的文件是可以自由操作的，跟普通的文件操作没有区别。
本地仓库副本对比普通的文件夹，只是多了一个.git的隐藏文件夹。里面会记录远程仓库信息、日志、未提交远程仓库的记录等。
Git客户端、服务端安装
接下来是Git服务端、客户端安装。
Git服务端的话，可以是GitHub、Gitlab等平台，如果希望私有化部署Git服务的话，推荐以docker的形式安装Gitlab。
安装命令如图所示，如果对docker不太熟悉，可以翻看往期内容。
另外，如果担心私有化部署有磁盘损坏风险的话，Gitlab也支持集群化部署、第三方平台仓库备份等，这里不作展开。
而Git客户端是每个用户都需要安装的，Git客户端通常是命令行工具。
当然，也可以选择有图形界面的Git客户端软件，如GitHub desktop、Fork等。
另外，一些代码编辑软件是集成Git客户端的，如Vscode。使用这些代码编辑软件的话，可以不安装额外的Git客户端。
Git常用操作
接下来是Git的常用操作，我们将Git常用操作根据操作顺序分为：
1、新建项目、项目管理
2、克隆、更新项目
3、上传本地修改
操作：新建、管理远程仓库
首先是新建、管理远程仓库。
虽然Git客户端也可以完成这一操作，但是操作起来比较麻烦，所以一般新建、管理仓库都在服务端提供的管理网站完成。
以Gitlab为例，在后台管理页面即可新建远程仓库。
关于远程仓库管理，有几个点需要特别说明，分别是修改记录、分支、tag、权限。
修改记录是每次上传更新的记录，每个修改记录都有唯一的修改记录id，一个修改记录可能包含多个文件的修改。
用户可以查看单次修改的具体内容，也可以对此次修改进行回滚操作。
回滚操作实际上是新提交一次更新以复原修改，但是回滚的修改记录不是最新修改记录的话，则会可能由于修改冲突而失败。这时候则需要人工修改再提交远程仓库。
分支是一个远程仓库内的多个独立副本，每个分支都是完全独立互不影响的，包括文件、修改记录等都是完全独立的。
一个远程仓库默认有一个主分支，默认情况下，文件会存储到主分支。
用户创建新分支时，需要基于某个修改记录、某个分支、或者某个tag才能创建。
一个分支的多次修改可一次全部更新到别的分支，称为合并。
合并操作实际上是对目标分支提交一次新修改，但是如果目标分支也修改过某个文件，则可能由于修改冲突而失败，这时候也需要通过人工修改文件更新到目标分支。
tag是一个标识，用于标记某个修改记录。
便于归档对应分支下截止到此次修改的文件，防止因为修改记录太多而造成混乱，方便版本迭代管理。
tag与分支是不同的，tag只是标记修改记录方便查看，是不允许更新操作的，而分支是一个独立的副本，允许更新文件。
最后，管理员可对仓库进行用户权限管理，包括查看、文件修改、仓库管理等权限。
操作：克隆、更新本地副本
接下来是关于本地仓库副本的克隆、更新操作。
当需要拉取某个远程仓库的文件到本地时，需要先在管理页面获取远程仓库的克隆地址，然后使用git客户端将远程仓库克隆到本地。克隆命令如图所示。
当然也可以使用Github desktop等软件进行操作，操作原理是一样的。
顺便一提，如果仅仅是为了方便查看远程仓库的文件，可以直接从管理页面下载文件压缩包。
但是直接下载文件压缩包的话，是不支持后续更新、上传操作的。
默认情况下，克隆的是远程仓库的主分支，如果希望切换别的分支，可以通过git客户端切换分支。
切换分支后，本地仓库副本中的文件将会改变。
值得注意的是，如果当前仓库副本中的文件被修改了且未提交，则不能切换分支。如果需要使用一个远程仓库的多个分支的代码，建议克隆多个本地仓库副本。
如果远程仓库的文件被别的用户更新了，可通过更新操作更新本地仓库副本的文件。
但是如果恰巧需要更新的文件本地也修改了，则会发生更新冲突而更新失败。
发生更新冲突时，可以通过git stash命令暂存本地修改，更新完毕后再恢复本地修改，git将会把更新冲突的内容标记出来。后续需要人工处理这些更新冲突的内容。
当然，发生更新冲突时，也可以克隆一份新的本地仓库副本，再通过beyond compare等工具对比差异文件，再人工修改这些差异内容。
这里顺便一提，随着多次提交、更新操作，本地仓库副本的.git文件夹会越来越大。
要是想对.git文件夹进行瘦身，虽然有更官方的做法。但是我们更推荐，在确保修改已同步到远程仓库的前提下，删除并重新克隆一个本地仓库副本。
操作：上传修改
最后是上传操作，对本地仓储副本中的文件修改完成后，需要手动上传到远程仓库才能同步。
上传一般分为3步，添加文件到暂存区、提交本地仓库、提交远程仓库。
添加文件到暂存区，是选定哪些被修改的文件为此次上传的内容，github desktop等软件的话，直接勾选就可以了。
Git命令行工具的话，则需要先通过git status命令查看被修改的文件列表，然后通过git add命令添加文件到暂存区。
这里顺便一提，Git认为空文件夹是无效的，也就是不会提交。
这种情况可以在空文件夹内创建.gitkeep文件，当然其他名字也可以，仅仅是为了让这个文件夹不空。
另外，Git对文件名的大小写不敏感，所以如果将文件名从小写的config改成大写的CONIFG，Git并不会认为这是一次更新。
这种情况需要用户删除文件上传同步后，再重新添加文件再上传同步。
添加文件到暂存区后，就可以提交本地仓库了。提交本地仓库是将暂存区的修改内容打包成一次更新，需要用户为此次更新填写更新日志。
提交本地仓库后并不会同步远程仓库，Git客户端仅仅将此次修改，记录在本地仓库副本的.git文件夹中。
用户可多次添加文件到暂存区并提交本地仓库，以根据不同修改目的，记录多个更新、填写多个更新日志。
最后是上传远程仓库，上传远程仓库可一次性将多次本地仓库修改同步到远程仓库。上传远程仓库后，本地仓库副本的修改才会真正同步到远程仓库。
提交远程仓库时，要求本地仓库副本为远程仓库的最新版本，如果没有更新冲突，则更新完本地仓库副本后再次提交即可。
但是如果发生更新冲突的话，就是恰巧本地修改的文件在远程仓库中也被修改了。
则需要先撤销之前提交的本地仓库修改，解决好更新冲突后，再重新提交上传。解决更新冲突的方法请翻看前面内容。
当然，也可以忽略更新冲突，强制上传远程仓库，但这个非常不推荐，这个操作会引起团队代码覆盖的问题，就是把别人代码弄没了。
总结
本期介绍了Git与其常用的操作，关于Git更多的操作说明可以查看官网。
从本期不难发现，更新冲突是比较麻烦的事情，必须用户手动解决。
那么是否有规避的解决方案呢，我们将在下一期展开讨论，在多人参与、多版本管理的场景下，如何用好Git。
精彩内容
您阅读本篇文章共花了：
发表评论