Git快速入门

1.Git介绍

Git的作者是Linux的创作者Linus。

Git是版本管理工具，可以记录所有文件的所有版本，可以有效追踪文件变化，同时可以支持回滚到之前的状态。

• Git与github的关系

Git是在本地使用的一个版本管理工具，其作用就是可以让你更好的管理你的本地程序。

github是一个网站，开发者可以在github上建立远程仓库，将本地的git仓库上传到github远程仓库，与其他开发者协作。

没有github的情况下，Git也可以在本地进行版本管理。Git与Github之间关系类似客户端与服务端之间的关系。

2.Git安装

Git支持Linux、windows和macos等平台，支持命令行和GUI两种使用方式，本文档主要讲解windows下Bash使用方式。

• 命令行方式

第一步：下载，网址https://git-scm.com/download/win

第二步：默认完成安装即可

第三步：登录git bash，配置用户信息，针对本机所有仓库，（与github账号关系？无关，作用于本地仓库，github还是以账号为主）

设置用户名
git config --global user.name “***”

设置邮箱
git config --global user.email “***@qq.com”

查看配置是否生效
git config --list

• GUI方式

可以选择SourceTree，下载地址https://www.sourcetreeapp.com/，默认安装即可，本文档不做讲解。

3.Git本地仓库

Git本地仓库（repository）可以认为是一个被git管理的本地文件夹。

常用命令如下：

初始化版本库
git init

代码从工作区提交到暂存区
git add .

代码从暂存区到版本库：
git commit -m "***"

查看仓库状态
git status

查看log
git log

查看某次commit修改
git show commitId

使用示例：

 

4.Git工作流

Git在本地分为工作区、暂存区和版本区，图中index为暂存区，master为版本区。

• 情况一：正常的修改提交流程

第一步：修改代码
第二步：提交代码从工作区到暂存区
git add .
第三步：提交代码从暂存区到版本区
git commit -m "***"

• 情况二：工作区进行了修改，还没提交到暂存区，取消本次修改

放弃单个文件修改,注意不要忘记中间的"--",不写就成了检出分支了!
git checkout -- filepathname

放弃当前文件夹下所有文件修改
git checkout .  

• 情况三：在工作区修改后提交到暂存区，取消本次修改

第一步：从从版本区到暂存区回滚
*针对单个文件
git reset HEAD -- filename
*针对当前目录下所有文件
git reset HEAD .

第二步：从暂存区到工作区回滚
git checkout .

• 情况四：修改已提交到版本区，取消本次修改

查看commit版本号
git log

回滚到指定版本号，hard表示将暂存区、版本区和工作区都回退
git reset --hard 版本号

• 情况五：删除某个文件

第一步：删除文件
git rm 文件名
第二步：提交删除修改
git commit -m "***"
-----------或者，跟正常提交一样----------

第一步：在工作区删除
第二步：提交到暂存区
git add .
第三步：提交到版本区
git commit -m "***"

5.远程仓库

以下介绍如何使用github，主要介绍创建SSH KEY、添加远程仓库、克隆仓库三个功能。

• 创建SSH KEY

本地与github仓库使用ssh协议传输，所以需要创建ssh key。

第一步：在github网站上，点击右上角settings，点击SSH and GPG keys，再点击new sshkey

第二步：在本地，使用git bash执行命令，生成SSH KEY

邮箱一定是github注册邮箱，生成的sshkey文件在个人用户目录下。

 

第三步：将以上本地生成的SSH KEY填写到github网站上

第四步：在本地执行命令，测试本地与github是否通

 

• 添加远程仓库

在github新创建一个仓库后，想将本地已有代码推上来，有两种情况。

第一种：创建新的本地仓库，将这个新创建的本地仓库推到远程仓库。

初始化本地仓库
git init

提交文件到暂存区
git add README.md

提交文件到版本区
git commit -m "first commit"

将本地仓库与远程仓库进行关联，origin是远程的意思
git remote add origin [email protected]:houpk999/git_demo.git

将本地仓库push到远程仓库的master分支，-u表示默认push到rogin master
git push -u origin master

第二种：将本地已有仓库推上来

将本地仓库与远程仓库进行关联，origin是远程的意思
git remote add origin [email protected]:houpk999/git_demo.git

将本地仓库push到远程仓库的master分支，-u表示默认push到rogin master
git push -u origin master

• 克隆仓库

当远程仓库已存在代码的情况下，本地没有代码，需要将远程仓库的代码克隆到本地，然后在本地开发，完成后再传输到远程仓库。

在一个空白文件夹下执行：

#远程仓库克隆到本地，如不指定分支，默认为master分支
git clone [email protected]:houpk999/git_demo.git

#指定分支
git clone -b 分支名 [email protected]:houpk999/git_demo.git

• pull和push

当远程仓库有多个分支时，本地仓库也需要建立多个分支与之对应，可以使用pull和push命令。

#将远程指定分支 拉取到 本地指定分支上
git pull origin <远程分支名>:<本地分支名>

#将远程指定分支 拉取到 本地当前分支上
git pull origin <远程分支名>

#将本地当前分支 推送到 远程指定分支上（注意：pull是远程在前本地在后，push相反）
git push origin <本地分支名>:<远程分支名>

#将本地当前分支 推送到 与本地当前分支同名的远程分支上（注意：pull是远程在前本地在后，push相反）
git push origin <本地分支名>

6.标签管理

当发布版本的时候，会打一个标签，当需要版本回滚时，根据标签回滚即可，而非使用branch和commit记录来回滚。

标签使用简单，主要是增删改查命令，如下：

查看所有标签
git tag

创建标签：
git tag tagname

指定提交标签的信息 
git tag -a tagname -m “comment”

切换到指定的标签
git checkout tagname

删除标签：
git tag -d tagname

标签发布到远程仓库：
git push orgin tagname

案例如下：

此时，到github上branch的Tags可以看到标签。

删除标签，使用如下命令：

 

7.分支管理

• 分支用途

分支的用途主要有两个方面：

第一种：比如说一个项目现在是1.0版，那么开发团队可能要同时进行1.1版和2.0版的开发，这样代码就会出现较大分歧，这时候就需要用到分支了，不同的任务组在不同的分支上开发，互相之间不会影响；

第二种：再比如说，需要向项目中添加一个新功能，一般的团队都不会直接在主分支上修改，都会新建一个分支，在上面更改代码。这样做的好处就是保证主线代码的完整性和可用性，也就是说，主线上都是稳定的代码，可以直接拿来发布的。

下面以新功能开发为例，举例分支的使用。

>>Master: 主分支；主要是稳定的版本分支，正式发布的版本都从Master拉。
>>Develop: 开发分支；更新和变动最频繁的分支，正常情况下开发都是在Develop分支上进行的。
>>Release：预发行分支；一般来说，代表一个版本的功能全部开发完成后递交测试，测试出Bug后进行修复的分支。
>>Features: 功能分支； 其实Features不是一个分支，而是一个分支文件夹。里面包含了每个程序员开发的功能点。Feature开发完成后合入Develop分支。
>>HotFix: 最希望不会被创建的分支；这个分支的存在是在已经正式上线的版本中，发现了重大Bug进行修复的分支

第一步：软件版本的起点：A
  上一次产品经理需求0.1的软件版本刚刚完成后，这不又来了新的版本需求0.2，这次一共两个功能点。幸好我们有Git，让并行开发成为可能。拉取Develop分支准备开干！

第二步：开发的起点：B
  两名工程师，两个不同的需求，大师甲和大师乙各自领取一个功能点开干；从Develop拉取属于自己的分支，有单独的分支就不会被干扰；

第三步：开发的终点：H
  一周不到，两位大师就已经完成了属于自己的功能；从图上看，都有两次代码的提交。大师们各自开发的功能初步看似乎没有啥问题，但是我们的App版本是一个多功能的集合，是否合在一起也会没有问题？这时候大师们把属于自己的分支合入Develop，并删掉自己的工作Branche。编译，运行，Success!

第四步：预发行的起点：Release 0.2 节点(I)
  大师们的能力果然与众不同，合入后没有一点问题，达到提交测试部的标准。新建Release 0.2 分支，代表一个里程碑式的事件。

第五步：Release 分支Bug宿命
  世上没有哪个大师的代码是没有Bug的，大师甲和大师乙也不例外。这不，测试部刚拿到预发行的版本就曝出了2个Bug。
  不过没有关系，能够复现的Bug对于我们来说就不是Bug。从Release 0.2拉取Bug修复分支。修好了，继续合进Release 0.2。谁叫Release就是这样的宿命呢。

第六步：版本发行的终点: M
  经过大师们艰苦卓绝的bug修复，终于通过了测试部的测试，也得到了产品经理们的认可，准备提交App Store审核。
  Release合入Master分支，打上Tag 0.2，这就是这次的MileStone了。
  当然也得记得Release合入Develop，之前这么多的bug也得在Develop上修复修复不是。做好了这些，Release就可以删啦。

第七步：救火队员一般的HotFix: N
  好事多磨！AppStore刚发出去的App, 就有用户反馈Crash! 大师甲和大师乙临危受命!
  从Master拉取HotFix分支来搞定它。原来是数组越界！分分钟搞定。完成后合入Master，版本更新为Tag 0.3，代表我们修复了重大问题。编译，运行，没问题，提交App Store等审核。
  噢，one more thing, HotFix 也要合入Develop，又多了一个功能点（bug修复）不是。

第八步：新的轮回开始：P
  1-> 7就是一个版本的开发过程中，我们的Git Flow流。到了最后，P和O节点拥有了相同的内容，就像在一开始的A和B那样

• 分支使用

分支使用主要有以下命令：

查看分支列表
git branch

创建分支
git branch branchname

切换分支
git checkout branchname

删除分支
git branch -d branchname

将指定分支branchname的修改合入当前分支
git merge branchname

课程链接http://www.imooc.com/learn/1052