如果学习Git对你来说很无聊，那是因为你还没有玩过这个游戏！

大家好！我是农民工小哥。对于Git，相信大多数程序员都不陌生。作为世界上最先进的分布式版本控制系统（没有之一），Git是一款开源的分布式版本控制软件，用于高效、高速地处理从小到大的项目版本管理。Git最初是由LinusTorvalds设计和开发的，用于管理Linux内核开发。久而久之，Git发展到今天，已经成为很多开发者必备的开发工具。如果你平时学习Git的时候觉得无聊，不妨试试这个好玩的小游戏，换一种方式在娱乐中学习。以下是演示示例：需要这款游戏的读者可以点击下方的名片公众号回复关键词Git小游戏获取Git介绍Git是一个开源的分布式版本控制系统。什么是版本控制？版本控制是一种记录一个或多个文件内容变化的系统，以备将来参考特定的版本修订。什么是分布式版本控制系统？在介绍分布式版本控制系统之前，有必要了解一下传统的集中式版本控制系统。集中式版本控制系统，如CVS、Subversion等，有一个单一的集中管理服务器保存所有文件的修订，一起工作的人通过客户端连接到这个服务器，取出最新的文件或提交更新。这样做最明显的缺点是中央服务器的单点故障。如果有一个小时的停机时间，在这个小时内没有人可以提交更新，他们也不能一起工作。如果中央服务器的磁盘出现故障，你恰好没有备份，或者备份不够及时，你就有丢失数据的风险。最坏的情况是完全丢失整个项目的所有历史变更记录。分布式版本控制系统的客户端不仅提取了最新版本的文件快照，还完整地镜像了代码仓库。这样，如果任何一个用于协同工作的服务器发生故障，之后可以用任意一个本地镜像仓库进行恢复。因为每一次抽取操作其实都是对代码仓库的一次完整备份。可以参考：Git从入门到精通GitvsSVNGit和SVN哪个更好，每个人都有不同的体会。Git是分布式的，SVN是集中式的。这是Git和SVN最大的区别。如果能掌握这个概念，就基本能明白两者的区别了。因为Git是分布式的，Git支持离线工作，很多操作都可以在本地进行，包括接下来要推出的分支功能。而且SVN必须联网才能正常工作。Git有很多复杂的概念，而SVN简单易用。所有同时掌握Git和SVN的开发者都必须承认Git中的命令太多了。日常工作需要掌握add、commit、status、fetch、push、rebase等，要想精通掌握，还必须掌握rebase和merge的区别，fetch和pull的区别等。另外,还有cherry-pick,submodule,stash等函数，但是这些名词听上去很费解。在易用性上，SVN会更适合新手。但另一方面，更多的Git命令意味着更多的功能。如果我们能够掌握Git的大部分功能，了解其中的奥妙，就会发现我们再也回不去SVN的时代了。Git分支很便宜，SVN分支很贵在版本管理中，分支是一个非常常用的功能。在版本发布之前，大需求开发需要发布一个分支，这就需要一个特性分支，而一个大的团队也会有开发分支，稳定分支等。在大团队的开发过程中，经常会有创建分支和切换分支的需求。Git分支是指向提交的指针，而SVN分支是复制的目录。这个特性使得Git的分支切换非常快并且创建成本非常低。而Git有本地分支，SVN没有本地分支。在实际的开发过程中，经常会遇到一些代码没有写完，而另一些问题又需要紧急处理的情况。如果我们使用Git，我们可以创建一个本地分支来存放未完成的代码。问题解决后，我们可以回到本地分支继续完成代码。更多关于Git和Svn对比的关注请参考：通俗易懂｜用好Git和SVN轻松掌控版本管理。Git的工作原理，文字很难理解。使用的系统为Debian/Ubuntu，安装命令为：$apt-getinstalllibcurl4-gnutls-devlibexpat1-devgettext\>libz-devlibssl-dev$apt-getinstallgit-core$git--versiongitversion1.8.1.2Centos/RedHat环境安装如果你使用的系统是Centos/RedHat，安装命令为：$yuminstallcurl-develexpat-develgettext-devel\>openssl-develzlib-devel$yum-yinstallgit-core$git--versiongitversion1.7.1Windows环境安装从Git官方下载地址下载exe安装包。按照安装向导进行安装。推荐安装git的命令行工具GitBash。Mac环境安装从Git官方下载地址下载mac安装包。按照安装向导进行安装。Git配置Git附带一个gitconfig工具来帮助设置控制Git外观和行为的配置变量。这些变量存储在三个不同的地方：/etc/gitconfig文件：包含系统上每个用户及其存储库的通用配置。将gitconfig与--system选项一起使用时，它会从此文件读取和写入配置变量。\~/.gitconfig或\~/.config/git/config文件：仅对当前用户有效。您可以传递--global选项让Git读写这个文件。当前使用的仓库的Git目录下的config文件（即.git/config）：针对本仓库。每一层都会覆盖上一层的配置，所以.git/config中的配置变量会覆盖/etc/gitconfig中的配置变量。在Windows上，Git在$HOME目录（通常是C:\Users\$USER）中查找.gitconfig文件。Git也会查找/etc/gitconfig文件，但只在MSys的根目录下，这是安装Git时选择的目标位置。Git基本概念仓库当你在本地创建一个项目或者创建一个git项目时，项目目录下会有一个隐藏的.git子目录。这个目录是git用来跟踪和管理仓库的，所以不要手动修改。哈希值Git中的所有数据在存储之前都经过校验和，然后通过校验和引用。这意味着在Git不知情的情况下不可能更改任何文件内容或目录内容。这个功能是在Git的引擎盖下构建的，是Git哲学的一个组成部分。如果您在传输过程中丢失信息或损坏文件，Git会发现。Git用来计算校验和的机制称为SHA-1散列（hash）。这是一个由40个十六进制字符（0-9和a-f）组成的字符串，根据Git中文件或目录结构的内容计算得出。SHA-1散列看起来像这样：24b9da6552252987aa493b52f8696cd6d3b00373这个散列在Git中用得很多，你会经常看到它。事实上，Git数据库中存储的信息是通过文件内容的哈希值来索引的，而不是文件名。文件状态在Git中，您的文件可以处于以下三种状态之一：已修改-已修改意味着文件已被修改但尚未保存到数据库中。Staged-Staged意味着修改文件的当前版本被标记为包含在下一个提交的快照中。Committed-Committed表示数据已经安全地存储在本地数据库中。工作区对应文件的状态，不同状态的文件在Git中处于不同的工作区。工作区（working）——当你在本地gitclone一个项目时，相当于在本地克隆了一个项目的副本。工作区是项目版本的独立提取。这些文件是从Git存储库的压缩数据库中提取出来的，并放在磁盘上供您使用或修改。暂存区（staging）——暂存区是存放下次要提交的文件列表信息的文件，一般在Git仓库目录下。它有时也被称为“索引”，但通常被称为暂存区。本地仓库（local）——提交更新，在暂存区查找文件，永久存储快照到Git本地仓库。远程仓库（remote）——上面的工作空间都是本地的。为了让其他人看到您的更改，您需要将更新推送到远程存储库。同样，如果要同步其他人的修改，需要从远程仓库中拉取更新。分支（Branch）分支是将修改记录的整个过程分开存放，使得单独的分支不受其他分支的影响，所以可以在同一个数据库中同时进行多个不同的修改。前面提到的master主分支（Master）是Git自动为我们创建的第一个分支，也叫主分支。其他分支开发完成后，必须合并到主标签（Tag）中，标签用于标记特定的点或提交历史，通常用于标记发布版本的名称或版本号（如：publish/0.0.1)，虽然标签看起来有点像分支，但是标签的commit是固定的，不能随意改变，见上图中的1.0/2.0/3.0HEADHEAD，它指向的是当前分支的最新提交图片。上面的概念理解的差不多了，可以继续往下看。创建仓库的Git命令克隆创建的仓库：#通过SSH$gitclonessh://user@domain.com/repo.git#通过HTTP$gitclonehttp://domain.com/user/repo.git创建新建本地仓库：$gitinit添加修改将修改添加到暂存区：#添加指定文件到暂存区$gitaddxxx#添加当前所有修改到暂存区$gitadd.#添加所有修改到暂存区$gitadd-A提交修改到本地仓库：#提交所有本地修改$gitcommit-a#提交之前标记的修改$gitcommit#附加消息提交$gitcommit-m'commitmessage'storage有时，我们需要在同一个项目的不同分支上工作。当需要切换分支机构时，本地工作尚未完成。这时候提交修改是不严谨的，但是不提交代码是不可能切换分支的。此时，您可以使用gitstash将本地更改存储为草稿。官方称之为存储，但我个人更喜欢称之为草稿。#1.将修改保存为当前分支的草稿$gitstash#2.查看草稿列表$gitstashliststash@{0}:WIPonmaster:6fae349:memo:Writingdocs.#3.1删除草稿$gitstashdropstash@{0}#3.2读取草稿$gitstashapplystash@{0}撤消修改撤消本地修改：#删除缓存区中的所有文件（即撤消最后一次gitadd）$gitresetHEAD#将HEAD重置为上面提交一次版本，将后面的修改标记为未加入缓存的修改$gitreset#将HEAD重置为上次提交的版本，保留未提交的本地修改$gitreset--keep#放弃工作目录下的所有修改$gitreset--hardHEAD#将HEAD重置为指定版本，并放弃该版本之后的所有修改$gitreset--hard#使用far结束分支强制覆盖本地分支$gitreset--hard例如，upstream/master,origin/my-feature#放弃文件的所有本地修改$gitcheckoutHEAD在添加.gitignore文件之前删除错误提交文件：$gitrm-r--cached.$gitadd.$gitcommit-m"removexyzfile"撤消远程修改（创建新提交，并回滚到指定修订版）：$gitrevert彻底删除指定版本：#执行以下命令后，commit-hash提交的记录会被彻底删除，所以使用时要小心$gitreset--hard$gitpush-fupdateandpushupdate:#下载远程版本，但不合并到HEAD$gitfetch#合并远程版本到本地版本$gitpulloriginmaster#通过rebase将远程分支与本地合并$gitpull--rebasePush:#将本地版本推送到远程$gitpushremote#删除远程分支$gitpush:(sinceGitv1.5.0)$gitpush--delete(sinceGitv1.7.0)#发布标签$gitpush--tags查看信息显示工作路径有beenModifiedfile:$gitstatus显示与上次提交的版本文件的差异：$gitdiff显示提交历史：#从最近一次提交开始，显示所有提交记录（显示hash、作者信息、提交标题和时间）$gitlog#显示一个用户的所有提交$gitlog--author="username"#显示一个文件的所有修改$gitlog-p显示搜索内容：#从当前目录的所有文件中查找文本内容$gitgrep"Hello"#在某个版本中搜索文本$gitgrep"Hello"v2.5分支增删查branch:#列出所有分支$gitbranch#列出所有远程分支$gitbranch-r#新建一个基于分支在当前分支上$gitbranch#基于远程分支创建新的可追踪分支$gitbranch--track#删除本地分支$gitbranch-d#强制删除本地分支，未合并的修改将丢失$gitbranch-D切换分支：#切换分支$gitcheckout#创建并切换到新分支$gitcheckout-btag#标记当前版本$gittag#给出当前版本标记并附上一条消息$gittag-a合并和重置虽然merge和rebase是git常用的功能，但是强烈建议不要使用git命令来完成这项工作，因为如果有代码冲突，有没有代码比较工具的案例太难了。您可以考虑使用各种GitGUI工具。Merge:#将分支合并到当前HEAD$gitmergeReset:#将当前HEAD版本重置到分支中，不重置已发布的提交$gitrebase更多命令参考：三年Git经验&常见问题组织Git分支开发Git是目前最流行的源代码管理工具。为了规范开发，保持代码提交记录和git分支结构清晰，方便后续维护，现规范git的相关操作。分支命名1.master分支master是主分支，也是用来部署生产环境的分支，保证master分支的稳定性。master分支一般由develop和hotfix分支合并，不能随时直接修改代码。2.develop分支develop是开发分支，始终保持最新完成和bug修复的代码，一般在开发新功能时，都会在develop分支的基础上创建特性分支。featurebranch在开发新功能时，在develop的基础上创建一个feature分支。分支命名：feature/开头的是feature分支，命名规则：feature/user_module,feature/cart_modulelease分支release是预发布分支，在release测试阶段，release分支代码会作为benchmark测试.当一组特性开发完成后，会先合并到开发分支，进入测试时再创建发布分支。如果测试过程中有bug需要修复，开发者会在release分支上直接修复并提交。测试完成后，release分支合并到master和development分支。此时master是最新的代码，用于在线。hotfixbranch分支命名：hotfix/以fix分支开头，其命名规则与feature分支类似。当线上出现紧急问题，需要及时修复。以master分支为基线，创建一个hotfix分支。修复完成后，需要合并到master分支和develop分支。更多开发规范请参考：全网最全的Git分支开发规范手册|掌握这10个规范，轻松驾驭Git！如果您喜欢，请使用Git的这些高级用法！为什么Git提交规范需要规范？没有规矩就没有规矩，编程也一样。如果你有一个项目，你从头到尾都是自己写的，你想怎么写就怎么写，谁也不能干涉。但是如果每个人都在团队合作中表现出自己的个性，那么代码就会乱七八糟，一个好的项目也会毁于一旦。无论是开发还是以后的维护，都会是一场灾难。这时候有人提出为什么不统一标准，大家都按照这个标准来做。于是，ESLint、JSHint等代码工具如雨后春笋般涌现，成为项目建设的必备产品。GitCommit规范可能没有那么夸张，但如果你在版本回滚时看到很多错误的提交，恐怕你会很生气。所以，严格遵守规范，利人利己。具体可以参考：你可能会忽略的Git提交规范常用企业工作流主要介绍企业中常用的Git工作流！GitFlowMainBranchStableBranchDevelopmentBranchPatchBranchModificationBranchGithubFlowCreateBranchAddSubmission提交PRRequest讨论评估代码部署检测合并代码Git用法和方法要遵循！使用命令行代替图形界面使用命令行操作，简洁高效提交内容尽量表达提交修改内容区分主题和正文内容，使用空行分隔主题一般不超过50个字符每行主体控制的长度72个字符的主题的末尾无需使用句点或点。body是用来详细说明这个提交做了什么的。使用。开发方式不要直接在主分支上开发使用新分支开发功能和修复问题使用release分支和tag标记进行版本管理使用release分支发布代码和版本维护(release/1.32)使用tag标记版本（A-大特性功能。B-小特性功能。C-只修复bug）常用命令汇总整理，方便日常使用，记住6条命令即可。无论是开发、运维，还是测试，大家都知道Git在日常工作中的地位。因此，它也是每个人必须学习和必备的技能之一。但是，打工的兄弟们，我经常看到有读者在后台抱怨命令太多难记，用久了就忘记了。是的，学习一门技术真的很难，更何况现在技术更新迭代这么快。。。所以，对于Git的技术学习，如果有一个可以看懂的入门资料就好了一目了然，一目了然。前不久，国外一位小姐姐写了这样一篇文章《CS Visualized: Useful Git Commands》。作者是来自不列颠哥伦比亚省的年轻女士莉迪亚·哈莉(L??ydiaHallie)。在这篇文章中，她使用生动的动画以更直观的方式向开发人员展示Git命令中的合并、变基、重置、还原和cherry-pick。以及其他常用的表演操作的具体原则。小姐姐用动画来说明Git命令，让你一目了然！#工作区->暂存区$gitadd#暂存区->本地仓库$gitcommit-m"someinfo"#本地仓库->远程仓库$gitpushoriginmaster#本地主分支推送到远程源仓库#工作区<-暂存区$gitcheckout--#暂存区文件内容覆盖工作区文件内容#暂存区<-本地仓库$gitresetHEAD#本地仓库文件内容覆盖暂存区文件内容#本地仓库<-远程仓库$gitclone#克隆远程仓库$gitfetchupstreammaster#拉取远程代码到本地但不应用到当前分支$gitpullupstreammaster#拉取远程代码在本地但应用到当前分支$gitpull--rebaseupstreammaster#如果平时使用rebase合并代码，添加#工作区<-本地仓库$gitreset#本地仓库覆盖到工作区（保存回退文件内容修改）$gitreset--mixed#本地仓库覆盖到工作区（保存回滚文件内容修改）$gitreset--soft#本地仓库覆盖到工作区（保留更改）并添加到暂存区）$gitreset--hard#将本地仓库覆盖到工作区（删除不保留修改）更多关于Git使用技巧的介绍可以参考：学习这11条，而你将离Git高手不远了！Git知识体系的动态更新在这里：Git技术学习