Bootstrapgit &github 快速入门

本节情

  1. github介绍
  2. 安装
  3. 库创建& 提交代码
  4. 代码回滚
  5. 工作区和暂存区
  6. 撤销修改
  7. 去操作
  8. 长距离仓库
  9. 分层管理
  10. 多人数合作
  11. github使用
  12. 大意特殊文件.gitignore

 

 

1.github介绍

洋洋口都知晓,Linus在1991年创设了开源的Linux,从此,Linux系统不断向上,已经改成最为深的服务器系统软件了。

Linus虽然创立了Linux,但Linux的扩展是赖全球热心的志愿者与的,这么多人口当世界各地为Linux编写代码,那Linux的代码是如何保管的吗?

实际是,在2002年以前,世界各地的志愿者将源代码文件通过diff的道发放Linus,然后由Linus本人通过手工方式合并代码!

公恐怕会怀念,为什么Linus不把Linux代码放到版本控制系统里呢?不是产生CVS、SVN这些免费的版本控制系统吧?因为Linus坚定地不予CVS和SVN,这些集中式的版本控制系统不但速度迟滞,而且得联网才会利用。有部分商用的版本控制系统,虽然比CVS、SVN好用,但那是付费的,和Linux的开源精神不符。

唯独,到了2002年,Linux系统已经提高了十年了,代码库之老受Linus很不便继续透过手工方式管理了,社区的弟兄们为本着这种措施发挥了强烈不满,于是Linus选择了一个商业的版本控制系统BitKeeper,BitKeeper的东家BitMover公司出于人道主义精神,授权Linux社区免费用此版本控制系统。

泰的大好局面在2005年便受打破了,原因是Linux社区牛人凑,不免沾染了有梁山民族英雄的江湖习惯。开发Samba的Andrew试图破解BitKeeper的磋商(这么干的实际也未单独他一个),被BitMover公司发现了(监控工作召开得科学!),于是BitMover公司怒了,要收回Linux社区的免费使用权。

Linus可以向BitMover公司道只歉,保证从此严格保证弟兄们,嗯,这是未容许的。实际情形是这么的:

Linus花了点滴圆时间友好用C写了一个分布式版本控制系统,这虽是Git!一个月以内,Linux系统的源码已经由Git管理了!牛是怎定义的为?大家可以回味一下。

Git迅速变成极端盛行的分布式版本控制系统,尤其是2008年,GitHub网站上线了(github是一个冲git的代码托管平台,付费用户可建私人仓库,我们一般的免费用户只能采取集体仓库,也就是是代码要明白。),它吧初步源路免费供Git存储,无数开源项目上马搬迁到GitHub,包括jQuery,PHP,Ruby等等。

史就是这么偶然,如果无是那时候BitMover公司威胁Linux社区,可能现在咱们虽从来不免费而超级好用的Git了。

 

今天,GitHub已是:

  • 一个拥有143万开发者的社区。其中不乏Linux发明者Torvalds诸如此类的一等黑客,以及Rails创始人DHH这样的常青极客。
  • 是星球上无与伦比盛的开源托管服务。目前都托管431万git项目,不仅进一步多红开源项目迁入GitHub,比如Ruby
    on
    Rails、jQuery、Ruby、Erlang/OTP;近三年流行的开源库往往以GitHub首发,例如:BootStrap、Node.js、CoffeScript等。
  • alexa全球排名414之网站。

 

2. git安装

安装Git

无限早Git是于Linux上开发之,很丰富一段时间内,Git也只能当Linux和Unix系统及走。不过,慢慢地有人把它移植到了Windows上。现在,Git可以当Linux、Unix、Mac和Windows这几非常平台达成健康运行了。

 

 

 

 

 

 

比方用Git,第一步当然是装Git了。根据你手上使的阳台来读书下面的契:

在Linux上安装Git

第一,你得试着输入git,看看系统出没发生安Git:

1
2
3
$ git
The program 'git' is currently not installed. You can install it by typing:
sudo apt-get install git

譬如上面的通令,有广大Linux会友好地告诉您Git没有装,还见面报告你哪些设置Git。

如果你刚好用Debian或Ubuntu
Linux,通过一致条sudo apt-get install git便好一直到位Git的安,非常简单。

 

3.版本库创建

哎是版本库呢?版本库又叫做仓库,英文名repository,你得略明了成一个索引,这个目录里的具有文件还可以于Git管理起,每个文件的改、删除,Git都能跟,以便任何时刻都得追踪历史,或者当明天有时刻好“还原”。

故此,创建一个版本库非常简单,首先,选择一个当的地方,创建一个空目录:

1
2
3
4
5
mkdir git_trainning
cd git_trainning/
 
$ git init
Initialized empty Git repository in /Users/alex/git_trainning/.git/

时而Git就把仓库建好了,而且告诉您是一个缺损的库房(empty Git
repository),细心之读者可窥见当前目录下大半矣一个.git的目,这个目录是Git来跟管理版本库底,没事千万不要手动修改是目录里的文件,不然改乱了,就将Git仓库给毁掉了。

倘若你未曾见到.git目,那是以这个目录默认是潜伏的,用ls -ah一声令下就可以看见。

拿公文上加至版本库

率先这里更显一下,所有的版本控制系统,其实只能跟踪文本文件之转,比如TXT文件,网页,所有的程序代码等等,Git也非异。版本控制系统可告知你每次的更改,比如当第5执加了一个单词“Linux”,在第8行删了一个单词“Windows”。而图片、视频这些二进制文件,虽然为会由版本控制系统管理,但迫于跟踪文件的别,只能把二进制文件每次转离谱起来,也就是一味略知一二图片于100KB改化了120KB,但到底改了什么,版本控制系统非理解,也无可奈何知道。

噩运的凡,Microsoft的Word格式是亚上前制格式,因此,版本控制系统是可望而不可及跟踪Word文件的改动的,前面我们选的例证只是为演示,如果假定实在使用本控制体系,就设为纯文本方式编写文件。

坐文件是发编码的,比如中文有常用的GBK编码,日文有Shift_JIS编码,如果无历史遗留问题,强烈建议使用标准的UTF-8编码,所有语言应用相同种编码,既没有冲,又受抱有平台所支撑。

言归正传,现在我们编辑一个first_git_file.txt文件,内容如下:

1
2
3
4
$ vim first_git_file.txt
 
first time using git, excited!
第一次用git哈哈

早晚要是放开git_trainning目录下(子目录也尽),因为马上是一个Git仓库,放到任何地方Git再决定也搜不至这个文件。

同把大象放到冰箱用3步相比,把一个文件放到Git仓库只需要少步。

第一步,用命令git add报Git,把公文上加到仓库:

1
$ git add first_git_file.txt

行方的命令,没有其它显示,说明添加成功。

第二步,用命令git commit告Git,把公文提交至仓库:  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ git commit -m "commit my first git file"
 
[master (root-commit) 621e6e4] commit my first git file
 Committer: Alex Li <alex@alexs-macbook-pro.local>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly. Run the
following command and follow the instructions in your editor to edit
your configuration file:
 
    git config --global --edit
 
After doing this, you may fix the identity used for this commit with:
 
    git commit --amend --reset-author
 
 file changed, 2 insertions(+)
 create mode 100644 first_git_file.txt
</alex@alexs-macbook-pro.local>

高中档红色部分的意思是,你在向git库里提交代码时,你用报告git你是哪位,这样git就会纪录下来是何许人也改变之代码,其实就算是为以后查询好,你一味待提供一个名与邮件地址就得,这里自己的git直接通过主机名好创造了一个,但您得由此git
config –global –edit
修改

 

粗略解释一下git commit命令,-m后面输入的是此次交付的证实,可以输入任意内容,当然最好是生意义之,这样你虽会起历史记录里好地找到改动记录。

烦麻烦不思量输入-m "xxx"施行很?确实来办法可以这样干,但是明显不建议您这么干,因为输入说明对好对旁人看都死重点。

胡Git添加文件要addcommit累计两步呢?因为commit可以同样浅提交多文件,所以您得频繁add差的公文,比如:

1
2
3
$ git add file1.txt
$ git add file2.txt file3.txt
$ git commit -m "add 3 files."

  

4. 代码回滚

4.1代码修改并交由  

我们曾经打响地增长并提交了一个first_git_file.txt文件,现在,是上累工作了,于是,我们后续修改first_git_file.txt文件,改成为如下内容:

1
2
3
First time using git, excited! update ...
insert line here...
第一次用git哈哈

现在,运行git status命令看看结果:

1
2
3
4
5
6
7
8
9
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
 
    modified:   first_git_file.txt
 
no changes added to commit (use "git add" and/or "git commit -a")

虽说Git告诉我们first_git_file.txt被改了,但一旦会省具体修改了呀内容,自然是老大好的。比如您休假两周到起国外归来,第一天上班时,已经忘记上次怎么改的readme.txt,所以,需要用git diff本条令看看:  

1
2
3
4
5
6
7
8
9
10
11
$ git diff first_git_file.txt
diff --git a/first_git_file.txt b/first_git_file.txt
index 2d13c2c..248d853 100644
--- a/first_git_file.txt
+++ b/first_git_file.txt
@@ -1,3 +1,4 @@
-first time using git, excited!
+First time using git, excited! update ...
 insert line here...
 第一次用git哈哈
+insert line again haha...

输出中+号绿色显示的尽管是改或新增的内容,-号红色显示的饶是去丢或者让改的情

知了针对性first_git_file.txt 作了啊修改后,再将其交给到仓库就放心多矣,提交修改及交给新文件是一致的蝇头步,第一步是git add

1
2
3
4
5
$ git add . # .  代表把当前目录下所有改动的文件都提交到代码库
Alexs-MacBook-Pro:git_trainning alex$ git commit -m "commit changes"
[master 50ad6b5] commit changes
 Committer: Alex Li <alex@Alexs-MacBook-Pro.local>
 file changed, 1 insertion(+)

交付后,我们重用git status一声令下看看仓库的脚下状态:  

1
2
3
$ git status
# On branch master
nothing to commit (working directory clean)

Git告诉我们当前没有用交给的改动,而且,工作目录是清(working
directory clean)的。

  

4.2 代码回滚  

今,你早已学会了修改文件,然后将修改提交至Git版本库,现在,再练一不善,修改first_git_file.txtt文件如下: 

1
2
3
4
5
First time using git, excited! update ...
insert line here..改之前的.
第一次用git哈哈
insert line again haha...
加点新内容 

下一场尝试提交:

1
2
3
4
5
$ git add first_git_file.txt
$ git commit -m "add new content"
[master 4459657] add new content
 Committer: Alex Li <alex@Alexs-MacBook-Pro.local>
 file changed, 2 insertions(+), 1 deletion(-)

譬如这样,你连对文件进行改动,然后连提交修改至版本库里,就好于玩RPG游戏时,每经一样拉扯就是会见活动将打状态存盘,如果有平等关没过去,你还得选读取前一关的状态。有些上,在打Boss之前,你见面手动存盘,以便要打Boss失败了,可以自近日之地方再开始。Git也是一律,每当你道文件修改至得水准的当儿,就可“保存一个快照”,这个快照在Git中吃号称commit。一旦您管文件改乱了,或者误删了文件,还可打近期的一个commit光复,然后继续做事,而无是管几乎独月的做事战果全部丢。

今天,我们回忆一下first_git_file.txt文件共来几乎独本子被交给到Git仓库里了: 

版本1

1
2
first time using git, excited!
第一次用git哈哈

版本2

1
2
3
first time using git, excited!
insert line here...
第一次用git哈哈

版本3

1
2
3
4
first time using git, excited!
insert line here...
第一次用git哈哈
insert line again haha...

版本4

1
2
3
4
5
First time using git, excited! update ...
insert line here..改之前的.
第一次用git哈哈
insert line again haha...
加点新内容

当然矣,在实际上工作受到,我们脑子里怎么可能记得一个几千履行的文件每次都改成了啊内容,不然一旦版本控制系统为什么。版本控制系统肯定起某个命令可以告知我们历史记录,在Git中,我们所以git log指令查看:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
$ git log
commit 445965781d1fd0d91e76d120450dd18fd06c7489
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 18:44:29 2016 +0800
 
    add new content
 
commit be02137bb2f54bbef0c2e99202281b3966251952
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 17:55:16 2016 +0800
 
    update again
 
commit 50ad6b526810bb7ccfea430663757ba2337b9816
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 17:46:51 2016 +0800
 
    commit changes
 
commit 621e6e44d04fa6a1cdc37826f01efa61b451abd1
Author: Alex Li <alex@Alexs-MacBook-Pro.local>
Date:   Tue Oct 4 17:42:50 2016 +0800
 
    commit my first git file

git log令显示从近年来届极致远之交给日志,我们可以看4潮提交,最近之一律不好是add
new content,上等同不良是update
again,最早的等同不行是commit my first git file
如果嫌输出信息极多,看得乱七八糟的,可以试加上--pretty=oneline参数:  

1
2
3
4
5
$ git log --pretty=oneline
445965781d1fd0d91e76d120450dd18fd06c7489 add new content
be02137bb2f54bbef0c2e99202281b3966251952 update again
50ad6b526810bb7ccfea430663757ba2337b9816 commit changes
621e6e44d04fa6a1cdc37826f01efa61b451abd1 commit my first git file

待交提示的是,你见到的如出一辙不行失误类似3628164...882e1e0的是commit id(版本号),和SVN不一样,Git的commit id免是1,2,3……递增的数字,而是一个SHA1计算出来的一个挺充分的数字,用十六进制表示,而且若瞧底commit id暨自身的自然不一致,以你协调的也罢按。为什么commit id待用这么一雅串数字代表为?因为Git是分布式的版本控制系统,后面我们还要研究多丁当与一个版本库里工作,如果大家都为此1,2,3……作为本号,那必然就撞了。  

 

转滚回滚回滚  

哼了,现在咱们启动时穿梭机,准备将first_git_file.txt回退及上一个本,也就算是“update
again”的非常本,怎么开吧?

率先,Git必须懂得当前版本是哪位版本,在Git中,用HEAD表示目前版本,也便是最新的交由be02137bb2f54bbef0c2e99202281b3966251952(注意自己的交ID和公的肯定不一致),上一个版本就是HEAD^,上达标一个本子就是HEAD^^,当然为上100个本子写100单^正如便于累不回复,所以写成HEAD~100

兹,我们只要拿当下版“add new content”回退到上一个版本“update
again”,就好应用git reset命令:

1
2
$ git reset --hard HEAD^
HEAD is now at be02137 update again

此刻再拘留而的文本内容,果然就是狂跌回到了

1
2
3
4
5
more first_git_file.txt
First time using git, excited! update ...
insert line here...
第一次用git哈哈
insert line again haha...

这时还得继承更朝着前面回退一个本子,不过且慢,然我们因此git log再次看现在本库底状态:

1
2
3
4
$ git log --pretty=oneline
be02137bb2f54bbef0c2e99202281b3966251952 update again
50ad6b526810bb7ccfea430663757ba2337b9816 commit changes
621e6e44d04fa6a1cdc37826f01efa61b451abd1 commit my first git file

新式的慌版本add new
content已经看不到了!好于你于21世纪坐时光穿梭机来到了19世纪,想更返回就转不失矣,肿么办?

术其实还是局部,只要上面的授命执行窗口还从未于关掉,你就算足以顺往上查找什么找什么,找到十分add
new content的commit id是445965781d1fd0d91e76d120450dd18fd06c7489

,于是就可指定回到未来的有版本:

1
2
git reset --hard 4459657
HEAD is now at 4459657 add new content

版本号没必要写全,前几乎各项就是得了,Git会自动去追寻。当然为无可知只是写前一两个,因为Git可能会见找到多个本子号,就无法确定是啦一个了。

复小心地看望first_git_file.txt的内容:

1
2
3
4
5
First time using git, excited! update ...
insert line here..改之前的.
第一次用git哈哈
insert line again haha...
加点新内容

果不其然,我胡汉三以回到了。

Git的版本回退速度特别快,因为Git在里生只针对当前本的HEAD指南针,当你回退版本的当儿,Git仅仅是将HEAD从对add new content

 

现,你扭曲退交了某版本,关掉了电脑,第二天早上即后悔了,想恢复到新本子怎么处置?找不顶新本子的commit
id怎么收拾?

在Git中,总是有忏悔药可以吃的。当你用$ git reset –hard
HEAD^回退到update again版本时,再惦记重操旧业到新型add new
content的本,就不能不找到add new contentL的commit
id。Git提供了一个限令git reflog用来记录你的各级一样蹩脚命令:

1
2
3
4
5
6
7
8
9
10
11
$ git reflog
4459657 HEAD@{0}: reset: moving to 4459657
be02137 HEAD@{1}: reset: moving to HEAD^
4459657 HEAD@{2}: commit: add new content
be02137 HEAD@{3}: reset: moving to be02137bb
50ad6b5 HEAD@{4}: reset: moving to 50ad6b5
621e6e4 HEAD@{5}: reset: moving to 621e6e44
50ad6b5 HEAD@{6}: reset: moving to HEAD^
be02137 HEAD@{7}: commit: update again
50ad6b5 HEAD@{8}: commit: commit changes
621e6e4 HEAD@{9}: commit (initial): commit my first git file

毕竟舒了人数暴,第二执行显示add new content的commit
id是4459657,现在,你又好乘坐时光机回到未来了。  

 

 

5. 工作区和暂存区

Git和任何版本控制系统设SVN的一个不同之处就是发生暂存区的定义。

先来拘禁名词解释。

工作区(Working Directory

就算若当微机里克看底目,比如我的git_trainning文件夹就是一个工作区:

1
2
ls git_trainning/
first_git_file.txt

版本库(Repository)

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

Git的版本库里怀了很多物,其中最为着重之虽是名为stage(或者给index)的暂存区,还有Git为咱自行创建的率先只支行master,以及针对性master的一个指南针叫HEAD

Bootstrap 1

分支和HEAD的定义我们随后更称。

前说了咱们管文件为Git版本库里丰富的上,是分点儿步执行的:

首先步是故git add管文件添加进去,实际上就是拿公文修改补充加到暂存区;

第二步是故git commit付更改,实际上就是管暂存区的兼具情节交给至当下分。

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

而可概括明了吧,需要提交的文书修改都放到暂存区,然后,一次性交给暂存区的具备修改。

俗话说,实践产生真知。现在,我们再度练一遍,先对first_git_file.txt开只修改,比如加上一行内容:

1
2
3
4
5
6
First time using git, excited! update ...
insert line here..改之前的.
第一次用git哈哈
insert line again haha...
加点新内容
update v5

接下来,在工作区新增一个readme.md文本文件(内容无写)。

先用git status查阅转状态:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
 
    modified:   first_git_file.txt
 
Untracked files:
  (use "git add <file>..." to include in what will be committed)
 
    readme.md
 
no changes added to commit (use "git add" and/or "git commit -a")

Git非常理解地报我们,first_git_file.txt于修改了,而readme.md尚从没有给补充加过,所以它们的状态是Untracked

现行,使用命令git add .,再用git status再查转:

1
2
3
4
5
6
7
8
9
$ git add .
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
 
    modified:   first_git_file.txt
    new file:   readme.md
</file>

现在,暂存区的状态就改成这样了:

Bootstrap 2

(盗图关系, 这里readme.txt = first_git_file.txt , LICENSE =
readme.md)

所以,git add指令实际上就是将要交给的装有修改放到暂存区(Stage),然后,执行git commit不畏可一次性把暂存区的有修改提交至分。

1
2
3
4
$ git commit -m "知道暂存区stage的意思了"
[master 9d65cb2] 知道暂存区stage的意思了
 2 files changed, 2 insertions(+)
 create mode 100644 readme.md

一旦付出后,如果您还要不曾对工作区做其他修改,那么工作区就是“干净”的:

1
2
3
$ git status
On branch master
nothing to commit, working directory clean

现在版本库变成了如此,暂存区就从未有过另外内容了:

Bootstrap 3

(盗图关系, 这里readme.txt = first_git_file.txt , LICENSE =
readme.md)

* *暂存区是Git非常重大的定义,弄明白了暂存区,就作明白了Git的多多操作到底干了啊。

 

  

6. 撤修改  

自然,你是匪会见犯错的。不过本凡是黎明简单碰,你正赶一份工作报告,你当readme.md遇上加了一条龙:

1
2
3
#git study repo
git is great
but my stupid boss still prefers SVN.

在公准备付出前,一盏咖啡起了图,你突然发现了“stupid
boss”可能会见被你丢这月之奖金!

既然如此错误发现得杀及时,就得非常容易地纠正其。你得删掉最后一执行,手动把文件恢复到直达一个本的状态。如果因此git status翻转:

1
2
3
4
5
6
7
8
9
10
git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
 
    modified:   readme.md
 
no changes added to commit (use "git add" and/or "git commit -a")
</file></file>

若得窥见,Git会告诉您,git checkout -- file可摒弃工作区的修改:  

1
2
3
4
$ git checkout -- readme.md
 
more readme.md
#git study repo

君刚才添加的2行骂老板的讲话虽深受撤了,

命令git checkout -- readme.md意就是是,把readme.md文件在工作区的改总体收回,这里出个别种植情景:

一种是readme.md起改后尚尚未让置于暂存区,现在,撤销修改就回来与版本库一模型一样的状态;

一种是readme.md已上加到暂存区后,又犯了改动,现在,撤销修改就赶回添加到暂存区后的状态。

总之,就是吃这个文件回到最近一样糟糕git commitgit add每每之状态。

git checkout -- file指令中的--很重要,没有--,就成了“切换到外一个分段”的一声令下,我们以后头的分层管理中会再次相遇git checkout命令。  

 

今昔要是昕3沾,你不但写了有的谬论,还git add至暂存区了:

1
2
3
4
5
6
7
8
cat readme.md
Git is a distributed version control system.
Git is free software distributed under the GPL.
Git has a mutable index called stage.
Git tracks changes of files.
My stupid boss still prefers SVN.
 
$ git add readme.md

   

庆幸的凡,在commit事先,你发现了这题目。用git status翻看转,修改就是加上到了暂存区,还从来不交到: 

1
2
3
4
5
6
7
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
 
    modified:   readme.md
</file>

Git同样告诉我们,用命令git reset HEAD file得拿暂存区的改动撤销掉(unstage),重新放回工作区:

1
2
3
$ git reset HEAD readme.md
Unstaged changes after reset:
M   readme.md

git reset令既可以回退版本,也可以管暂存区的改动回退交工作区。当我们因此HEAD经常,表示最新的本子。

再用git status翻开转,现在暂存区是根之,工作区有涂改

1
2
3
4
5
6
7
8
9
$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.md
#
no changes added to commit (use "git add" and/or "git commit -a")

尚记得如何丢弃工作区的修改为?

1
2
3
4
$ git checkout -- readme.md
 
more readme.md
#git study repo

万事社会风气归根到底冷静了!

  

7. 去除操作

每当Git中,删除也是一个改动操作,我们实战一下,先补加一个新文件test.txt到Git并且付诸:  

1
2
3
4
5
$ git add .
$ git commit -m "add test.txt"
[master a8fa95a] add test.txt
 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 test.txt

相似景象下,你平凡直接在文件管理器中把没因此之文本去了,或者用rm指令去了

1
rm test.txt

其一时候,Git知道您去了文本,因此,工作区和版本库就无一样了,git status命令会立刻报您什么文件被剔除了:

1
2
3
4
5
6
7
8
9
$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
 
    deleted:    test.txt
 
no changes added to commit (use "git add" and/or "git commit -a")

今天而生出个别独挑选,一凡是当真要自版本库中剔除该公文,那即便因此命令git rm删掉,并且git commit

1
2
3
4
5
6
7
x$ git rm test.txt
rm 'test.txt'
 
$ git commit -m "remove test"
[master 03df00a] remove test
 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100644 test.txt

现在,文件就由版本库中让去除了。

任何一样种植情景是删错了,因为版本库里还有啊,所以可以十分轻松地管误删的文本恢复至最新版本:

1
$ git checkout -- test.txt

git checkout其实是故版本库里之本子替换工作区的本,无论工作区是修改还是剔除,都得以“一键还原”。  

 

  

  

8. 长途仓库  

顶目前为止,我们曾经控制了哪以Git仓库里对一个文本进行时不断,你再为不用担心文件备份或者少的问题了。

只是有因此过集中式版本控制系统SVN的童鞋会站下说,这些效应在SVN里早就闹了,没看Git有啊特别之地方。

科学,如果只是以一个仓房里管理文件历史,Git和SVN真没啥区别。为了保证你本所学的Git物超所值,将来断然免会见后悔,同时为了打击就背学了SVN的童鞋,本章开始介绍Git的杀手级功能之一(注意是某某,也即是背后还有的二,之三……):远程仓库。

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:

1
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文件之情节:

Bootstrap 4

接触“Add Key”,你就是该看曾添加的Key

怎GitHub需要SSH
Key呢?因为GitHub需要识别出公推送的交由确实是你推送的,而未是他人冒充的,而Git支持SSH协议,所以,GitHub只要了解了你的公钥,就足以肯定就生您协调才能够推送。

理所当然,GitHub允许而加加多单Key。假定你来若干计算机,你说话当小卖部交付,一会儿以爱妻提交,只要拿各国令计算机的Key都加上到GitHub,就可以在各国台微机及通往GitHub推送了。

末段交提醒,在GitHub上免费托管的Git仓库,任何人都得看出喔(但只是生您协调才能够更改)。所以,不要拿敏感信息放进去。

假使你莫思量给旁人见到Git库,有有限独主意,一个凡是交点保护费,让GitHub把公开之堆栈变成私有的,这样别人就是看无展现了(不可读更不行写)。另一个艺术是祥和下手,搭一个Git服务器,因为凡你协调的Git服务器,所以别人呢是圈不显现底。这个法我们后面会讲到之,相当简单,公司中支出必备。

包您有一个GitHub账号后,我们虽将上马远程仓库的学。

  

8.1 创建远程仓库 

如今底场景是,你就在当地创建了一个Git仓库后,又想当GitHub创建一个Git仓库,并且为这点儿个仓库进行远程同步,这样,GitHub上的仓库既可作为备份,又可以叫其他人通过该仓库来协作,真是一举多得。

率先,登陆GitHub,然后,在右边上斗找到“New
repository”按钮,创建一个初的堆栈:

Bootstrap 5

 Bootstrap 6

 

 

创立好的仓库

Bootstrap 7

 

眼前,在GitHub上之这oldboy_website仓库还是空的,GitHub告诉我们,可以于夫库房克隆出新的库房,也可以管一个既有些地方仓库和之干,然后,把本地仓库的情节推送至GitHub仓库。

现行,我们根据GitHub的唤醒,在地方就有的git_trainning仓库下运行命令:

 

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ git remote add origin git@github.com:triaquae/oldboy_website.git #添加远程仓库
$ git push -u origin master #推到远程
 
The authenticity of host 'github.com (192.30.253.113)' can't be established.
RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Are you sure you want to continue connecting (yes/no)? yes   #第一次推会出现,写yes
Warning: Permanently added 'github.com,192.30.253.113' (RSA) to the list of known hosts.
Counting objects: 20, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (14/14), done.
Writing objects: 100% (20/20), 1.76 KiB | 0 bytes/sdone.
Total 20 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), done.
To git@github.com:triaquae/oldboy_website.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

吁千万注意,把上面的triaquae替换成你协调之GitHub账户名,否则,你于该地关联的就是是自己的远程库,关联没有问题,但是若之后推送是促进不上的,因为你的SSH
Key公钥不以自己的账户列表中。

加加后,远程库的名字就是origin,这是Git默认的叫法,也足以转成为别的,但是origin这个名字同样看就是懂得凡是远程库。

将当地库底情节推送到长途,用git push命令,实际上是把当下支行master促进送及长途。  

 

这会儿刷新远程仓库页面, 就见到了公正从本地推进上来的代码了

Bootstrap 8

从现在起,只要本地作了付出,就好透过命令:

1
$ git push origin master

what ? 不迷信?那帮你试试一下吧

创建一个index.html文件,同时上传到长途

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ vim index.html
$ git add .
$ git commit -m "add home page"
 
[master 8675486] add home page
 file changed, 6 insertions(+)
 create mode 100644 index.html
 
$ git push origin master #推到远程
 
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 362 bytes | 0 bytes/sdone.
Total 3 (delta 0), reused 0 (delta 0)
To git@github.com:triaquae/oldboy_website.git
   03df00a..8675486  master -> master

接下来刷新下远程仓库页面,就来看而的初创办的文书了

Bootstrap 9

 

8.2 从远程库克隆  

咱叙了先行有当地库,后发生长途库底早晚,如何干远程库。

现在,假而我们于零星出,那么极端好的办法是优先创造远程库,然后,从远程库克隆。

第一,登陆GitHub,创建一个初的堆栈,名字被gitskills

Bootstrap 10

我们勾选Initialize this repository with a README,这样GitHub会自动为咱创建一个README.md文件。创建了后,可以观看README.md文件:

  

Bootstrap 11

今天,远程库已经准备好了,下一样步是用命令git clone仿造一个本土库:

Bootstrap 12

以本土找一个君想存这个远程仓库的目,然后在该地命令行用git clone
命令来克隆这个远程库

1
2
3
4
5
6
7
8
9
10
11
$ git clone git@github.com:triaquae/gitskills.git
Cloning into 'gitskills'...
Warning: Permanently added the RSA host key for IP address '192.30.253.112' to the list of known hosts.
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (3/3), done.
Checking connectivity... done.
 
cd gitskills/  #进入刚clone下来的目录
ls
README.md

倘若有多个人合作开发,那么每个人分别打远程克隆一份便可以了。

你或许还注意到,GitHub给有之地址不止一个,还好为此https://github.com/triaquae/gitskills.git 这样的地点。实际上,Git支持多协议,默认的git://运ssh,但为可以动用https等其它协商。

使用https除了速度缓慢外,还闹个极度深的分神是历次推送都不能不输入口令,但是以少数只放http端口的店里面就无法利用ssh商要只能用https

 

9. 分管理  

分段就是科幻电影里面的平宇宙,当您正电脑前努力学习Git的当儿,另一个您方其他一个平行宇宙里努力学习SVN。

设若个别独平行宇宙互不干扰,那对现行底乃也远非啥影响。不过,在某个时间点,两只平行宇宙合并了,结果,你既然学会了Git又学会了SVN!

Bootstrap 13

 

 

分在其实中生啊用呢?假要你准备出一个新职能,但是急需简单完美才会不辱使命,第一圆满而写了50%底代码,如果这交给,由于代码还未曾写了,不完全的代码库会促成别人休可知办事了。如果当代码全部状了再同不善提交,又存在丢失每天进度的伟风险。

现在产生矣子,就毫无怕了。你创造了一个属于您自己之分层,别人看不到,还继续在本来的分上健康办事,而而于协调的子上干活,想付出就交给,直到开了后,再一次性统一到原的支行上,这样,既安全,又不影响别人干活。

别版本控制系统而SVN等还起分管理,但是就此了之后您会意识,这些版本控制系统创造和切换分支比蜗牛还迟迟,简直让丁无法忍受,结果分支功能成为了张,大家都未错过用。

而Git的子是不同寻常的,无论创建、切换和去分支,Git在1秒钟里就能够形成!无论你的版本库是1只文本还是1万独文本。

 

9.1 创建及合分支 

在读书版本回退部分经常,你早就了解,每次交,Git都把它串成一条时间线,这长达时间线虽是一个子。截止到目前,只发生同等长长的时间线,在Git里,这个分为主分支,即master分支。HEAD严格来说不是依靠为提交,而是指为mastermaster才是靠于提交的,所以,HEAD对的就算是时下子。

同一开始的时刻,master支行是一律长达线,Git用master对最新的交,再就此HEAD指向master,就会确定当前分,以及时子的提交点:

Bootstrap 14

 

老是交,master支行都见面上前移动一步,这样,随着你不休提交,master分层的线为更加丰富, 当我们创建新的旁,例如dev常常,Git新建了一个指南针叫dev,指向master同一之交给,再将HEAD指向dev,就表示手上支行在dev上: 

Bootstrap 15

假如我们当dev上的做事做到了,就可拿dev合并到master及。Git怎么统一为?最简便的方,就是一直将master指向dev的手上付出,就成功了合:

Bootstrap 16

所以Git合并分支为飞!就窜指针,工作区内容呢无换!

联合了分支后,甚至可以去除dev分支。删除dev分层就是将dev指南针给删掉,删掉后,我们尽管剩下了平等长长的master分支:

Bootstrap 17

算最神奇了,你看得出来有些提交是透过分支就的呢?

 

脚开始实战

先是,我们创建dev分,然后切换到dev分支:

1
2
$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命加上-b参数表示创建并切换,相当给以下简单长达命令:

1
2
3
$ git branch dev
$ git checkout dev
Switched to branch 'dev'

然后,用git branch命令查看时子:

1
2
3
$ git branch
* dev
  master

git branch指令会列有具有支行,当前分前面会标一个*号。

接下来,我们虽好以dev子上健康提交,比如针对readme.txt做只修改,加上一行:

1
Creating a new branch is quick.

然后交由:

1
2
3
4
$ git add readme.txt
$ git commit -m "branch test"
[dev fec145a] branch test
 file changed, 1 insertion(+)

现在,dev分层的工作形成,我们不怕好切换回master分支:

1
2
$ git checkout master
Switched to branch 'master'

切换回master子后,再查一个readme.txt文件,刚才添加的始末无显现了!因为非常提交是于dev分支上,而master分层此刻的提交点并从未更换:

Bootstrap 18

现在,我们把dev分的做事战果合并及master分支上:

1
2
3
4
5
$ git merge dev
Updating d17efd8..fec145a
Fast-forward
 readme.txt |    1 +
 file changed, 1 insertion(+)

git merge命用于合并指定分支到即子。合并后,再查readme.txt的始末,就可以看到,和dev分的新式提交是完全同的。

留意到面的Fast-forward消息,Git告诉我们,这次联合是“快进模式”,也不怕是直拿master指向dev的时付,所以集合速度好抢。

理所当然,也不是每次合并都能Fast-forward,我们后会称其他艺术的集合。

合完成后,就得放心地抹dev分支了:

1
2
$ git branch -d dev
Deleted branch dev (was fec145a).

删除后,查看branch,就单单剩下master分支了:

1
2
$ git branch
* master

以缔造、合并及去分支非常抢,所以Git鼓励而下分支就有任务,合并后再也删掉分支,这与直接在master旁上干活力量是如出一辙的,但经过又安全。

 

9.2 解决冲突

人生不如意之从十有八九,合并分支往往也不是顺的。

预备新的feature1子,继续我们的新分出:

1
2
$ git checkout -b feature1
Switched to a new branch 'feature1'

修改readme.txt最后一执,改吗:

1
added this line from branch feature 1

feature1分段上授:

$ git add readme.txt 
$ git commit -m "add feature"
[feature1 75a857c] AND simple
 1 file changed, 1 insertion(+), 1 deletion(-)

切换到master分支:

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.

Git还会自行唤醒我们目前master分比远程的master旁使超过前1单提交。

master支行上把readme.txt文件之结尾一实施改吧:

1
added this line from master

提交:

$ git add readme.txt 
$ git commit -m "master update"
[master 400b400] & simple
 1 file changed, 1 insertion(+), 1 deletion(-)

现在,master分支和feature1分层各自还分别产生新的提交,变成了这么:

Bootstrap 19

这种景象下,Git无法执行“快速合并”,只能试图把个别的改合并起来,但这种联合就可能会见有冲突,我们摸索看:

1
2
3
4
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.

果然冲突了!Git告诉我们,readme.txt文件是冲突,必须手动解决冲突后又付诸。git status否可告知我们冲突的文件:

1
2
3
4
5
6
7
8
9
10
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 2 commits.
#
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      readme.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

俺们可一直翻readme.txt的情节:

1
2
3
4
5
6
7
#git study repo
Creating a new branch is quick.
<<<<<<< HEAD
added this line from master
=======
added this line from branch feature 1
>>>>>>> feature1

Git用<<<<<<<=======>>>>>>>标记出无与分的始末,我们修改如下后保存:

1
2
3
4
#git study repo
Creating a new branch is quick.
added this line from master
added this line from branch feature 1

再提交

1
2
3
$ git add readme.txt
$ git commit -m "conflict fixed"
[master 59bc1cb] conflict fixed

现在,master分支和feature1分段成了产图所示:

Bootstrap 20

之所以带参数的git log也得以看出分支的合情况:

1
2
3
4
5
6
7
8
$ git log --graph --pretty=oneline
*   feedd786cad3e18323a41846fcc1b0d52fc0c98e fix conflict
|\ 
| * 01f8f8d168e113fac9fbe24c4cfa6d4c351a9821 update from branch
* | 743ccee30f3d74f1993f17e7312032b7399b1306 from master
|/ 
* edfbc29982927236596539e0f1971b0575f803c0 branch test
* 8675486bfeeb340914369e80d2cfcf3e854e88a3 add home page

  

9.3 分支策略

当实质上付出中,我们理应以几独着力尺度开展分层管理:

首先,master分应该是充分平静之,也即是独用来公布新本子,平时休能够以方干活;

那在啊干活为?干活都于dev分层上,也就是说,dev旁是未稳定之,到某个时段,比如1.0版本发布时,再把dev支行合并到master上,在master分段发布1.0本;

公同而的同伙们每个人都于dev子上干活,每个人犹生和好之分支,时不时地为dev分段上联合就得了。

于是,团队合作之分层看起便像这样:

Bootstrap 21

 

 

9.4 bug分支  

软件开发中,bug就如一般便饭一样。有了bug就用修补,在Git中,由于分是这样之精,所以,每个bug都可以经过一个初的即分段来修补,修复后,合并分支,然后拿临时分段删除。

当你收到一个修复一个代号101底bug的任务时,很自然地,你想创造一个分issue-101来修复它,但是,等等,当前正在dev齐展开的做事还无交到:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ git status
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#

  

连无是公莫思付出,而是工作才进行到一半,还没法交付,预计得还亟需1上时间。但是,必须以少只钟头外修复该bug,怎么惩罚?

多亏,Git还提供了一个stash功效,可以拿当前工作现场“储藏”起来,等以后恢复现场后连续做事:

1
2
3
$ git stash
Saved working directory and index state WIP on dev: 6224937 add merge
HEAD is now at 6224937 add merge

现在,用git status查工作区,就是穷之(除非有没有来于Git管理的文书),因此得以放心地开创分支来修复bug。

先是确定要以哪个分支上修复bug,假定需要在master支行上修复,就于master创建临时分段:

1
2
3
4
5
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
$ git checkout -b issue-101
Switched to a new branch 'issue-101'

今日修复bug,需要把“Git is free software …”改吗“Git is a free software
…”,然后交给:

1
2
3
4
$ git add readme.txt
$ git commit -m "fix bug 101"
[issue-101 cc17032] fix bug 101
 file changed, 1 insertion(+), 1 deletion(-)

修复好后,切换到master支行,并完成合并,最后去issue-101分支:

1
2
3
4
5
6
7
8
9
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 2 commits.
$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt |    2 +-
 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-101
Deleted branch issue-101 (was cc17032).

  

太硬了,原计划少独小时的bug修复只花费了5分钟!现在,是时刻随着回到dev子干活了!

1
2
3
4
5
$ git checkout dev
Switched to branch 'dev'
$ git status
# On branch dev
nothing to commit (working directory clean)

  

工作区是根的,刚才之干活现场存到哪去了?用git stash list一声令下看看:

1
2
$ git stash list
stash@{0}: WIP on dev: 6224937 add merge

做事现场还当,Git把stash内容是有地方了,但是得恢复一下,有个别单艺术:

一是用git stash apply光复,但是还原后,stash内容并无去,你要用git stash drop来删除;

任何一样栽方法是故git stash pop,恢复的还要把stash内容也抹了:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ git stash pop
# On branch dev
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   hello.py
#
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   readme.txt
#
Dropped refs/stash@{0} (f624f8e5f082f2df2bed8a4e09c12fd2943bdd40)

再用git stash list翻看,就看不到任何stash内容了:

1
$ git stash list

若得数stash,恢复的下,先用git stash list翻开,然后还原指定的stash,用命令:

1
$ git stash apply stash@{0}

 

  

 

10. 几近总人口搭档  

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

假使查阅远程库底音讯,用git remote

1
2
$ git remote
origin

或者,用git remote -v展示更详实的消息:

1
2
3
$ git remote -v
origin  git@github.com:triaquae/gitskills.git (fetch)
origin  git@github.com:triaquae/gitskills.git (push)  

地方显示了好抓取和推送的origin的地点。如果没有推送权限,就看不到push的地方。

10.1 推送分支

推送分支,就是拿欠分上的具有地方提交推送至远程库。推送时,要指定地方分支,这样,Git就见面拿该支行推送到远程库对应的长途分支上:

1
$ git push origin master

如果假定推送其他分支,比如dev,就改成:

1
$ git push origin dev

唯独,并无是大势所趋要将地方分支为远程推送,那么,哪些分支需要推送,哪些不待吗?

  • master分是主分支,因此若时时与长途同步;

  • dev支行是支付分支,团队有所成员还急需在面工作,所以也急需与长途同步;

  • bug分支只用于在当地修复bug,就没必要推到远程了,除非老板要看您每周到底修复了几乎独bug;

  • feature分支是否有助于到长途,取决于你是不是与你的同伙合作以地方开发。

总的说来,就是在Git中,分支完全好在地面自己藏着玩,是否推送,视若的心气而早晚!

10.2 抓到手分支

大抵人合作时,大家都见面为masterdev分段上推送各自的改动。

而今,模拟一个你的小伙伴,可以于其它一样令微机(注意要管SSH
Key添加到GitHub)或者千篇一律台计算机的任何一个目下仿制:

1
2
3
4
5
6
7
$ git clone git@github.com:triaquae/gitskills.git
Cloning into 'gitskills'...
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (7/7), done.
remote: Total 16 (delta 0), reused 10 (delta 0), pack-reused 0
Receiving objects: 100% (16/16), done.
Checking connectivity... done.

当您的伴侣从远程库clone时,默认情况下,你的伴儿只能观地方的master子。不信教可以据此git branch命令看看:

1
2
$ git branch
* master

如今,你的同伙要当dev分层上开,就必创造远程origindev旁到地头,于是他之所以此命令创建本地dev分支:

1
$ git checkout -b dev origin/dev

今,他就足以以dev高达持续修改,然后,时不时地将dev分支push到远程:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ git add .
$ git commit -m "small updates"
 
[dev f1b762e] small updates
 2 files changed, 5 insertions(+), 1 deletion(-)
Alexs-MacBook-Pro:gitskills alex$ git push origin dev
Counting objects: 4, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 438 bytes | 0 bytes/sdone.
Total 4 (delta 0), reused 0 (delta 0)
To git@github.com:triaquae/gitskills.git
   33ec6b4..f1b762e  dev -> dev

  

你的伙伴就向origin/dev分支推送了外的付出,而恰恰你吧本着同的文书作了修改,并意欲推送:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ git add .
$ git commit -m "add Dog class"
[dev 7e7b1bf] add Dog class
 2 files changed, 7 insertions(+)
 
 
$ git push origin dev
 
To git@github.com:triaquae/gitskills.git
 ! [rejected]        dev -> dev (fetch first)
error: failed to push some refs to 'git@github.com:triaquae/gitskills.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again. #提示你了,先把远程最新的拉下来再提交你的
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

推送失败,因为你的同伙的新式提交和您准备推送的交付有冲突,解决办法也够呛粗略,Git已经提醒我们,先用git pull拿新型的付由origin/dev通缉下去,然后,在本地合并,解决冲突,再推

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$ git pull
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 4 (delta 0), reused 4 (delta 0), pack-reused 0
Unpacking objects: 100% (4/4), done.
From github.com:triaquae/gitskills
   33ec6b4..f1b762e  dev        -> origin/dev
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
See git-pull(1) for details.
 
    git pull <remote> <branch>
 
If you wish to set tracking information for this branch you can do so with:
 
    git branch --set-upstream-to=origin/<branch> dev

git pull否破产了,原因是从来不点名地方dev子和长途origin/dev支行的链接,根据提示,设置devorigin/dev的链接:

1
2
$ git branch --set-upstream-to=origin/dev dev
Branch dev set up to track remote branch dev from origin.

再pull:

1
2
3
4
5
6
$ git pull
Auto-merging hello.py
CONFLICT (content): Merge conflict in hello.py
Auto-merging branch_test.md
CONFLICT (content): Merge conflict in branch_test.md
Automatic merge failed; fix conflicts and then commit the result.

这回git pull得逞,但是合并有冲突,需要手动解决,解决之不二法门与支行管理面临的缓解冲突完全一致。解决后,提交,再push:  

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ git add .
$ git commit -m "merge & fix hello.py"
[dev 93e28e3] merge & fix hello.py
 
$ git push origin dev
 
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 819 bytes | 0 bytes/sdone.
Total 8 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), done.
To git@github.com:triaquae/gitskills.git
   f1b762e..93e28e3  dev -> dev

 

从而,多丁搭档的干活模式通常是这么:

  1. 第一,可以计算用git push origin branch-name推送自己之改动;

  2. 一旦推送失败,则以远程分支比你的地面更新,需要先用git pull计较合并;

  3. 如果统一有冲突,则解决冲突,并于地面提交;

  4. 并未冲要解决掉冲突后,再就此git push origin branch-name推送就能够不负众望!

如果git pull提醒“no tracking
information”,则印证地方分支和远程分支的链接关系远非创造,用命令git branch --set-upstream branch-name origin/branch-name

立虽是多总人口搭档的工作模式,一旦熟悉了,就非常简单。

  

  

11. github使用

咱俩直接为此GitHub作为免费的远程仓库,如果是私有的开源项目,放到GitHub上是截然没有问题之。其实GitHub还是一个开源协作社区,通过GitHub,既可以吃旁人参与而的开源项目,也堪与别人的开源项目。

在GitHub出现以前,开源项目开源容易,但吃周边老百姓群众参与进来比较不方便,因为只要参与,就设付代码,而受每个思付出代码的大众都开始一个账号那是匪现实的,因此,群众啊唯有限于报个bug,即使能够转少bug,也只能拿diff文件用邮件发过去,很无便利。

只是于GitHub上,利用Git极其强大的仿造和支行功能,广大人民大众真正得以率先软自由与各种开源项目了。

哪参与一个开源项目也?比如人气最高的bootstrap项目,这是一个挺强劲的CSS框架,你得拜它的色主页https://github.com/twbs/bootstrap,点“Fork”就在协调的账号下仿制了一个bootstrap仓库,然后,从友好的账号下clone:

1
git clone git@github.com:michaelliao/bootstrap.git

一定要起友好的账号下clone仓库,这样你才会推送修改。如果由bootstrap的作者的库房地址git@github.com:twbs/bootstrap.git克隆,因为从没权限,你以不可知推送修改。

Bootstrap的法定仓库twbs/bootstrap、你当GitHub上克隆的库房my/bootstrap,以及你协调克隆到地头电脑的库,他们之关联就像下图显示的那么:

Bootstrap 22

 

比方你想修复bootstrap的一个bug,或者新增一个功能,立刻就可以开始工作,干了晚,往团结之仓库推送。

设你要bootstrap的官方库能经受而的改,你便可以以GitHub上提倡一个pull
request。当然,对方是否受而的pull request就非肯定了。

一经您无能力修改bootstrap,但同时想如果跃跃欲试一将pull
request,那就算Fork一下己的库房:https://github.com/triaquae/gitskills ,创建一个your-github-id.txt的文件文件,写点自己读书Git的经验,然后推送一个pull
request给自家,我会视心情而定是否受。

小结

  • 以GitHub上,可以任意Fork开源仓库;

  • 祥和抱有Fork后的库房的诵读写权限;

  • 得推送pull request给合法仓库来贡献代码。

  

  

12. 忽略特殊文件.gitignore

稍加上,你必须将某些文件放到Git工作目录中,但以无能够交到其,比如保留了数据库密码的部署文件啦,等等,每次git status且见面显Untracked files ...,有强迫症的童鞋心里一定不爽。

哼于Git考虑到了豪门之感触,这个题目迎刃而解起来呢坏粗略,在Git工作区的清目录下开创一个异常的.gitignore文本,然后将要不经意的文件名填进去,Git就见面自动忽略这些文件。

非欲开始写.gitignore文件,GitHub已经为我们准备了各种配置文件,只待做一下就算可利用了。所有配置文件可以一直在线浏览:https://github.com/github/gitignore

大意文件的尺码是:

  1. 忽视操作系统自动生成的文本,比如缩略图等;
  2. 疏忽编译生成的中档文件、可执行文件等,也尽管是如一个文书是经另外一个文书自动生成的,那自动生成的公文就从来不必要放上版本库,比如Java编译产生的.class文件;
  3. 大意你协调的含有敏感信息之布局文件,比如存放口令的布置文件。

推个例证:

一经你以Windows下展开Python开发,Windows会自动在发出图表的目录下转移隐藏的缩略图文件,如果生起定义目录,目录下虽会来Desktop.ini文本,因此你要忽略Windows自动生成的垃圾文件:

1
2
3
4
# Windows:
Thumbs.db
ehthumbs.db
Desktop.ini

接下来,继续忽略Python编译产生的.pyc.pyodist等于文件或者目录:

1
2
3
4
5
6
7
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

加上你协调定义的文件,最终取得一个完好无缺的.gitignore文本,内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 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

运Windows的童鞋注意了,如果你于资源管理器里新建一个.gitignore文本,它会大弱智地唤醒您得输入文件称,但是于文本编辑器里“保存”或者“另存为”就可管文件保留也.gitignore了。

粗时候,你想补加一个文件及Git,但意识加上非了,原因是者文件给.gitignore忽略了:

1
2
3
4
$ git add App.class
The following paths are ignored by one of your .gitignore files:
App.class
Use -f if you really want to add them.

只要您实在想补加该文件,可以据此-f强制添加到Git:

1
$ git add -f App.class

抑或你意识,可能是.gitignore写得生题目,需要摸索出来到底孰规则写错了,可以为此git check-ignore指令检查:

1
2
$ git check-ignore -v App.class
.gitignore:3:*.class    App.class  

Git会告诉我们,.gitignore的第3尽规则忽略了拖欠公文,于是我们便可以掌握应修订哪个规则。

小结

  • 大意某些文件时,需要编制.gitignore

  • .gitignore文件本身要搁版本库里,并且可本着.gitignore开版本管理!

  

  

  

以上文章大量参阅或转载自: http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000
 

相关文章