文件的内容和文件名后缀是没有必然联系的,我们可以随意更改文件名的后缀,但文件内容不会发生改变。即使在windows下,也可以用文本编辑器打开任意一个文件查看其内容,但内容是不是human readable就另当别论了。git内部存储文件时用zlib压缩起来,生成blob文件。至于你说的识别不了的”情况,在你双击一个文件的时候,系统会根据文件的后缀名,去某个map中寻找要运行哪个程序来加载这个文件。譬如你创建一个xxx.txt,双击下,默认用记事本打开了。然后把文件名改成xxx.iii,再双击,就说无法开启了。因为在那个map里没有iii和对应的程序。如果你直接打开记事本,然后把这个iii文件拖进去,看它能不能打开。还是能打开的嘛。再双击,被告知无法开启,那就选择从已安装的程序清单里选取,如果把永远用选取的程序来打开这种文件,就相当于在map里添加了一条,以后就用记事本打开。

Git工作原理

按照官方文档的描述,Git是这样定义的

.git目录是Git的核心,每一个变动都会存储在.git文件夹中,Git的相关命令本质上也是读取.git文件夹下的内容
.git目录下有几个重要的文件/文件夹

提交和文件是Git中的主要组成,也叫git对象,Git中的许多命令都和git对象有关
git对象分为下面3类

git对象存储在.git目录下的objects文件夹中,Git会将git对象压缩成二进制文件,git对象的文件名即sha-1算法得到的hash值,按照2/38的形式保存(前两位是文件夹的名称,剩下38位是文件名,这样做可以防止文件夹的内容过多,提高查找效率)

对于commit对象,hash值也被称为commitid

可以使用以下命令查看git对象中的内容

git cat-file -p <hash>

通过查看三种git对象的内容,不难发现如下的组织关系

其实可以吧hash看成每个对象的指针,Git通过指针将众多git对象串联起来,来实现对项目的版本控制

用户通过Git命令读写.git文件夹,达到获取信息或变更版本的目的

Git一开始被设计成供VCS使用的工具集合而不是一整套用户有好的VCS,它还包含了许多的底层命令,一般被称为plumbing命令(底层命令),而用户日常使用Git命令被称为porcelain命令(高层命令),porcelain命令实际是是对plumbing命令的封装

一次完整的提交过程会包含如下过程

使用porcelain命令的话是非常简单的

如果使用plumbing命令就会复杂很多,但是可以更好地理解其背后的工作原理

通过前文的内容不难发现,每次生成的commit对象会包含上一个commit对象的hash,即当前的commit包含上一个commit的指针,许多个commit对象串联起来就形成了分支

所以,Git的分支本质上是指向commit对象的可变指针

而HEAD代表当前commit的指向,.git/refs/heads/<branchname>文件的内容就是该commit对象的hash

怎样查看git本地仓库所有文件目录

工具/原料 Git-2.8.1-64-bit or Git-2.8.1-32-bit windows 8 方法/步骤 安装好Git工具后,找到桌面或者win8的开始菜单下找到Git Bash 快捷方式 选中Git Bash图标,右键,选中“属性”,打开如图: 去掉--cd-to-home,修改“起始位置”为自定义的git ...

Git如何检出指定目录或文件

1、git init (初始化git,生成.git文件)

2、git config core.sparsecheckout true (打开 sparse checkout(稀疏检出)开关,如果要关闭稀疏检出,要重置为false即可)

3、git xx >> .git/info/sparse-checkout  (xx为配置检出的git远程仓库的文件夹)

4、git remote -v  (列出详细信息,在每一个名字后面列出其远程url)

5、git remote add origin http://xxxx (配置远程仓库路径)

6、git pull origin master (检出该远程仓库下的指定目录或文件)

1、cat .git/info/sparse-checkout (查看指定目录或文件是否配置成功)

2、config --list(查看 sparse checkout(稀疏检出)开关 是否打开)

1、git config core.sparsecheckout false

2、rm -rf .git/info/sparse-checkout  (移除 .git/info/sparse-checkout 文件)

到此所有操作完成

感谢原文 Git如何检出指定目录或文件 - liangzai_cool的主页

git的文件系统与底层原理

由于工作中使用git作为版本管理,之前对git的了解不多,特别是底层方面的原理方面的知识。为了能更好的使用git,有必要学习并梳理下相关知识。

步入正题:

执行git init 初始化后,会在.git文件夹下会创建多个目录,每个文件夹功能划分的很清晰。

Git 是一套内容寻址文件系统.通过键值对的方式存储和查找。

下面操作一遍,直观的看到整个过程,以便理解。

参考: https://git-scm.com/docs/git-hash-object

参考: http://man.linuxde.net/find

可以见到文件名称为数字和字母组成的字符串。这个是根据文件内容和头信息(Header),通过SHA-1算法计算得出的40位十六进制校验和。

SHA-1是一种加密哈希函数(cryptographic hash function)。SHA-1将文件中的内容通过其hash算法生成一个160bit的报文摘要,即40个十六进制数字(每个十六进制数字占4位)。它几乎可以保证,如果两个文件的SHA-1值是相同的,那么它们确是完全相同的内容(类似于生活中的指纹识别);SHA-1主要有两种用途,一个是加密,一个是数据完整性校验。Linux kernel开创者和Git的开发者——Linus说,Git使用了SHA-1并非是为了安全性,而是为了数据的完整性。理论上SHA-1会在2^51攻击下实现哈希碰撞,所以也不是完全的安全。

参考: https://git-scm.com/docs/git-cat-file

模拟bolb对象存储流程

以上,说明了git的数据存储的基本方式。主要步骤:

下面是创建文件,修改文件,恢复文件的相关过程。

git会记录每个版本的修改,根据校验和可恢复到相应的版本。

小结: 这个过程中包括文件创建、文件修改、文件恢复,跟我们平时工作中使用的高级命令功能很相似。git会把整个过程转化为底层操作,同时对用户透明。

相关引用参考:
http://smilejay.com/2012/08/git-commit-sha-1/
https://git-scm.com/book/zh/v1/Git-%E5%86%85%E9%83%A8%E5%8E%9F%E7%90%86-Git-%E5%AF%B9%E8%B1%A1

git中,文件的状态

git中常用的一个命令便是,git status,该命令的作用是查看哪些文件处于什么状态.
可以用 git status 命令查看哪些文件处于什么状态。 如果在克隆仓库后立即使用此命令,会看到类似这样的输出:
echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)

nothing added to commit but untracked files present (use "git add" to track)

在状态报告中,可以看到,出现了一个untracked files文件,readme.未跟踪的文件意味着在之前的快照(提交)中没有这些文件,git不会自动的将这些文件纳入可追踪的范围,除非需要明确的指出我要跟踪做这些文件.此时,可以执行:
git add readme.txt
再运行git status
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: README
可以看到readme文件处于被追踪的状态中,是被暂存的状态.但是仍然没有commit.

此时,如果我们做了修改,对于一个被追踪的文件,进行了修改,如果你修改了一个CONTRIBUTING.md的已经被追踪的文件,然后运行:
git status
则会出现以下内容:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

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)

意思为: 名为CONTRIBUTING.md已经跟踪的文件发生了变化.但是还没有被放入暂存区,如需要暂存本次修改,需要运行git add命令.
git add命令是一个多命令,可以使用将其从未追踪文件变为已追踪文件,还可以将已追踪文件未修改的内容,变为已追踪文件暂存.还能用户合并时将冲突文件标记为已解决的状态等.
此时,运行git status输出为:
git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

可以看到,此时输出的意思为:两个文件都已经暂存,在下次commit时,会一起提交到仓库.

假设此时,需要继续在修改CONTRIBUTING.md文件,此时再运行git status命令,会出现:
git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

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)

此时,CONTRIBUTING.md文件同时出现在暂存区和非暂存区,是因为,git add文件只是暂存了上次执行git add命令时文件的暂存,如若继续暂存,需要继续运行git status
git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

如果我们需要查看当前工作区文件和暂存区文件的差异,可以使用git diff命令.若要查看已暂存的将要添加到下次提交里的内容,可以用 git diff --staged 命令。 这条命令将比对已暂存文件与最后一次提交的文件差异.

此时,可以进行commit,进行提交啦.现在的暂存区已经准备就绪,可以提交了。 在此之前,请务必确认还有什么已修改或新建的文件还没有 git add 过, 否则提交的时候不会记录这些尚未暂存的变化。 这些已修改但未暂存的文件只会保留在本地磁盘。 所以,每次准备提交前,先用 git status 看下,你所需要的文件是不是都已暂存起来了, 然后再运行提交命令 git commit.

现在你已经创建了第一个提交! 可以看到,提交后它会告诉你,当前是在哪个分支(master)提交的,本次提交的完整 SHA-1 校验和是什么(463dc4f),以及在本次提交中,有多少文件修订过,多少行添加和删改过。

提交记录的是放在暂存区域的快照.任何还未暂存的文件仍然保持已修改的状态,可以在下次提交时纳入版本管理,每次运行一次git commit都是对项目做一次快照,以后可以回到这个状态,或者进行比较.

跳过使用暂存区域
尽管使用暂存区域的方式可以静心准备要提交的细节,但是,有个问题就是繁琐,git提供了一个暂存区域的方式,只要提交的时候,git commit -a,则git会将已经跟踪过的文件暂存起来一起提交.从而省略一次git add,省略的步骤是,将那些已被追踪的文件改为暂存.这是因为 -a 选项使本次提交包含了所有修改过的文件。 这很方便,但是要小心,有时这个选项会将不需要的文件添加到提交中。

查看git提交历史,使用git log命令.会出现下面输出:
$ git log
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon schacon@gee-mail.com
Date: Mon Mar 17 21:52:11 2008 -0700

commit 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
Author: Scott Chacon schacon@gee-mail.com
Date: Sat Mar 15 16:40:33 2008 -0700

commit a11bef06a3f659402fe7563abf99ad00de2209e6
Author: Scott Chacon schacon@gee-mail.com
Date: Sat Mar 15 10:31:28 2008 -0700

在不传入任何参数的前提下,git log会按照时间顺序列出所有的提交,按照时间顺序倒排,commit之后是每次提交的SHA-1校验和(是一个十六位的长度为四十的哈希值),以及作者信息和提交说明.

git的基本使用

git 采用的是分布式仓库,本地和远程仓库都是一个包含完整记录的仓库,如果某一处被格式化了,还以从另一个仓库获取,并不会有大影响(只要之前进行了同步仓库)。git 可以在断网的情况下,提交到本地仓库,之后联网再推到远程仓库。每次提交或者保存,git都会记录下所有文件状态,若未改变的文件,git不会再次存储,只会链接到之前已经存储的文件。

git文件一共有四种状态:

以下为git中存在的,并在跟踪的

创建本地.gitignore

创建一个global .gitignore

指定仓库排除

参考 Ignoring files

这里遇到一个问题:当我不修改系统默认的提交信息时(或者只是换行不输入任何信息),然后关掉编辑器会出现提交不成功,并会提示
Aborting commit due to empty commit message.

解决方法 :必须输入新的提交信息,即在原来的基础上,至少要加入新的行数据。

git rm \*~ 删除所有以~这个结尾的文件

限定输出

更多限定
Table 3. Options to limit the output of git log

参考至: Git Basics - Undoing Things

`eg

$ git commit -m 'initial commit'

$ git add forgotten_file

$ git commit --amend`

展示仓库名

fetch、pull、push

(==注==:origin 是用git clone到本地之后,自动命名,如果在你push之前,有人先push了,那么push会失败,必须fetch下来合并,并且运行起来,才能在push)

指定一个提交(commit)点作为tag,并不保存额外的信息、

包含tagger 名字、邮箱、日期、tagging msg等信息

-m 指定标记消息,若没有,系统会自动采用默认的编辑器

给之前提交(commit)加上tag

分享tags
默认情况下,git push 并不会将本地的tag,push到远程服务器上,用以下两个命令行推到远程仓库上

检出Tags
必须新建一个分支,然后将要检出的tags,指定到这新分支上

为了是命令更简单、更容易明白和操作,可以给命令添加别名如下:

运行的时候直接打 git ci可以

可视化命令 gitk

如何用git命令行查看隐藏文件

首先确保你的本地git工作目录下已经增加了远程分支了使用gitremote-v查看。如果没有则先使用gitremoteadd命令添加一个(假设名为origin,分支为master)。如果已经有了,则使用gitpushoriginmaster命令提交当前工作目录下的分支到远程master分支

如何使用 Git 和 GitHub

以前因为觉得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版本库里添加的时候,是分两步执行的:
第一步是用git add把文件添加进去,实际上就是把文件修改添加到暂存区;
第二步是用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 add再git 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软件开发公司www.xiupin365.net软件开发公司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是分布式版本控制系统,同一个Git仓库,可以分布到不同的机器上。怎么分布呢?最早,肯定只有一台机器有一个原始版本库,此后,别的机器可以“克隆”这个原始版本库,而且每台机器的版本库其实都是一样的,并没有主次之分。
实际情况往往是这样,找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交。
完全可以自己搭建一台运行Git的服务器,不过现阶段,为了学Git先搭个服务器绝对是小题大作。好在这个世界上有个叫GitHub的神奇的网站,从名字就可以看出,这个网站就是提供Git仓库托管服务的,所以,只要注册一个GitHub账号,就可以免费获得Git远程仓库。
在继续阅读后续内容前,请自行注册GitHub账号。由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的,所以,需要一点设置:
创建SSH Key。在用户目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key,输入命令ssh-keygen -t rsa -C "youremail@example.com",你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。
登陆GitHub,打开“Account settings”,“SSH Keys”页面.然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容:
点“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仓库。

如何查看git远程仓库中的文件

首先,我们打开自己的本地GIT仓库,在根目录下右击鼠标,选择git bash选项。
怎样从本地删除git远程仓库里面的文件
进入到我们的git命令行页面后,先将远程代码pull到本地,保持本地仓库跟远端仓库同步。
怎样从本地删除git远程仓库里面的文件
然后我们使用git rm命令删掉要删除的文件。具体命令是 git rm 文件名,大家可以把rm当做remove的缩写,方便记忆
怎样从本地删除git远程仓库里面的文件
删除之后,本地目录下已经删除的文件夹就不再存在了,为了能将远程仓库的相应文件也删除掉,我们要把这次操作提交到上去,git commit -m "for test"
怎样从本地删除git远程仓库里面的文件
可以看到代码中显示我们删掉了README文件,然后将更改push到远程,git push,
怎样从本地删除git远程仓库里面的文件
6
我们根据上图的结果可以看到一个操作已经成功提交到远程仓库了。

Git的存储机制

答:
git在正确的抽象层次上处理存储空间压缩,使得程序比上代(如svn)和同时代(如bzr)的VCS大为简化。

之前的VCS从节省空间出发,想当然地把delta作为基础数据结构。这样的最大问题(远不是唯一问题)是:delta设计时没有考虑到的修改方式就无法表达。例如,svn早期版本及更早的VCS不能记录文件rename/copy,所以只要重命名文件,列出历史时重命名之前的历史就显示不出来。

git的存储层(plumbing layer)提供的接口里,每个commit都记录完整的目录树。存储空间压缩问题完全在存储层内部解决: