使用git和github管理自己的项目

我是通过看廖雪峰的git教程学习的,真的是极好的,以下是我学习过程中的总结,记录下来,方便自己参考以熟悉git和github的使用。

除了廖雪峰的教程,还比较推荐在看完廖雪峰的教程之后,再看这样一篇文章:使用git和github进行协同开发流程,和我的另一篇git的笔记:使用git和github管理自己的项目—真实开发环境的策略 ,深入了解github和git怎么在具体的项目开发中管理项目、有什么好的规范!

我这里记录git的学习笔记,方便随时参考,具体的git的原理github的原理集中式和分布式版本控制的区别版本控制的概念和原理Git和其他版本控制工具比如SVN的区别、以及更多的相关概念讲解,请自己参见廖雪峰的git教程

我强烈推荐先看廖雪峰的git教程来系统化认识和学习git,然后自己整理一份具体的步骤方便平时开发时快速参考,或者直接参考我的。

先说一个比较好笑的事:廖雪峰的git教程中,刚开始的部分的浏览量有38万,但是最后一页教程的网页的浏览量是1万多。

以前因为觉得git、github比较难,所以一直拖着不学,现在去尝试学习,一晚上就OK了

  • 重点之一是找到全面的、详细的、生动的、高质量的教程。廖雪峰的git教程是我目前找到的最好的一个。之前找到的讲解git用法的书《pro git》现在看来是没有必要再看了!
  • 重点之二就是自己立即去学,其实没什么难的,不要被貌似难的表象、概念唬住。
  • 重点之三是最好能自己做简单的、系统的整理,方便自己随时再回来查看、复习、参考,不至于出现这样的情况:学完以后过一段时间之后再用,但是这时候发现忘了差不多了!
  • 重点之四就是立即动手去用,否则学完很快就忘了。

有钱的买mac,没钱的用ubuntu–或者其他的linux发行版、被逼无奈的用Windows–但是被逼之余的自主时间一定要远离Windows。

现在我的测试环境是ubuntu。

以对一个文件的管理为例,简单说明git的使用。另外需要说明的是下面的实验过程主要是只针对一个文件、并且修改的次数往往只有一次,而在真正的项目中,往往有大量的文件,也可能多次修改后才合并,合并时候的冲突可能也不只一两个,等等。不过原理都是一样的,我想说的是,不要局限在这个教程的示例上,请自己通过教程掌握基本的远原理之后,自己推广、去大量的实践,最重要的是要制定一个好的版本控制的策略(合理分工、安排,还是尽可能的避免冲突为好),这个可以参考:使用git和github进行协同开发流程以及我的学习笔记使用git和github管理自己的项目—真实开发环境的策略

1.创建版本库

  • sudo apt-get install git 先安装git
  • 先创建目录,作为仓库
  • git init 初始化仓库,可以发现当前目录下多了一个.git的目录,这个目录是Git来跟踪管理版本库的,没事千万不要手动修改这个目录里面的文件,不然改乱了,就把Git仓库给破坏了
  • vim readme.txt 新建一个文本文件,比如往里面添加简单的一行字符串
  • git add readme.txt 添加一个文件,比如readme.txt,如果目录里面的所有文件都要添加,可以git add *
  • git commit-m "添加一个readme.txt文件" 将文件提交到仓库,并加上说明(这时候是版本1)
  • 如果是第一次使用git,那么git commit可能报错,所以需要你配置一些个人信息
  • git config --global user.email "you@example.com" 配置邮件
  • git config --global user.name "Your Name" 配置用户名
  • 必须配置,否则后面的commit、push到远程库都会失败
  • 然后再次git commit -m "添加一个readme.txt文件" 才会成功

2.提交修改

  • 假如此时第一次修改了readme.txt文件
  • git status 让我们时刻掌握仓库当前的状态。这时告诉我们,readme.txt被修改过了,但还没有准备提交的修改。
  • git diff readme.txt 查看对readme.txt做了什么修改
  • git add readme.txt 提交修改和提交新文件是一样,先git add
  • git status 可以再用git status查看仓库的当前状态,告诉我们,将要被提交的修改包括readme.txt
  • git commit-m "第一次修改" 然后再git commit,并添加修改的描述(这时候是版本2)
  • git status 可以再执行git status看仓库状态,因为所有的都提交了,Git告诉我们当前没有需要提交的修改,而且,工作目录是干净(working directory clean)的。

3.版本回退

  • 你可以像上面所说的那样不停的提交新的文件、提交对文件的修改
  • 这时候第二次修改readme.txt文件
  • git add readme.txt 先git add
  • git commit -m "第二次修改" 提交第二次修改(这时候是版本3)
  • git log 显示从最近到最远的提交日志,具体显示的内容自己试一试看看
  • git log --pretty=oneline 如果嫌输出信息太多,看得眼花缭乱,试试加上–pretty=oneline参数
  • 这篇教程去理解为什么Git的版本号要这么长,Git的版本号类似:3628164fb26d48395383f8f31179f24e0882e1e0 这样的特别长的十六进制数。
  • git reset --hard HEAD^ 会回退到上一个版本,也就是从版本3回退到版本2
  • 在Git中,用HEAD表示当前版本,也就是最新的提交3628164…882e1e0(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
  • vim readme.txt 可以看到此时的readme.txt文件就是版本2时候的内容,回退成功!
  • git log 此时看到版本3的信息没有了
  • git reset --hard 3628164 通过命令行上的历史信息(假如你没清屏的话),找到版本3 的版本号,不一定要全部的版本号,就像这个命令的例子,只要前面的约7、8位这样就可以指定回到版本3
  • vim readme.txt 看到的是第三版本的readme.txt文件的内容,所以又回来了
  • Git的版本回退速度非常快,因为Git在内部有个指向当前版本的HEAD指针,当你回退版本的时候,Git仅仅是把HEAD从指向你要回退的那个版本
  • git reflog 记录你的每一次命令,最先显示的是这个命令执行之后的版本的版本号的前七位,这样就算你清屏了或者重启了,也能找到某个版本的版本号,就可以轻松回退到那个版本

4.工作区、版本库和暂存区

工作区:就是你在电脑里能看到的目录,比如我的learngit文件夹就是一个工作区。

版本库:工作区有一个隐藏目录.git,这个不算工作区,而是Git的版本库。

暂存区:Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master,以及指向master的一个指针叫HEAD。

前面讲了我们把文件往Git版本库里添加的时候,是分两步执行的:

  1. 第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;
  2. 第二步是用git commit提交更改,实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时,Git自动为我们创建了唯一一个master分支,所以,现在,git commit就是往master分支上提交更改。

你可以简单理解为,需要提交的文件修改通通放到暂存区,然后,一次性提交暂存区的所有修改。

详细知识见这篇教程。必须理解暂存区、工作区、版本库。这些都是是Git非常重要的概念,弄明白了这些概念,就弄明白了Git的很多操作到底干了什么。没弄明白的话,请反复看!!

5.管理修改

为什么Git比其他版本控制系统设计得优秀,因为Git跟踪并管理的是修改,而非文件。

什么是修改?比如你新增了一行,这就是一个修改,删除了一行,也是一个修改,更改了某些字符,也是一个修改,删了一些又加了一些,也是一个修改,甚至创建一个新文件,也算一个修改。

通过实例讲解什么叫跟踪修改,要想理解,请参考原文结合暂存区的知识理解:

  • vim readme.txt 编辑文件,比如添加新的一行
  • git add readme.txt 添加,但是不提交
  • vim readme.txt 再编辑文件,比如再添加一行
  • git commit -m "修改两次,添一次,提交一次" 提交
  • git status 看到的效果是:只提交了第一次的修改,第二次的修改没有提交

那怎么提交第二次修改呢?你可以继续git addgit commit,也可以别着急提交第一次修改,先git add第二次修改,再git commit,也就是第一次修改 -> git add -> 第二次修改 -> git add -> git commit,就相当于把两次修改合并后一块提交了。

6.撤销修改

第一种情况

  • 修改了readme.txt文件,还没有git add 和git commit
  • 但是在你提交之前发现这次修改有问题。既然错误发现得很及时,就可以很容易地纠正它。你可以手动把文件恢复到上一个版本的状态。
  • git checkout -- readme.txt 也可以通过命令撤销修改,这条命令的意思就是,把readme.txt文件在工作区的修改全部撤销
  • 无论是文件修改后值存在于工作区还没有放到暂存区,还是已经添加到暂存区,总之这个命令就是让这个文件回到最近一次git commit或git add时的状态。
  • 查看文件,内容果然复原了。git checkout — file命令中的--很重要,没有--,就变成了“切换到另一个分支”的命令,我们在后面的分支管理中会再次遇到git checkout命令。

第二种情况

  • 修改了readme.txt文件,而且执行了git add readme.txt
  • 庆幸的是你在 git commit 之前发现了这个问题
  • git status 查看一下,修改只是添加到了暂存区,还没有提交
  • git reset HEAD readme.txt 可以把暂存区的修改撤销掉,重新放回工作区。git reset命令既可以回退版本,也可以把暂存区的修改回退到工作区。当我们用HEAD时,表示最新的版本。
  • git status 查看一下,现在暂存区是干净的,工作区有修改
  • git checkout -- readme.txt 还记得第一种情况中如何丢弃工作区的修改吧

第三种情况

现在,假设你不但改错了东西,还从暂存区提交到了版本库,怎么办呢?还记得版本回退一节吗?可以回退到上一个版本。不过,这是有条件的,就是你还没有把自己的本地版本库推送到远程。

还记得Git是分布式版本控制系统吗?我们后面会讲到远程版本库,一旦你把错误的修改(如果是影响很大的错误)提交推送到远程版本库,你就真的惨了……

区别对待本地版本库和远程版本库!

7.删除文件

在Git中,删除也是一个修改操作

  • 添加一个新的文件 test.txt
  • git add test.txt
  • git commit test.txt -m "再次新增一个文件"
  • 一般情况下,你通常会在文件管理器中把没用的文件删除,或者直接rm test.txt
  • git status 这个时候,Git知道你删除了文件,因此,工作区和版本库就不一致了,git status命令会立刻告诉你哪些文件被删除了
  • 现在你有两个选择,一是确实从版本库中删除该文件,那就git rm test.txt,然后git commit 文件就从版本库中删除了
  • 另一种情况是删除错了,因为版本库里还有,所以可以轻松地将误删除的文件恢复到最新版本git checkout -- test.txt git checkout其实使用版本库中的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”

8.添加远程库

要想学习这部分的知识,请先参考下面的:a.配置连接远程仓库Github

  • 假如现在你已经配置好github,并且在github上添加了learngit仓库。
  • git remote add origin git@github.com:michaelliao/learngit.git 这个命令是在本地的learngit仓库下执行的,前面通过learngit仓库为例我们已经讲过在本地创建和操作git仓库。这两个地方的仓库名不需要相同,因为会通过在本地的仓库目录下执行这条命令(命令中包含远程库的名字)已经将两者建立了联系
  • 请千万注意,把上面的michaelliao替换成你自己的GitHub账户名,否则,你在本地关联的就是我的远程库,关联没有问题,但是你以后推送是推不上去的,因为你的SSH Key公钥不在我的账户列表中。
  • git push -u origin master 把本地库的所有内容推送到远程库上。把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。
  • 然后去Github对应的远程库看看,都已经推送上去了。
  • 此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改。

这样你就可以在Github上托管你的项目代码、vim的配置文件和插件、重要的文档……

现在我的vim的配置文件和插件已经同步到Github上了:https://github.com/xumenger/myVimConfig

另外推荐我的关于vim配置的文章::http://segmentfault.com/a/1190000003722928

9.从远程库克隆

  • 假设我的github上面有一个远程库,但是本地没有,需要克隆到本地,远程库的名字叫’gitskills’
  • git clone git@github.com:michaelliao/gitskills.git 克隆一个本地库
  • cd gitskills 进入克隆下来的本地库,默认的名字是和github上的一样的
  • ls -al 可以看到本地的克隆库里面是和远程库里面的一样的
  • 如果有多个人协作开发,那么每个人各自从远程克隆一份就可以了。

你也许还注意到,GitHub给出的地址不止一个,还可以用https://github.com/michaelliao/gitskills.git这样的地址。实际上,Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议。

使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。

10.分支管理

分支在实际中有什么用呢?假设你准备开发一个新功能,但是需要两周才能完成,第一周你写了50%的代码,如果立刻提交,由于代码还没写完,不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交,又存在丢失每天进度的巨大风险。

现在有了分支,就不用怕了。你创建了一个属于你自己的分支,别人看不到,还继续在原来的分支上正常工作,而你在自己的分支上干活,想提交就提交,直到开发完毕后,再一次性合并到原来的分支上,这样,既安全,又不影响别人工作。

其他版本控制系统如SVN等都有分支管理,但是用过之后你会发现,这些版本控制系统创建和切换分支比蜗牛还慢,简直让人无法忍受,结果分支功能成了摆设,大家都不去用。

但Git的分支是与众不同的,无论创建、切换和删除分支,Git在1秒钟之内就能完成!无论你的版本库是1个文件还是1万个文件。

11.创建和合并分支

首先教程中会详细讲解分支的原理(分支、指针、工作区……),一定要好好看!!看完之后你才能对你的创建分支和合并分支的操作不只是会用,更能在用的时候没有任何疑惑!反正能学到更多的知识,何乐而不为!

另外推荐这样的博客:使用git和github进行协同开发流程以及我的学习笔记使用git和github管理自己的项目—真实开发环境的策略

版本回退里,你已经知道,每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支。截止到目前,我们练习的learngit,只有一条时间线,在Git里,这个分支叫主分支,即master分支。HEAD严格来说不是指向提交,而是指向master,master才是指向提交的,所以,HEAD指向的就是当前分支。

开始实战:

  • git checkout -b dev 创建一个新的分支:dev,并且会切换到dev分支。所以这条命令有两个作用。git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:git branch devgit checkout dev
  • 补充:所有的git管理的项目刚开始时候默认有一条分支:master
  • git branch 查看当前所在的分支。git branch命令会列出所有分支,当前分支前面会标一个*号。
  • 因为切换到dev分支,所以我们现在可以在dev分支上正常提交,比如对readme.txt做一个修改
  • git add readme.txt
  • git commit -m "提交到dev分支"
  • git checkout master 现在,dev分支的工作完成,我们就可以切换回master分支
  • *注意:*切换回master分支后,再查看一个readme.txt文件,刚才添加的内容不见了!因为那个提交是在dev分支上,而master分支此刻的提交点并没有变
  • git merge dev 这是在master分支上执行的命令,作用是:把dev分支上的工作成果合并到master分支上
  • git merge命令用于合并指定分支到当前分支。合并后,再查看readme.txt的内容,就可以看到,和dev分支的最新提交是完全一样的。注意到上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。当然,也不是每次合并都能Fast-forward,我们后面会将其他方式的合并。
  • git branch -d dev 合并完成之后,可以放心的删除dev分支了
  • git branch 删除后,查看branch,只剩下master了

12.解决冲突

教程中有详细的图文说明,很形象,很好!一定要参考!

人生不如意之事十之八九,合并分支往往也不是一帆风顺的。

  • git checkout -b feature1 创建新的分支feature1,并且换到这个分支,进行新的实验
  • 在feature1分支下,假如将readme.txt的最后一行由”test branch” 改为”test feature1″
  • git add readme.txt
  • git commit -m "在feature1上修改readme.txt的最后一行" 在feature1分支上提交
  • git checkout master 切换到master分支。Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
  • 在master分支下,假如将readme.txt的最后一行由”test branch” 改为”test master”因为上面的是在feature1上进行的修改,所以切换回master之后,看到的文件并不是在feature1上修改后的文件
  • git add readme.txt
  • git commit -m "又在master上修改了readme.txt文件" 在master上也提交修改
  • 现在,master分支和feature1分支各自都分别有新的提交
  • git merge feature1 在master分支上执行该命令,与feature1分支合并。这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,果然冲突了!Git告诉我们,readme.txt文件存在冲突,必须手动解决冲突后再提交
  • git status git status也可以告诉我们冲突的文件
  • 这时候使用vim等编辑器打开readme.txt文件可以看到已经在readme.txt文件中将冲突的信息已经添加到里面了,Git用<<<<<<<=======>>>>>>>标记出不同分支的内容
  • 然后我们编辑readme.txt文件,处理冲突,将内容改成我们想要的样子
  • git add readme.txt
  • git commit -m "解决冲突" 在master上提交
  • git log --graph --pretty=oneline --abbrev-commit 用带参数的git log可以看到分支的合并情况。用git log --graph命令可以看到分支合并图。
  • git branch -d feature1 最后删除feature分支,完成工作。

2015.09.09 今天就学到这里,实在太晚了,赶紧睡觉,明天还得工作!什么都没有身体重要!
明天继续:分支管理策略

a.配置连接远程仓库Github

首先看这篇文章了解git和SVN的区别,毕竟现在必须在工作中使用的就是SVN,所以还是弄清楚两者的区别。

Git是分布式版本控制系统,同一个Git仓库,可以分布到不同的机器上。怎么分布呢?最早,肯定只有一台机器有一个原始版本库,此后,别的机器可以“克隆”这个原始版本库,而且每台机器的版本库其实都是一样的,并没有主次之分。

实际情况往往是这样,找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。

完全可以自己搭建一台运行Git的服务器,不过现阶段,为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫GitHub的神奇的网站,从名字就可以看出,这个网站就是提供Git仓库托管服务的,所以,只要注册一个GitHub账号,就可以免费获得Git远程仓库。

在继续阅读后续内容前,请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:

  1. 创建SSH Key。在用户目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsaid_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key,输入命令ssh-keygen -t rsa -C "youremail@example.com",你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsaid_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。
  2. 登陆GitHub,打开“Account settings”,“SSH Keys”页面.然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容:
    bVpN2
  3. 点“Add Key”,你就应该看到已经添加的Key:
    bVpN2

注意现在的Github的页面的布局可能和图片中显示有细小的差别,不过相信你能找到对应的操作!

为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。

当然,GitHub允许你添加多个Key。假定你有若干电脑,你一会儿在公司提交,一会儿在家里提交,只要把每台电脑的Key都添加到GitHub,就可以在每台电脑上往GitHub推送了。

最后友情提示,在GitHub上免费托管的Git仓库,任何人都可以看到喔(但只有你自己才能改)。所以,不要把敏感信息放进去。

如果你不想让别人看到Git库,有两个办法,一个是交点保护费,让GitHub把公开的仓库变成私有的,这样别人就看不见了(不可读更不可写)。另一个办法是自己动手,搭一个Git服务器,因为是你自己的Git服务器,所以别人也是看不见的。这个方法我们后面会讲到的,相当简单,公司内部开发必备。

现在的情景是,你已经在本地创建了一个Git仓库后,又想在GitHub创建一个Git仓库,并且让这两个仓库进行远程同步,这样,GitHub上的仓库既可以作为备份,又可以让其他人通过该仓库来协作,真是一举多得。具体可以见教程

首先,登陆GitHub,然后,在右上角找到“Create a new repo”按钮,创建一个新的仓库:
bVpN3

在Repository name填入learngit,其他保持默认设置,点击“Create repository”按钮,就成功地创建了一个新的Git仓库:

bVpN3

目前,在GitHub上的这个learngit仓库还是空的,GitHub告诉我们,可以从这个仓库克隆出新的仓库,也可以把一个已有的本地仓库与之关联,然后,把本地仓库的内容推送到GitHub仓库。

13.分支管理策略

通常,合并分支时,如果可能,Git会用Fast forward模式,但这种模式下,删除分支后,会丢掉分支信息。

如果要强制禁用Fast forward模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

下面我们实战一下--no-ff方式的git merge

  • git checkout -b dev 创建并切换到dev分支
  • vim readme.txt 修改readme.txt文件
  • git add readme.txt
  • git commit -m "add merge" 提交一个新的commit
  • git checkout master 切回master分支
  • git merge --no-ff -m "merge with with no-ff" dev 准备合并dev分支,注意--no-ff参数表示禁用Fast forward,因为本次合并要创建一个新的commit,所以加上-m参数,把commit描述写进去
  • git log --graph --pretty=oneline --abbrev-commit 合并后查看分支历史

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

14.分支策略

在实际开发中,我们应该按照几个基本原则进行分支管理:

  • 首先,master分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活
  • 那在哪里干活呢?干活都在dev分支上,也就是说,dev分支是不稳定的,到某个时候,比如2.0版本发布时,再把dev分支合并到master上,在master分支发新版本
  • 你和你的小伙伴每个人都在dev分支上干活,每个人都有自己的分支,时不时往dev分支上合并就可以了

所以,团队合作的分支看起来就像这个样子:
bVcc7

Git分支十分强大,在团队开发中应该充分应用。

15.Bug分支

软件开发中,bug就像是家常便饭一样。有了bug就需要修复,在Git中,由于分支是如此的强大,所以每个bug都可以通过一个新的临时分支来修复,修复后,合并分支,然后将临时分支删除。

当你街道一个修复代号为101的bug的任务的时候,很自然的,你想创建一个分支issue-101来修复它,但是,等等,当前正在dev上进行的工作还没有提交:

  • git status 查看状态

并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需1天时间。但是,必须在两个小时内修复该bug,怎么办?

幸好,Git还提供了一个stash功能,可以把当前工作现场“储藏”起来,等以后恢复现场后继续工作:

  • git stash 用该命令查看工作区,就是干净的(除非有没有被Git管理的文件),因此可以放心的创建分支来修复bug了。
  • git checkout master 从dev分支切换回master
  • git checkout -b issue-101 假定需要在master分支上修复,就从master创建临时分支
  • 假设现在修复好了bug,本例中,就假如在readme.txt文件中做了修改
  • git add readme.txt
  • git commit -m "fic bug 101" 修改之后提交
  • git checkout master 从issue-101切换回master
  • git merge --no-ff -m "merged bug fix 101" issue-101 合并分支选择不适用Fast forward模式,然后添加必要的描述信息
  • git branch -d issue-101 删除issue-101这个临时bug修复分支
  • 太棒了,bug搞定了,现在可以回到dev分支干活了
  • git checkout dev 切换回dev分支
  • git status 可以看出工作区是干净的,那么刚才的工作现场存在哪里呢?
  • git stash list 看到工作现场还在,Git吧stash内容存在某个地方了,但是需要恢复一下
  • 方法一git stash apply,但是回复后,stash内容并不删除,你需要使用git stash drop来删除
  • 方法二git stash pop,恢复的同时也把stas内容删除了
  • git stash list 再用git stash list查看,就看不到任何stash内容了
  • 你可以多次stash,恢复的时候,先用giit stash list 查看,然后恢复指定的stash,使用如下的命令
  • git stash apply stash@{0}

修复bug时,我们会通过创建新的bug分支进行修复,然后合并,最后删除。

当手头工作没有完成时,先把工作现场git stash一下,然后去修复bug,修复后,再git stash pop,回到工作现场。

16.Feature分支

软件开发中,总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。

现在,你终于接到了一个新任务:开发代号为Vulcan的新功能,该功能计划用于下一代星际飞船。软件开发中,总有无穷无尽的新的功能要不断添加进来。

添加一个新功能时,你肯定不希望因为一些实验性质的代码,把主分支搞乱了,所以,每添加一个新功能,最好新建一个feature分支,在上面开发,完成后,合并,最后,删除该feature分支。

现在,你终于接到了一个新任务:开发代号为Vulcan的新功能,该功能计划用于下一代星际飞船。于是开始准备工作

  • git checkout -b feature-vulcan 在dev分支上创建并且换到feature-vulcan分支,用来开发新功能
  • 假如现在经过一定的时间后,工作完成了
  • git add vulcan.py
  • git status 查看状态
  • git commit -m "add feature vulcan" 提交
  • git checkout dev 切换回dev分支
  • 一切顺利的话,feature分支和bug分支是类似的,合并,然后删除。但是,就在此时,接到上级命令,因经费不足,新功能必须取消!虽然白干了,但是这个分支还是必须就地销毁,不要再合并了:
  • git branch -d feature-vulcan 销毁失败。Git友情提醒,feature-vulcan分支还没有被合并,如果删除,将丢失掉修改,如果要强行删除,需要使用命令git branch -D feature-vulcan。
  • git branch -D feature-vulcan

17.多人协作

当你从远程仓库克隆时,实际上Git自动把本地的master分支和远程的master分支对应起来了,并且,远程仓库的默认名称是origin。

推送分支

  • git remote 查看远程库的信息
  • git remote -v 显示更为详细的信息
  • git push origin master 推送分支,就是把该分支上的所有本地提交推送到远程库。推送时,要指定本地分支,这样,Git就会把该分支推送到远程库对应的远程分支上。
  • git push origin dev 也可以推送到其他的分支,比如dev分支
  • 但是,并不是一定要把本地分支往远程推送,那么,哪些分支需要推送,哪些不需要呢?master分支是主分支,因此要时刻与远程同步;dev分支是开发分支,团队所有成员都需要在上面工作,所以也需要与远程同步;bug分支只用于在本地修复bug,就没必要推到远程了,除非老板要看看你每周到底修复了几个bug;feature分支是否推到远程,取决于你是否和你的小伙伴合作在上面开发。总之,就是在Git中,分支完全可以在本地自己藏着玩,是否推送,视你的心情而定!

抓取分支

多人协作时,大家都会往master和dev分支上推送各自的修改。

  • git clone git@github.com:michaelliao/learngit.git 现在,模拟一个你的小伙伴,可以在另一台电脑(注意要把SSH Key添加到GitHub)或者同一台电脑的另一个目录下克隆。
  • git branch 当你的小伙伴从远程库clone时,默认情况下,你的小伙伴只能看到本地的master分支,所以执行这条命令只能看到master分支
  • git checkout -b dev origin/dev 现在,你的小伙伴要在dev分支上开发,就必须创建远程origin的dev分支到本地,于是他用这个命令创建本地dev分支
  • git commit -m "add /usr/bin/env" 现在,他就可以在dev上继续修改,然后,时不时地把dev分支push到远程。
  • git add hello.py git commit -m "add coding: utf-8" git push origin dev 你的小伙伴已经向origin/dev分支推送了他的提交,而碰巧你也对同样的文件作了修改,并试图推送。推送失败,因为你的小伙伴的最新提交和你试图推送的提交有冲突。
  • git pull 解决办法也很简单,Git已经提示我们,先用git pull把最新的提交从origin/dev抓下来,然后,在本地合并,解决冲突,再推送。
  • git branch --set-upstream dev origin/dev git pull也失败了,原因是没有指定本地dev分支与远程origin/dev分支的链接,根据提示,设置dev和origin/dev的链接。
  • git pull 再次pull,这回git pull成功,但是合并有冲突,需要手动解决,解决的方法和分支管理中的解决冲突完全一样
  • git commit -m "merge & fix hello.py" git push origin dev 解决冲突后,再提交,再push

因此,多人协作的工作模式通常是这样的:

  • 首先,可以试图用git push origin branch-name 推送自己的修改
  • 如果推送失败,则因为远程分支比你的本地更新,需要先用git pull试图合并
  • 如果合并有冲突,则解决冲突,并在本地提交
  • 没有冲突或者解决掉冲突之后,再用git push origin branch-name推送就能成功
  • 如果git pull提示“no tracking information”,则说明本地分支和远程分支的链接关系没有创建,用命令git branch –set-upstream branch-name origin/branch-name。这就是多人协作的工作模式,一旦熟悉了,就非常简单。

18.标签管理

发布一个版本时,我们通常先在版本库中打一个标签,这样,就唯一确定了打标签时刻的版本。将来无论什么时候,取某个标签的版本,就是把那个打标签的时刻的历史版本取出来。所以,标签也是版本库的一个快照。

Git的标签虽然是版本库的快照,但其实它就是指向某个commit的指针(跟分支很像对不对?但是分支可以移动,标签不能移动),所以,创建和删除标签都是瞬间完成的。

19.创建标签

  • git branch 查看当前有哪些分支
  • git checkout master 在Git中打标签非常简单,首先,切换到需要打标签的分支上
  • git tag tagnamev1.0 打一个新标签
  • git tag 查看所有标签
  • 默认标签是打在最新提交的commit上的(也就是HEAD)。有时候,如果忘了打标签,比如,现在已经是周五了,但应该在周一打的标签没有打,怎么办?
  • git log --pretty=oneline --abbrev-commit 方法是找到历史提交的commit id,然后打上就可以了,这时候显示了提交的历史信息 ,假如有这么一条就是你想打标签的历史commit:6224937 add merge
  • git tag tagnamev2.0 6224937 就可以给这次提交打标签了
  • git tag 可以查看标签信息,注意,标签不是按时间顺序列出,而是按字母排序的
  • git show tagnamev2.0 查看具体的某个标签的信息
  • git tag -a v0.1 -m "version 0.1 released" 3628164 还可以创建带有说明的标签,用-a指定标签名,-m指定说明文字
  • git show v0.1 查看具体的某个标签的信息,可以看到说明文字
  • git tag -s v0.2 -m "signed version 0.2 released" fec145a 还可以通过-s用私钥签名一个标签,签名采用PGP签名,因此,必须首先安装gpg(GnuPG),如果没有找到gpg,或者没有gpg密钥对,就会报错
  • git show v0.2 用命令git show <tagname>可以看到PGP签名信息,用PGP签名的标签是不可伪造的,因为可以验证PGP签名。

20.操作标签

  • git tag -d v0.1 假如标签打错了,也可以删除,因为创建的标签都只存储在本地,不会自动推送到远程。所以,打错的标签可以在本地安全删除。
  • git push origin v1.0 要推送某个标签到远程
  • git push origin --tags 或者,一次性推送全部尚未推送到远程的本地标签
  • git tag -d v0.9 如果标签已经推送到远程,要删除远程标签就麻烦一点,先从本地删除
  • git push origin :refs/tags/v0.9 然后,从远程删除。删除命令也是push,但是格式要注意

21.使用Github

如何参与一个开源项目呢?比如人气极高的bootstrap项目,这是一个非常强大的CSS框架。

  • 你可以访问它的项目主页https://github.com/twbs/bootstrap,点“Fork”就在自己的账号下克隆了一个bootstrap仓库
  • git clone git@github.com:yourname/bootstrap.git 然后,从自己的账号下clone
  • 一定要从自己的账号下clone仓库,这样你才能推送修改。如果从bootstrap的作者的仓库地址git@github.com:twbs/bootstrap.git克隆,因为没有权限,你将不能推送修改。

Bootstrap的官方仓库twbs/bootstrap、你在GitHub上克隆的仓库my/bootstrap,以及你自己克隆到本地电脑的仓库,他们的关系就像下图显示的那样:
bVpQU

如果你想修复bootstrap的一个bug,或者新增一个功能,立刻就可以开始干活,干完后,往自己的仓库推送。

如果你希望bootstrap的官方库能接受你的修改,你就可以在GitHub上发起一个pull request。当然,对方是否接受你的pull request就不一定了。

如果你没能力修改bootstrap,但又想要试一把pull request,那就Fork一下廖雪峰的仓库:https://github.com/michaelliao/learngit,创建一个your-github-id.txt的文本文件,比如我的:xumenger.txt,写点自己学习Git的心得,然后推送一个pull request给他,他会视心情而定是否接受。

22.自定义Git

之前已经说过在使用之前必须先配置user.nameuser.email,否则后面commit的时候可能会有错误,实际上git还有很多可配置的:

  • git config --global color.ui true 让Git显示颜色,会让命令输出看起来更醒目,自己去试试一些git命令的输出看看是不是有色!

23.忽略特殊文件

有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦,等等,每次git status都会显示Untracked files …,有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受,这个问题解决起来也很简单,在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件。

不需要从头写.gitignore文件,GitHub已经为我们准备了各种配置文件,只需要组合一下就可以使用了。所有配置文件可以直接在线浏览:https://github.com/github/gitignore

忽略文件的原则是:

  • 忽略操作系统自动生成的文件,比如缩略图等;
  • 忽略编译生成的中间文件、可执行文件等,也就是如果一个文件是通过另一个文件自动生成的,那自动生成的文件就没必要放进版本库,比如Java编译产生的.class文件;
  • 忽略你自己的带有敏感信息的配置文件,比如存放口令的配置文件。

举个例子

假设你在Windows下进行Python开发,Windows会自动在有图片的目录下生成隐藏的缩略图文件,如果有自定义目录,目录下就会有Desktop.ini文件,因此你需要忽略Windows自动生成的垃圾文件:

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

然后,继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录:

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

加上你自己定义的文件,最终得到一个完整的.gitignore文件,内容如下:

# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# My configurations:
db.ini
deploy_key_rsa

最后一步就是把.gitignore也提交到Git,就完成了!当然检验.gitignore的标准是git status命令还会不会再说working directory clean。.gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!

使用Windows的童鞋注意了,如果你在资源管理器里新建一个.gitignore文件,它会非常弱智地提示你必须输入文件名,但是在文本编辑器里“保存”或者“另存为”就可以把文件保存为.gitignore了。

再次建议:有钱的买mac,没钱的用ubuntu–或者其他的linux发行版、被逼无奈的用Windows–但是被逼之余的自主时间一定要远离Windows。

24.配置别名

给Git配置好别名,就可以输入命令时偷个懒。我们鼓励偷懒。

  • git config --global alias.st status 有没有经常敲错命令?比如git status?status这个单词真心不好记。如果敲git st就表示git status那就简单多了,当然这种偷懒的办法我们是极力赞成的。
  • git config --global alias.co checkout
  • git config --global alias.ci commit
  • git config --global alias.br branch
  • 很多人都用co表示checkout,ci表示commit,br表示branch
  • git ci -m "bala bala bala..." 以后提交就可以简写成这样
  • git config --global alias.unstage 'reset HEAD'撤销修改一节中,我们知道,命令git reset HEAD file可以把暂存区的修改撤销掉(unstage),重新放回工作区。既然是一个unstage操作,就可以配置一个unstage别名
  • git unstage test.py 当你敲入此命令,实际上Git执行的是:git reset HEAD test.py
  • git config --global alias.last 'log -1' 配置一个git last,让其显示最后一次提交信息
  • git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit" 甚至还有人这样的配置,那么,这时候git lg的效果是这样的
    bVpQW

配置文件

配置Git的时候,加上--global是针对当前用户起作用的,如果不加,那只针对当前的仓库起作用。

配置文件放哪了?每个仓库的Git配置文件都放在.git/config文件中:

$ cat .git/config 
[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    ignorecase = true
    precomposeunicode = true
[remote "origin"]
    url = git@github.com:michaelliao/learngit.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
    remote = origin
    merge = refs/heads/master
[alias]
    last = log -1

别名就在[alias]后面,要删除别名,直接把对应的行删掉即可。

而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中:

$ cat .gitconfig
[alias]
    co = checkout
    ci = commit
    br = branch
    st = status
[user]
    name = Your Name
    email = your@email.com

配置别名也可以直接修改这个文件,如果改错了,可以删掉文件重新通过命令配置。

赞 (3)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址