使用git和github管理本身的项目---基础操做学习

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

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

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

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

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

之前由于以为git、github比较难,因此一直拖着不学,如今去尝试学习,一夜就OK了segmentfault

  • 重点之一是找到全面的、详细的、生动的、高质量的教程。廖雪峰的git教程是我目前找到的最好的一个。以前找到的讲解git用法的书《pro git》如今看来是没有必要再看了!安全

  • 重点之二就是本身当即去学,其实没什么难的,不要被貌似难的表象、概念唬住。服务器

  • 重点之三是最好能本身作简单的、系统的整理,方便本身随时再回来查看、复习、参考,不至于出现这样的状况:学完之后过一段时间以后再用,可是这时候发现忘了差很少了!ssh

  • 重点之四就是当即动手去用,不然学完很快就忘了。编辑器

有钱的买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 的版本号,不必定要所有的版本号,就像这个命令的例子,只要前面的约七、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/m...

另外推荐个人关于vim配置的文章::http://segmentfault.com/a/119...

9.从远程库克隆

  • 假设个人github上面有一个远程库,可是本地没有,须要克隆到本地,远程库的名字叫'gitskills'

  • git clone git@github.com:michaelliao/gitskills.git 克隆一个本地库

  • cd gitskills 进入克隆下来的本地库,默认的名字是和github上的同样的

  • ls -al 能够看到本地的克隆库里面是和远程库里面的同样的

  • 若是有多我的协做开发,那么每一个人各自从远程克隆一份就能够了。

你也许还注意到,GitHub给出的地址不止一个,还能够用https://github.com/michaellia...这样的地址。实际上,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文件的内容:
    图片描述

  3. 点“Add Key”,你就应该看到已经添加的Key:
    图片描述

注意如今的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”按钮,建立一个新的仓库:
图片描述

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

图片描述

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