Git的入门|安装|常用命令|分支使用

GIT

概念

官网地址: https://git-scm.com/
Git是一个开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。
Git 是 Linus Torvalds(Linus花了两周时间自己用C写了一个分布式版本控制系统，这就是Git！一个月之内，Linux系统的源码已经由Git管理了！牛是怎么定义的呢？大家可以体会一下。) 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。
Git 与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持.

一个很形象的比喻大家可以看一下:
Git是什么？
Git是目前世界上最先进的分布式版本控制系统（没有之一）。
Git有什么特点？简单来说就是：高端大气上档次！
那什么是版本控制系统？
如果你用Microsoft Word写过长篇大论，那你一定有这样的经历：
想删除一个段落，又怕将来想恢复找不回来怎么办？有办法，先把当前文件“另存为……”一个新的Word文件，再接着改，改到一定程度，再“另存为……”一个新文件，这样一直改下去，最后你的Word文档变成了这样：

过了一周，你想找回被删除的文字，但是已经记不清删除前保存在哪个文件里了，只好一个一个文件去找，真麻烦。看着一堆乱七八糟的文件，想保留最新的一个，然后把其他的删掉，又怕哪天会用上，还不敢删，真郁闷。更要命的是，有些部分需要你的财务同事帮助填写，于是你把文件Copy到U盘里给她（也可能通过Email发送一份给她），然后，你继续修改Word文件。一天后，同事再把Word文件传给你，此时，你必须想想，发给她之后到你收到她的文件期间，你作了哪些改动，得把你的改动和她的部分合并，真困难。于是你想，如果有一个软件，不但能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以，岂不是很方便？

这样，你就结束了手动管理多个“版本”的史前时代，进入到版本控制的20世纪.

GIT和SVN的区别

• GIT是分布式的，SVN不是：这是GIT和其它非分布式的版本控制系统，例如SVN，CVS等，最核心的区别。
• GIT把内容按元数据方式存储，而SVN是按文件：所有的资源控制系统都是把文件的元信息隐藏在一个类似.svn,.cvs等的文件夹里。
• GIT分支和SVN的分支不同：分支在SVN中一点不特别，就是版本库中的另外的一个目录。
• GIT没有一个全局的版本号，而SVN有：目前为止这是跟SVN相比GIT缺少的最大的一个特征。
• GIT的内容完整性要优于SVN：GIT的内容存储使用的是SHA-1哈希算法。这能确保代码内容的完整性，确保在遇到磁盘故障和网络问题时降低对版本库的破坏。

GIT的工作流程

一般工作流程如下:

• 克隆 Git 资源作为工作目录。
• 在克隆的资源上添加或修改文件。
• 如果其他人修改了，你可以更新资源。
• 在提交前查看修改。
• 提交修改。
• 在修改完成后，如果发现错误，可以撤回提交并再次修改并提交。

GIT几个重要概念

• 工作区：就是你在电脑里能看到的目录。
• 暂存区：英文叫stage, 或index。一般存放在 “.git目录下” 下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。
• 版本库：工作区有一个隐藏目录**.git**，这个不算工作区，而是Git的版本库。

简单来说这几个工作区就组成了git的工作流.
你的本地仓库由 git 维护的三棵“树”组成。第一个是你的** 工作区**，它持有实际文件；第二个是 暂存区（Index），它像个缓存区域，临时保存你的改动；最后是** HEAD**，它指向你最后一次提交的结果。

GIT安装配置

安装

安装教程很多,这里就不细说了,推荐一个安装教程:
http://www.runoob.com/git/git-install-setup.html

配置

| git config --global user.name “你的名字或昵称”

git config --global user.email “你的邮箱”

作为 git 的基础配置，作用是告诉 git 你是谁，你输入的信息将出现在你创建的提交中。打开终端（Windows打开安装git时安装的git bash）执行如下命令

连接服务器

我们以连接码云为例讲解.因为国内基本都连接码云,速度比较快,介于GitHub已经被微软搞定,我们就不讲解连接GitHub了,流程基本一致.
码云官网: https://gitee.com/
自行注册账号.
码云的参考文档: http://git.mydoc.io/
连接码云的官方文档: http://git.mydoc.io/?t=180845

GIT常用基本命令

创建新仓库

在电脑任意位置创建新文件夹，打开，然后执行 git init
以创建新的 git 仓库。

检测状态

利用命令: git status

添加和提交

添加

使用命令:git add filename 或者 **git add * **你可以提出更改（把它们添加到暂存区）

检测状态:

接着使用工具:

提交

由于刚刚的添加只是添加到暂存区,那么还没有实际的提交到版本库head,所以我们需要提交到版本库:**git commit -m **“提交的解释说明信息”

推送到远端仓库

由于刚刚commit的只是保存在了本地的仓库,为了和别人交换代码,我们需要提交代码到远端仓库.
远端仓库在什么地方? 就是我们前面介绍的码云.
首先确保你已经做了 “连接服务器的步骤”,然后我们在码云上创建一个项目.
官网参考地址: http://git.mydoc.io/?t=180676
按照官方文档创建即可.
创建好远端仓库之后复制远端仓库地址:

然后在git bash中使用命名:
git remote add origin <远端仓库地址>

再使用推送命令:
git push origin master

这是查看远端仓库:

注意:
如果在执行 git push orgin master的时候报错:

解决步骤:
先执行: git pull origin master –allow-unrelated-histories
再执行:git pull origin master(类似svn的update)
再执行:git push origin master
名词说明:
origin : 远端仓库的别名
master : 远端仓库的主分支

克隆

上面的操作是建立在本地仓库和远程仓库之间建立联系并推送和更新.
如果我们本来有远程仓库,那么可以直接克隆远程仓库.
新建一个test2目录:

直接执行命令: git clone 远程仓库地址

在查看test2目录:

然后就可以正常操作了,更新,提交代码了

总结基本常用命令

初始化仓库------------ --------git init
查看状态-----------------------git status
添加文件到暂存区---------------git add */finleName/.
将暂存区的文件提交到本地仓库—git commit -m “提示信息”
将本地仓库和远端仓库建立联系—git remote add origin 远端仓库地址
远程拉取(更新)代码--------------git pull orgin master
同步本地仓库和远端仓库---------git push origin master
克隆远程仓库-------------------git clone 远端仓库地址

GIT设置忽略文件

设置忽略文件就是将不想添加到版本库中的文件直接忽略掉.

.gitignore

直接在项目目录下创建.gitignore文件

将不想添加到版本库中的文件名直接添加到.gitignore中,当然没有必要完全自己去写.
GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore
比如我们现在添加一个java常用忽略文件:

我们测试一下,在项目目录中添加一个error.log:


发现*.log已经被忽略了.

强制添加忽略文件

如果我们现在想把info.log提交到仓库怎么办? 改动.gitignore文件? 这样肯定不可取,git没有这么傻,我们只需要 -f 参数即可.
如:

GIT版本回退

在实际开发过程中难免会遇到一些突发情况(此处省略一万字),那么我们很可能需要回到一个指定的版本,这个时候就需要用到版本回退功能了.
首先我们准备一个文件version.txt

内容:

提交到仓库!
我们更改三次内容,让版本升级到3.0
版本2:

版本3:

那么问题来了,我现在觉得还是版本2.0好,要回退怎么办? Git怎么去找到2.0的版本?

git log

通过git log 我们可以查看提交的信息:

当然也可以在码云上查看.
进入正题,如何回到版本2.0?

git reset

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交5f431da…（注意我的提交ID和你的肯定不一样），那么上一个版本就是HEAD^{**，上上一个版本就是**HEAD**，当然往上100个版本写100个}比较容易数不过来，所以写成HEAD~100**。
执行命令: git reset –hard HEAD^

见证奇迹的时刻到来:

内容真的变成了2.0.
当然我们还可以继续回退到版本1.0都是可以的.

时光穿梭

我现在觉得还是3.0的版本比较好,怎么办?穿越未来?可能吗?
一句话:可以
但前提是你的窗口没有关闭,那么你可以找到3.0版本的唯一id: 5f431da…
直接执行命令:

看版本回到了3.0,就是这么任性.
注意:版本ID不用写全,写前面六七位就可以了.

总结

Git的版本回退速度非常快，因为Git在内部有个指向当前版本的HEAD指针，当你回退版本的时候，Git仅仅是把HEAD从指向 不同的版本罢了.

我如果回退到2.0:

然后顺便把工作区的文件更新了。所以你让HEAD指向哪个版本号，你就把当前版本定位在哪。
所以:

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。
• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。
• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。(自己去尝试)

GIT管理修改

管理修改

我们前面已经说了暂存区的概念,那么为什么Git比其他版本控制系统设计得优秀，因为Git跟踪并管理的是修改，而非文件。你会问，什么是修改？比如你新增了一行，这就是一个修改，删除了一行，也是一个修改，更改了某些字符，也是一个修改，删了一些又加了一些，也是一个修改，甚至创建一个新文件，也算一个修改。
经过前面的实践我们其实已经得到了一个结论:
每次修改，如果不用git add到暂存区，那就不会加入到commit中。

撤销修改

我们在日常开发中,经常会有这样的一种情况:
我们在一个版本中修改了代码,但是猛然的发现做的这些修改都是徒劳的(千万只草泥马飘过…),怎么办?
处理这个问题很简单: 把修改的部分删除掉不就完了吗,但是当你使用git status的时候你就会发现不是想的那么简单,我们来演示一下:
首先有一个文件UserController.java

我们对这个文件进行修改:条件了一个方法

但是我现在后悔了(好像确实有后悔药…),没关系,删掉

利用git status 查看状态:你会发现你是多么的too yong too simple…

你会发现git 还是记录了你的修改,怎么办?我们细心的会发现git 给了我们两个提示:
一个是让我们提交到暂存区
另一个……………
git checkout – filename
没错我们要的就是这个. 这条命令的意思就是把fileName文件在工作区的修改全部撤销
这里一般会有两种情况:
一种是fileName自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态；
一种是fileName已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。
总之，就是让这个文件回到最近一次git commit或git add时的状态。

第一种情况

那我们试着做一下:

发现文件真的已经回到了之前的版本.

第二种情况

上面第一种情况很简单,要是我们已经提交修改到了暂存区,如果只是做上面的操作肯定不能回到之前的状态,那么还需要利用:
**git reset HEAD **可以把暂存区的修改撤销掉（unstage），重新放回工作区,这个就大家自己尝试一下.

总结

场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout – file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD ，就回到了场景1，第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节。

GIT删除文件

删除文件在日常开发中是很常见的操作
比如我们现在在工作区把UserController.Java删除掉
利用git status 查看:

现在有两个操作选择:
一,直接git rm filename 删除掉 然后再提交 (正常删除)
二,直接git checkout – filename恢复到原来的版本(失误删除)

失误删除操作

发现误删除的文件又回来了, git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

正常删除操作

我们可以直接使用 git rm file删除并提交
也可以git add file 并提交都是ok的
自行尝试.

GIT分支

Git强大之一就是他的分支.什么是分支?
分支是用来将特性开发绝缘开来的。在你创建仓库的时候，master 是“默认的”分支。在其他分支上进行开发，完成后再将它们合并到主分支上。

分支的创建与合并

• 查看分支：git branch
• 创建分支：git branch
• 切换分支：git checkout
• 创建+切换分支：git checkout -b
• 合并某分支到当前分支：git merge
• 删除分支：git branch -d

查看分支

创建分支

我们看到git branch 列出来的分支就有两个了,前面有*的表示是当前分支.

切换分支

将分支切换到 dev

创建并切换分支

合并分支

在dev上开发一点新的东西,然后提交到版本库.
切换回master分支

注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

删除分支

合并完成后就可以删除dev分支了

合并冲突的解决方法

什么情况会出现冲突?
在不同的分支上改动了相同的文件,git就懵逼了,不知道该用怎么合并
解决方案:
当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。
用git log --graph命令可以看到分支合并图。

分支管理策略

合并分支的模式

fast forward
这种模式删除分支后，会丢掉分支信息。
合并前:

合并后:

删除分支后:

加上–no-ff
加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
所以，团队合作的分支看起来就像这样：

Bug分支

软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
但是我们在接到修改bug的通知之后我们手里面的工作还没完成怎么办?为了当前工作不被污染,我们必须要将现有的工作保存起来(冻结),等bug修复完成后再启用.
演示一下:
现在在dev分支上创建了两个新文件:

现在接到bug修复通知,手上的工作必须”冻结起来”以免被污染:
命令:git stash

注意: 在git stash之前必须先git add .
现在切回主分支 进行bug修复:

接下来继续回到dev进行开发:

feature分支

软件开发中，总有无穷无尽的新的功能要不断添加进来。添加一个新功能时，你肯定不希望因为一些实验性质的代码，把主分支搞乱了，所以，每添加一个新功能，最好新建一个feature分支，在上面开发，完成后，合并，最后，删除该feature分支。
如果要丢弃一个没有被合并过的分支，可以通过git branch -D 强行删除。

GIT多人协作

分支的推送

• master分支是主分支，因此要时刻与远程同步；
• dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
• bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
• feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

分支的抓取

抓取远程的dev分支

注意如果此时改动origin/dev分支是提交不了的,因为本地没有dev分支,所以我们必须先在本地创建一个dev分支,然后git pull 拉取,再git push 就可以了

总结

• 查看远程库信息，使用git remote -v；
• 本地新建的分支如果不推送到远程，对其他人就是不可见的；
• 从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
• 在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；
• 建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；
• 从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。

GIT-FLOW