GitIs a distributed version control system open source, can be effective, high-speed processing from very small to very large project version management.GitIt isLinus Torvaldsto help manageLinuxkernel development and the development of an open source version control software. This article from the originalGitcommand starting to learn the actual process of developing the most common and most effective, the most basic commands, helpGitbeginners to quickly integrate into community development. Due toGitlearn the basic commands are laying the foundation, while the actual development process mostly done in conjunction with the development of software version control, so after completing learning basic command-line operation, based on the late launchIntelliJ IDEAofGitthe operation study notes.
This article will focus on the following points:
-
Basic introduction of Git
-
The basic operation of Git
-
Git branch operations
-
Git commit operation changes
-
Pushed to the remote repository
-
Obtain from a remote repository
A, Git basic introduction
How to understand Git? Git is what?
For just joined the job market newcomer, was assigned to the first task often is: the code from a remote repository to pull down, and to be familiar with the code. If you've never had any contact Git, then pull the code will have considerable difficulty, because you do not understand how to pull codes. If you come into contact with before Git, and used in the school over Gitto the code version control, then you should Githave a basic understanding, at least pull the code, add an index, pushing code to the basic operation of remote warehouses. In fact, we have some of the basic version control in the learning process thought that at the time of writing papers, often maintain multiple copies of a document, version control manually on each file name, as shown below:
From the figure above As can be seen, the use of this original version of the manual control can be done to control the point in time according to the document version can even fall back to a point in time to write a document, or the document merge different points of time, but this version control manually always have limitations, the entire version of the control can only be done by one person, if people are controlled, it must be confusing, cluttered lead content of the document, the document editors confused. This document looked at the pile of mess, want to keep the latest version of which, delete the other versions, but they feared that one day the deleted document will be used again, not daring to delete.
The above problems will be Gitthe end, Gitmanaged document (text document) allows multiple people to make changes to the same document, the contents of each modified easily to merge and create a new branch based on the current content to continue in the new branch modify, and finally merged into the current branch, to ensure that documents are always up to date.
So, in the end what is Git? For example, the traditional way of team work, Jackin the development of the project, found that a certain part of the need Johnto complete, so he sent a file copy John, and then continue their work. The next day Johntransfer the file back, this time may Jacknot knowJohnWhat changes to the file can not clearly distinguish change his past, unless previously done well clear agreement between them or Jackwait Johnto complete before continuing their work.
Use Gitwill greatly simplify the process. JackTheir work will upload content to a remote repository, Johncopy the contents of the remote repository to local, after two people carry out their own work. When Johnthe completion of the work, notify Jackpull project updates, the pull process, Gitwill automatically merge changes between the two sides as a whole, if you modify the project members of conflict (such as modifying the same place), Gitallows you to manually select what content to fill the conflict place. This feature also benefited from Gitthe version control mechanism. When the content of the file is modified, Gitpartially modified will be divided into zones of recording occurs, in units of blocks so as to automatically merge. GitAlso recorded each modification of the contents of the node, each commit, Gitgenerate a HASHvalue as the version number, we can find the desired version by looking at the history of the project, and by the version number of the current version is rolled back to the specified version. The figure is a schematic diagram of a local warehouse and central warehouse:
in short, Gitto bring the convenience of far more than that, in use later, you will appreciate her charm.
Git understanding of the work area and buffer zone
-
Workspace (
working directory)
in the new folder to initialize aGitlater warehouse, then the current folder can become a workspace file in the work area can be seen, of course, this does not include the initial warehouse Workspace generated.gitfolder. -
Repository (
repository)
workspace there is a hidden folder.git, this is not the work area, butGitthe repository.
Git的版本库里存在很多东西，其中最为重要的是stage（或者叫index）的暂存区。还有Git为我们自动创建的第一个分支master，以及指向master的第一个指针叫HEAD。
Git中添加，是分两步执行的：
第一步是用git add把文件添加进去，实际上是把文件修改添加到暂存区；
第二步是git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。
可以理解为需要提交的文件统统放在暂存区，然后，一次性提交暂存区的所有修改。
二、Git的基本操作
阅读上面的内容之后，对Git有了一个基本的了解，但是要更加深刻地了解Git，得通过操作命令来慢慢了解。下面将介绍Git的常见命令，跟着命令来一步一步学习Git。
git init——初始化仓库
建立一个空文件夹，如果需要使用Git对文件夹内的文本文档进行版本管理，那么就必须进行仓库初始化。进入新建的文件夹中，打开命令行工具，使用git init命令。
出现上面的结果表示当前的仓库初始化成功。初始化成功之后，会在当前文件夹生成一个.git的隐藏文件夹，这个.git文件夹里存储着管理当前目录内容所需的仓库数据。对于文件夹内的文件结构，后期将出相应的文章进行介绍。
在Git中，我们将这个目录的内容称为“附属于该仓库的工作树”。“工作树”就是工作区，文件的编辑操作都在工作树中进行，然后记录到仓库中，以此管理文件的历史快照。如果想要将文件恢复到原先的状态，可以从仓库中调取以前的历史快照，在工作树中打开。具的操作方式将在后面详细介绍。
git status——查看仓库的状态
git status是一个非常有用的命令，可以通过这个命令来查看仓库的当前状态。
因为是刚刚初始化的仓库，所以显示正在处于master分支（主分支）下，关于分支内容，后面也会讲到，这里不必过于深究。接下来又显示了没有可以提交的内容，如果新建文件或者拷贝文件到当前工作树，可以使用git add来进行追踪（添加索引）。
现在我们在当前工作树中添加一个新文件README.md作为被管理对象，当然任何文本文件都是可以被管理的，然后再尝试使用git status来观察仓库的状态。
添加完新文件以后，仓库的状态变了，显示的是当前有未被追踪的文件README.md（这里有一个小细节，新添加的README.md还未被Git管理的时候，显示的是红色，后面使用到IntelliJ IDEA的时候，新创建的*.java未被管理之前，文件显示也将是红色，根据颜色也可以判断当前文件的状态）。类似地，只要对Git的工作树或者仓库进行操作，git status命令的显示结果都会发生变化。
git add——向暂存区中添加文件
如果我明只是在工作树中添加或者修改了文件，那么这个文件将不会被git管理，换句话说就是无法进行版本管理，那么添加、修改完文件，需要将其用Git管理起来，那么就需要使用到git add命令。git add后面的参数可以是一个文件夹，可以是一个文件，或者是某一类文件（*.java）等。
添加完之后，再次查看仓库状态，又发生了变化，显示的是Changes to be committed，表示又未提交的修改（这里有一个小细节，未提交修改的文件显示的是绿色，后期在IntelliJ IDEA中显示绿色的文件*.java表示修改后添加了索引但还未提交）。这里还显示了可以使用命令git rm --cached <file>来撤销已添加到暂存区的文件，这里只会移除添加到暂存区的数据，不会影响到工作树中的文件，我们来具体操作一下。
这时候的状态和添加README.md到暂存区之前的状态一模一样。
git commit——保存仓库的历史记录
- 记录一行提交信息
git commit命令是提交命令，是将已经添加到暂存区的文件提到到本地仓库的历史记录中，通过这些记录，就可以在日后的某一天将此时的文件状态进行恢复。具体的命令是git commit -m "提交信息，可以是任何内容"。参数-m之后是提交的信息，一般都是记录当前修改的内容等。
这就将README.md文件提交到了本地仓库中，提交产生的日志表示新增了一个文件，没有删除任何文件。
- 记录详细提交信息
有时候我们提交代码的时候仅仅一行提交信息难以描述清楚本次修改的具体内容，所以需要写多行描述信息，那么我们可以直接使用git commit命令来完成多行提交信息的记录。在此之前，我们在刚才测试的文件中添加一些内容，然后重新提交，测试多行描述信息编写的功能，最后测试git commit命令。
对其添加了一些内容之后，必须添加索引后才可以进行提交。
其中在添加多行提交信息的时候，添加的方法和使用vim工具对文本文件进行编辑的方法是一致的，不会使用vim的朋友可以自行学习。
git log——查看提交日志
git log是一个很重要的命令，使用它可以查看当前仓库提交的日志信息，通过日志信息可以很方便查看何人在何时对代码进行了提交和合并，以及提交前后的区别。
使用git log查看刚才我们已经提交的两次内容，如下图所示：
上图中显示了两次提交的详细内容，包括commit id（黄色内容部分），也就是指向相应提交的HASH值，这个值是唯一代表本次提交，使用这个值可以轻松回退到指定的版本。上图上还显示了本次提交的作者和日期时间以及提交的时候编辑的具体提交说明内容。
- 查看简短的提交日志
有时候并不需要查看过多的提交日志，那么可以使用命令：
git log --pretty=short
来查看简短的提交日志，如下图所示：
- 只显示指定文件或者文件夹提交日志
有时候只想查看单个文件或者指定文件夹的提交日志，可以使用命令
git log 文件名/文件夹名
来进行查看，如下图：
- 查看文件的改动内容
查看文件的具体的改动，可以添加-p参数来查看，具体命令如下：
git log -p [文件名/文件夹名]
其中方括号中的内容是可选内容，填写了就表示查看指定文件的改动。
从上图可以看出，最近一次提交相对于前一次提交，增加了一行内容主分支master第一次编写内容，且显示第一次提交是新建的文件。
git diff——查看更改前后的差别
git diff可以查看工作树、暂存区（index）、最新提交（HEAD）之间的差别，可以使用该命令实现查看自己在代码中到底修改了一些什么内容，它也是一个非常重要的常用命令。
- 查看工作树和暂存区的差别
我们在README.md文件中再添加一行内容，并将其添加到暂存区中，然后再次修改README.md文件，使用git diff命令查看工作树和暂存区之间的差别。
README.md已有的内容为：
可以在后面在再添加一行内容：主分支master第二次编写内容。然后将它添加到暂存区中，然后再次修改README.md文件，添加一行内容：主分支master第三次编写内容。这次不再添加到暂存区，使用命令查看更改前后的差别。
从上图可以看出，工作树中的README.md文件的内容相较于暂存区多了一行。我们再次将README.md文件添加到暂存区中，然后使用命令git diff进行比较，结果没有任何显示，说明工作树中的文件和暂存区中的没有差别。
- 查看工作树和最新提交的差别
使用命令git diff HEAD就可以查看工作树和最新提交的差别，紧接着上面的操作，我们将暂存区中的最新更改提交到本地仓库中，然后尝试查看工作树和最新提交的差别，结果同样是没有任何差别，这也是很容易想象的。那么我们对工作树中的README.md文件进行修改，不添加到暂存区也不提交，然后在尝试进行查看。
我们修改了工作树中的文件，而没有添加到暂存区，所以使用git diff HEAD和git diff命令都是指向了工作树与最新提交的差别。
三、分支操作
使用Git来进行代码托管，主要是为了方便团队和合作开发，并行开发。在并行开发过程中，往往存在多个分支，且各个分支的代码的进度都不一样，开发的内容也不一致，比如develop分支是开发分支，feature是新功能开发分支，master是主分支。对于分支的操作，大多都是新建分支、切换分支、合并分支等。
各个分支完全可以独立开发，等分支作业完成之后，再与主分支mater合并，共同推进项目前进。
- git branch——查看分支
使用git branch命令可以查看本地分支，如果想查看远程分支，可以在后面加上参数-a。
如上图所示，本地分支有且仅有一个master主分支，前面的*表示我们当前正在master分支上进行开发。
- git checkout -b——创建、切换分支
如果以当前分支master为基础创建新的分支，那么使用命令：
git checkout -b 新分支名称 [master]
这是一个创建分支的并切换到新分支的一个命令，后面中括号的内容可以省略，默认是以当前分支为基础，创建新的分支，其中master可以换成远程分支，这样就可以在本地以远程分支为基础创建一个新的分支。仅仅是切换分支，使用git checkout 分支名称即可。上面的创建分支的命令可以换成两行来进行：
git branch 新分支名称
git checkout 新分支名称
现在使用命令来创建新的分支：
上面的命令是创建的了新的分支并切换到了新的分支上，我们可以使用git branch命令来查看本地分支：
切换到了新的分支，可以通过git status来查看当前分支的状态，因为是基于master创建的分支，所以当前分支也有master分支对应工作树中的最新文档。
- 特性分支
特性分支一般都是为了完成某项特殊功能的分支，特性分支大多都是从主分支上新建而来，特性分支开发完成之后合并到主分支上。
- 主干分支
在实际的项目开发中，master往往担任着主干分支的职责，主干分支往往是稳定的分支，可以部署到正式的环境中。
- git merge——合并分支
我们对之前创建的新分支feature-A中添加部分内容（添加的内容不影响其他分支），然后添加到暂存区，再提交到本地仓库，最后将其合并到主分支中。合并到哪个分支，首先就需要切换到哪个分支上，我们需要切换到master分支上，然后在进行合并。
上面合并使用到的命令是git merge 被合并的分支名，但是这里推荐使用git merge --no-ff 被合并的分支名这个命令，因为后者可以将合并记录到历史中，方便后面使用给git log --graph进行查看。
如果合并完想撤销合并，只要合并后没有进行添加索引和提交，那么可以使用git checkout 文件名或者git checkout .来撤销合并，如果添加了索引，那么可以使用git rm --cached 文件名来撤销添加索引。
- git log --graph——使用图表方式进行查看日志
git log不仅可以查看提交信息，还可以查看合并等信息，加上参数--graph可以使用图标方式进行查看，在第一次合并，我们使用的是命令是git merge 被合并的分支名，这时候，使用git log --graph命令输出的结果如下图所示：
我们再次修改feature-A分支，再次合并，这次合并使用git merge --no-ff 被合并的分支名这个命令，此时在使用git log --graph命令进行查看：
可以清楚看见，分支合并的过程，这就是在合并时参数--no-ff的作用，--no-ff指的是强行关闭fast-forward方式，fast-forward方式就是当条件允许的时候，git直接把HEAD指针指向合并分支的头，完成合并。属于“快进方式”，不过这种情况如果删除分支，则会丢失分支信息。因为在这个过程中没有创建commit。
四、更改提交的操作
- git reset——会退到历史版本
更改提交操作也是常见的操作，这样可以方便我们的代码回退到某一个时间节点，对于已经提交到本地仓库的分支，如果要撤销提交或回退版本，常见的有三种方式，--mixed、--soft、--hard。那么，对于这三种方式，到底有什么区别呢？
-
git reset --mixed [commit id或者HEAD]：此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码的修改，回退掉commit和index信息。 -
git reset --soft [commit id或者HEAD]：回退到某个版本，只回退掉了commit的信息，不会恢复到index一级。如果还要提交，直接commit即可。 -
git reset --hard [commit id或者HEAD]：彻底回退到某个版本，本地的源码也会变为上一个版本的内容，此命令慎用！
最常用的是第一种默认方式，风险最小，灵活性更高，以上三种回退方式比较重要，建议牢记。
现在一起来做一个小任务，共同学习一下如何来操作历史版本，首先，我们将工作树、暂存区、最新提交都恢复到feature-A创建之前，然后再基于master分支创建一个fix-B分支，然后切换到fix-B分支并添加部分内容并提交，然后在恢复到feature-A合并之后，然后将fix-B分支合并到主分支上。所以，我们最终需要的结果是：
我们使用命令和commit id切换到指定的历史版本中，提交日志是：测试工作树和最新提交的差别，使用命令：
git reset --hard 316598977bb36a977304dacdf2a48be90f820d3c
其中HASH值是与各自的环境相关，使用命令的时候需要更改为自己的HASH值。
因为使用的--hard参数，所以工作树、暂存区、HEAD都切换到了这个历史提交版本，查看README.md内容为：
此时创建一个新的分支fix-B，并在该分支中添加部分内容并提交：
此时各分支的状态是：
我们再将分支恢复到feature-A合并后的状态，也就是如下图所示：
因为此时我们所处的状态是在feature-A与主分支master合并之前，所以要恢复到feature-A，相当于将历史版本向前推进，也就是“穿梭到未来”。由于命令git log只能查看以此时为重点的操作日志，无法查到未来的操作日志，所以我们需要使用另外一个命令来查看，git reflog命令就是我们需要的命令。
上图中黄色的内容都是HASH值的一部分（4位以上都可以直接参与执行），所以我们切换到master分支来恢复到feature-A与master合并的时刻。
我们再将fix-B分支合并到主分支master上来：
从上图可知，系统告诉我们自动合并失败了，原因是发生了冲突，需要我们自己手动解决冲突，然后提交结果。我们使用编辑器打开README.md文件，显示的内容如下所示：
=======是合并前与合并后的分界线，我们需要将文件中的内容修改成为我们需要的样子并提交修改后的结果，修改完成之后的结果是：
解决完冲突以后需要添加到暂存区后，完成提交。
- git commit - -amend——修改提交信息
当我们第一次提交代码的时候，提交信息可能是完全根据我们自己的意愿来写的，但是呢，公司往往对代码的提交信息的格式有要求，比如需要加上JIRA号等，所以我们偶尔会需要修改提交信息，那么使用命令git commit --amend就可以了。使用该命令之后，就可以修改上一次提交的信息了，进入编辑器之后就可以修改其中的信息了。
再次通过日志查看结果，提交信息成功修改了：
- git rebase -i——压缩历史
当提交完代码之后，发现代码的部分注释或者其他不太紧要的内容有些错误，大多数人的做法是撤销本次提交，再次修改后重新提交，其实还有一种比较常见的操作，那就是修改部分错误，重新提交，然后将这次提交包含到前一个提交之中，压缩成一个历史记录，这样的效果就是没有多余的提交记录，看起来就是这个小错误从来没发生过一样。这个小技巧也是很常用的小技巧，我们来测试一下。
基于master分支创建一个新的分支叫feature-C，然后在其中添加一些内容，并认为制造一些单词拼写错误在里面，方便后面修改。
上图中README.md文件最后一行的第一个单词拼写错误，但是我们使用命令git commit -am "创建feature-C分支"进行了一次性的添加索引和提交。
对于上面制造出来的错误，我们在本次进行修改并提交：
由于这个分支进行了两次提交，所以在历史记录中就有两次提交的记录，但是对于第二次提交，健全的历史记录并不需要他们，所以我们希望将这两次提交历史合并成为一次历史，那么使用Git的相关命令轻松可以做到。首先我们查看两次提交的历史记录：
我们使用命令git rebase -i HEAD~2来将两次提交合并，键入命令之后，会打开编辑器，我们将第二次提交的记录前面的pick改成fixup即可，就完成了两次提交记录的合并，后面可以通过查看日志来确认一下。
修改完成之后，就会出现最后一行的温馨提示：
我们再次查看日志：
发现两次提交成功合并成为一次提交了，且这次提交的commit id也不和之前的都一样了。最后我们切换到master分支将feature-C合并上来。
五、推送至远程仓库
以上的操作都是在本地操作的，作为分布型版本管理系统，我们需要将本地仓库的代码推送到远程仓库，方便其他成员协同开发，这里采用的远程仓库是国产代码托管平台码云，至于其他平台，如全球著名的“同性交友网站”——GitHub，操作方法和原理都是一致的。
我们在码云上建立一个公有仓库，由于我们本次示例都是使用的README.md文件，所以在建立仓库的时候，仓库名称需要和本地一致，且不需要使用README.md文件来记录远程仓库的信息，假设读者已经建立好了仓库，且仓库名称和本地仓库名称一致。接下来我们将设置远程仓库中。
git remote add origin [email protected]:itlemon/git-test.git
其中，[email protected]:itlemon/git-test.git来自码云上我们建立的公共仓库，如下图所示：
使用上面的命令之后，Git会自动将[email protected]:itlemon/git-test.git远程仓库的名称设置为origin（标识符）。那么我们下次推送或者切换到远程分支的时候加上origin标识符就相当于告诉Git，我们要推送到远程仓库或从远程仓库切分支到本地仓库。
接下来，我们将README.md文件推送至远程仓库，使用命令：
git push -u origin master
在第一次推送的时候，可能会遇见各种问题，比如没有权限推送、远程仓库和本地仓库有冲突等等，对于没有权限推送，多数是因为没有创建公钥，那么我们需要在本地Git仓库创建公钥，然后将它设置到码云上，对于第一次推送有冲突，那么可以在上面的命令中添加一个参数-f来强制推送即可（后期不建议使用强制推送，因为会覆盖远程仓库）。上述命令中-u参数是将origin master分支设置为本地master分支的上游（upstream），这样方便以后拉取代码直接使用命令git push，而无需使用git push origin master，最后推送的效果是：
从上图可以看出，本地的11次提交在远程仓库也可以进行查看，如下图所示：
六、从远程仓库获取
对于新入职的员工来说，安装完Git，配置完权限，第一步基本都是被告知需要自己将代码从远程仓库克隆下来，那么如何克隆，那么我们需要使用命令：
git clone git@gitee.com:itlemon/git-test.git
使用git clone命令之后，我们在本地就建立了一个本地仓库，默认处于master分支，那么我们可以灵活查看远程仓库的各个分支，使用命令：
git branch -a
也就是相较于查看本地分支列表，多了一个参数-a，假设我们远程有一个feature-D分支，那么怎么把它从远程仓库切到本地？第一次切换和创建本地分支命令一致，例如：
git checkout -b feature-D origin/feature-D
The first feature-Dbranch synchronized to the local, we need to build a new branch to carry it, usually named and consistent remote branches. For subsequent pulling code directly git pullto, you can be the latest remote feature-Dcode on a local branch to pull. If conflict occurs, you need to manually resolve the conflict and submit a branch of the push to remote branches, always keep the remote repository branch is the latest.
Sometimes we can not pull from a new branch of code down, or use the git branch -acommand can not obtain a new branch in the remote just created, it is mostly because the remote branch list of local cache is not updated, this time about the need to update the list of remote branch:
git remote update origin --prune
Which originis remote repository identifier, if your remote repository identifier is not origin, need to change their identifiers, are usually the default origin.
Armed with more commonly used commands, basically you can handle most of the work, as to the actual development process, we might rarely used command, but I personally think, skilled use of the command will help you understand in IntelliJ IDEA various operating code versions. Above basically an introduction to git common commands, and using graphic demonstration of the way, step by step, hoping to help the reader. Next, I will continue out of a combination of IntelliJ IDEA to use Git articles, using its graphical interface to demonstrate how to use Git to efficiently develop and colleagues, and I hope to help newcomers quickly integrate into the company as a team.
More dry goods share, welcome attention to my micro-channel public number: Java Mountain (Micro Signal: itlemon)
