[toc]

0x00 快速入门

描述:Git是目前世界上最先进的分布式版本控制系统(没有之一),如下面的Git生态化流程;

WeiyiGeek.生态化

WeiyiGeek.生态化

Git发展历史:
Git的诞生:很多人都知道,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花了两周时间自己用C写了一个分布式版本控制系统这就是Git!一个月之内,Linux系统的源码已经由Git管理了!牛是怎么定义的呢?
Git迅速成为最流行的分布式版本控制系统,尤其是2008年,GitHub网站上线了,它为开源项目免费提供Git存储,无数开源项目开始迁移至GitHub,包括jQuery,PHP,Ruby等等。
历史就是这么偶然,如果不是当年BitMover公司威胁Linux社区,可能现在我们就没有免费而超级好用的Git了。


那什么是版本控制系统?
答:使用版本控制系统通常还意味着自动帮我记录每次文件的改动,还可以让同事协作编辑,就算你胡来搞砸了整个项目,把文件改的改,删的删,你也可以轻松恢复到原先的样子。这样你就结束了手动管理多个“版本”的史前时代,进入到版本控制的20世纪。

如果不使用版本控制系统?

  • 如果你用Microsoft Word写过长篇大论,那你一定有这样的经历:想删除一个段落,又怕将来想恢复找不回来怎么办?有办法,先把当前文件“另存为……”一个新的Word文件,再接着改,改到一定程度,再“另存为……”一个新文件,这样一直改下去回相当的痛苦;
  • 例如:过了一周,你想找回被删除的文字,但是已经记不清删除前保存在哪个文件里了,只好一个一个文件去找,真麻烦。看着一堆乱七八糟的文件,想保留最新的一个,然后把其他的删掉,又怕哪天会用上,还不敢删,真郁闷。更要命的是,有些部分需要你的财务同事帮助填写,于是你把文件Copy到U盘里给她(也可能通过Email发送一份给她),然后你继续修改Word文件。一天后同事再把Word文件传给你,此时你必须想想,发给她之后到你收到她的文件期间,你作了哪些改动,得把你的改动和她的部分合并,真困难。


为什么不选择SVN而选择GIT
答:说到这里不得不提到集中式vs分布式的分别对比;
Linus一直痛恨的CVS、SVN都是集中式的版本控制系统(Centralized Version Control Systems,简称 CVCS ),而Git、BitKeeper、Mercurial和Bazaar是分布式版本控制系统;

  • 集中式版本控制系统
    • CVS(是一个C/S系统,是一个常用的代码版本控制软件,主要在开源软件管理中使用,与它相类似的代码版本控制软件有subversion)作为最早的开源而且免费的集中式版本控制系统。由于CVS自身设计的问题,会造成提交文件不完整,版本库莫名其妙损坏的情况。同样是开源而且免费的SVN修正了CVS的一些稳定性问题,是目前用得最多的集中式版本库控制系统。
    • 除了免费的外,还有收费的集中式版本控制系统,比如IBM的ClearCase(以前是Rational公司的,被IBM收购了),特点是安装比Windows还大,运行比蜗牛还慢,能用ClearCase的一般是世界500强,他们有个共同的特点是财大气粗,或者人傻钱多。
    • 微软自己也有一个集中式版本控制系统叫VSS,集成在Visual Studio中。由于其反人类的设计,连微软自己都不好意思用了。
  • 分布式版本控制系统
    • 除了Git以及促使Git诞生的BitKeeper外,还有类似Git的Mercurial和Bazaar等。这些分布式版本控制系统各有特点,但最快、最简单也最流行的依然是Git!

集中式和分布式版本控制系统有什么区别呢?
先说集中式版本控制系统,版本库是集中存放在中央服务器的,而干活的时候,用的都是自己的电脑,所以要先从中央服务器取得最新的版本,然后开始干活,干完活了,再把自己的活推送给中央服务器。
比如:中央服务器就好比是一个图书馆,你要改一本书,必须先从图书馆借出来,然后回到家自己改,改完了再放回图书馆。

  • 集中式版本控制系统最大的毛病就是必须联网才能工作,如果在局域网内还好,带宽够大,速度够快,可如果在互联网上,遇到网速慢的话,可能提交一个10M的文件就需要5分钟,这还不得把人给憋死啊。
    WeiyiGeek.集中版本

    WeiyiGeek.集中版本

那分布式版本控制系统与集中式版本控制系统有何不同呢?

  • 首先,分布式版本控制系统根本没有“中央服务器”,每个人的电脑上都是一个完整的版本库,这样,你工作的时候,就不需要联网了,因为版本库就在你自己的电脑上。
    既然每个人电脑上都有一个完整的版本库,那多个人如何协作呢?
  • 比方说你在自己电脑上改了文件A,你的同事也在他的电脑上改了文件A,这时你们俩之间只需把各自的修改推送给对方,就可以互相看到对方的修改了。
  • 和集中式版本控制系统相比,分布式版本控制系统的安全性要高很多,因为每个人电脑里都有完整的版本库,某一个人的电脑坏掉了不要紧,随便从其他人那里复制一个就可以了。而集中式版本控制系统的中央服务器要是出了问题,所有人都没法干活了。

在实际使用分布式版本控制系统的时候,其实很少在两人之间的电脑上推送版本库的修改,因为可能你们俩不在一个局域网内,两台电脑互相访问不了,也可能今天你的同事病了,他的电脑压根没有开机。因此,分布式版本控制系统通常也有一台充当“中央服务器”的电脑,但这个服务器的作用仅仅是用来方便“交换”大家的修改,没有它大家也一样干活,只是交换修改不方便而已。

WeiyiGeek.分布式

WeiyiGeek.分布式

当然Git的优势不单是不必联网这么简单,后面我们还会看到Git极其强大的分支管理,把SVN等远远抛在了后面。


远程仓库平台介绍

GitHub
Git[1] 是由 Linux Torvalds 开发[2]的一个版本控制系统,现如今正在被全世界大量开发者使用。许多公司喜欢使用基于 Git 版本控制的 GitHub 代码托管。根据报道,GitHub 是现如今全世界最大的代码托管网站[3]

GitHub 的用处很多通常我们可以用来做以下的事情:
(1).代码托管:方便随时随地同步代码,再也不用带着U盘到处跑了。
(2).学习优秀的开源项目:减少重复造轮子的时间,学习其他人的优秀设计思想、实现方式。
(3).多人协作:同一个项目多人协作开发,发挥每个人擅长的部分。
(4).搭建博客、个人网站或者公司官网:可以为项目建立静态主页, 也可以建立命名特殊的 Repository 来建立个人静态网站,不用忍受各大博客网站的约束与各式各样的广告。
(5).个人简历:如果你在Github上很活跃,维护有自己的开源项目,那么你找工作将是一个非常大的优势,现在程序员的招聘很多公司都很看中你 GitHub 账号,某种意义上 GitHub 就可以算是你的简历了
(6).其他:GitHub 能做的远不止这些,比如用来做数据存储、预览3D渲染文件、社交平台等,主要是看你想如何去使用它。

①GitHub是一个免费的远程仓库,可以把代码放到GitHub存储。
②GitHub还是一个开源协作社区,通过GitHub,既可以让别人参与你的开源项目,也可以参与别人的开源项目。简单点就是把代码托管到网上。
③同时也能star喜欢的项目,fork并pull为他人项目打补丁、还能配合hexo做个人博客等等。


0x01 git 安装

最早Git是在Linux上开发的,很长一段时间内,Git也只能在Linux和Unix系统上跑;现在Git可以在Linux、Unix、Mac和Windows这几大平台上正常运行了。

1
2
3
4
5
6
7
8
9
10
#linux安装
sudo apt-get install git
sudo yum install git

#MAC安装
第一种方法:官网下载(https://git-scm.com/download/mac),界面化安装
第二种方法:更简单也是推荐的方法,就是直接从AppStore安装Xcode,Xcode集成了Git,不过默认没有安装,你需要运行Xcode,选择菜单“Xcode”->“Preferences”,在弹出窗口中找到“Downloads”,选择“Command Line Tools”,点“Install”就可以完成安装了。

#Windows安装
选择系统位数安装:https://git-scm.com/download/win

安装完成后,在开始菜单里找到“Git”->“Git Bash”,蹦出一个类似命令行窗口的东西,就说明Git安装成功!

1.yum安装最新版

Step1.启用Wandisco GIT存储库 启用存储库需要在/etc/yum.repos.d/目录中命名的新yum存储库配置文件:

1
2
3
4
5
6
7
8
9
10
11
cat > /etc/yum.repos.d/wandisco-git.repo <<END
[wandisco-git]
name=Wandisco GIT Repository
baseurl=http://opensource.wandisco.com/centos/7/git/$basearch/
enabled=1
gpgcheck=1
gpgkey=http://opensource.wandisco.com/RPM-GPG-KEY-WANdisc
END

#导入存储库GPG密钥
sudo rpm --import http://opensource.wandisco.com/RPM-GPG-KEY-WANdisco

Step2.更新或者删除最新版本的git

1
2
yum install -y git 
yum update -y git


2.编译安装最新版

Step1.安装使用yum安装需要用到的依赖包

1
2
3
4
5
yum install -y wget
yum install gcc
yum install gcc-c++
yum install -y zlib-devel
yum install -y perl-ExtUtils-MakeMaker package

Step2.去官网仓库下载最新的Git版本git-2.18.0

1
wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.18.0.tar.gz

Step3.解压、配置编译安装

1
2
3
4
tar -zxvf git-2.18.0.tar.gz
cd git-2.18.0
./configure --prefix=/usr/local/git
make && make install

Step4.配置全局环境变量PATH

1
2
3
echo "export PATH=$PATH:/usr/local/git/bin">>/etc/bashrc
source /etc/bashrc
git --version

Step5.如果使用 git --version 命令查看的git版本不是自己安装的版本的话,卸载不是自己安装的Git, 然后重新生效下环境变量就可以了。

1
2
3
sudo yum remove git
source /etc/bashrc
git --version

补充说明:


0x02 git初始化配置

因为Git是分布式版本控制系统,所以每个机器都必须自报家门:所有需要设置提交用户以及用户邮箱

1
2
3
4
5
6
7
8
9
10
11
12
13
# git命令帮助
$ git config --help 或者 git help config 或者 man git-config

# 表示你这台机器上所有的Git仓库都会使用这个配置,当然也可以对某个仓库指定不同的用户名和Email地址。
$ git config --global user.name "WeiyiGeek" #设置协同者信息
$ git config --global user.email "[email protected]"
$ git config --global --add user.name "WeiGeek" #可以添加姓名
$ git config --global --unset user.name "WeiGeek" #也可以删除姓名

$ git config --list #显示所有配置
$ git config --global --list # 显示全部用户(是不是设置成功)
[email protected]
user.name=Weiyigeek

WeiyiGeek.配置信息

WeiyiGeek.配置信息

别名设置:
有没有经常敲错命令?比如git status?status这个单词真心不好记。
如果敲git st就表示git status那就简单多了,当然这种偷懒的办法我们是极力赞成的。

1
2
3
4
5
6
7
8
9
10
11
12
$ git config --global alias.[别名名称] [原git命令]  #别名设置
$ git config --global alias.st status
$ git config --global alias.co checkout #用co表示checkout,ci表示commit,br表示branch:
$ git config --global alias.ci commit
$ git config --global alias.br branch
$ git config --global alias.unstage 'reset HEAD'
$ 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 st #查看状态查看别名是否生效
$ git ci -m "bala bala bala..." #提交就可以简写
#实用的别名设置

WeiyiGeek.git log案例

WeiyiGeek.git log案例

自定义Git显示颜色,会让命令输出看起来更醒目;Git会适当地显示不同的颜色比如git status命令:

1
$ git config --global color.ui true

远程仓库认证:
实际情况往往是这样,找一台电脑充当服务器的角色,每天24小时开机,其他每个人都从这个“服务器”仓库克隆一份到自己的电脑上,并且各自把各自的提交推送到服务器仓库里,也从服务器仓库中拉取别人的提交;
比如:Github网站为了方便了我们进行代码的上传和拉取私有的仓库版本,我们需要对其登录认证,由于你的本地Git仓库和GitHub仓库之间的传输是通过SSH加密的;

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

第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。
如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:

1
2
$ ssh-keygen -t rsa -C "[email protected]"
$ ssh-keygen -t rsa -C "[email protected]" -p #设置密匙登录的密码(对于保密性比较强的项目或者部门)

成功后在用户主目录里找到.ssh目录,里面有id_rsa和id_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面,然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴我们上面生成的id_rsa.pub文件的内容,点“Add Key”,你就应该看到已经添加的Key;

WeiyiGeek.添加公匙到远程仓库中

WeiyiGeek.添加公匙到远程仓库中

STEP3: Testing your SSH connection

1
ssh -T [email protected]


0x03 仓库初始化

常用的远程仓库管理平台:

方式1:(本地已有开发项目,在github新建立仓库并上传-先有本地库,后有远程库的时候,如何关联远程库)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#方式1
$ git init [repositoryName] #项目Repository
$ git init learngit

#方式2
$ git init --bare [repo-name] #创建一个裸目录不生成.git
$ git init #生成.git目录

$ git remote #列出所有远程仓库
$ git remote add origin [email protected]:weiyigeek/learngit.git
#git pull origin master
$ git add . #添加修改的文件
$ git commit -m "Project first commit"
$ git push -u origin master #上传更改到远程服务器

把本地master分支的最新修改推送至GitHub,现在你就拥有了真正的分布式版本库!


方式2:(远程仓库已有项目开发代码,本地进行拉取-远程库克隆)

1
2
3
4
5
6
7
8
9
$ git clone [email protected]:weiyigeek/learngit.git
$ git pull #从远程服务器仓库上拉取项目

#注意:如果本地更改代码与远程仓库中代码不同的话需要进行合并
$ git clone [email protected]:weiyigeek/learngit.git

#获取以远程仓库代码为主覆盖本地仓库的更改
$ git fetch #获取远程仓库的所有分支,以及数据(Update Databases)
$ git fetch --all && git reset --hard origin/master #回到远程仓库的状态:抛弃本地仓库的所有版本(commit),回到远程仓库的状态

总结说明:

  • 实际上Git支持多种协议,默认的git://使用ssh,但也可以使用https等其他协议,通过ssh支持的原生git协议速度最快
  • 使用https除了速度慢以外,还有个最大的麻烦是每次推送都必须输入口令,但是在某些只开放http端口的公司内部就无法使用ssh协议而只能用https。
  • 把文件添加到版本库,所有的版本控制系统,其实只能跟踪文本文件的改动,比如TXT文件,网页,所有的程序代码等等,Git也不例外。而图片、视频这些二进制文件,虽然也能由版本控制系统管理,但没法跟踪文件的变化,只能把二进制文件每次改动串起来,也就是只知道图片从100KB改成了120KB,但到底改了啥,版本控制系统不知道也没法知道。
  • 使用Windows的童鞋要特别注意,千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件,他们自作聪明地在每个文件开头添加了0xefbbbf(十六进制)的字符

0x04 git配置文件

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
$ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
[remote "origin"] #远程库的名字就是origin,这是Git默认的叫法,也可以改成别的,但是origin这个名字一看就知道是远程库。
url = [email protected]:michaelliao/learngit.git
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:WeiyiGeek/blog.git #可以添加多个git仓库,但是拉取的时候自会在第一个仓库进行(常用)
[branch "master"] #本地分支
remote = origin # 指定上传的远程库
merge = refs/heads/master
[alias] #别名就在[alias]后面,要删除别名,直接把对应的行删掉即可。
last = log -1

而当前用户的Git配置文件放在用户主目录下的一个隐藏文件.gitconfig中,配置别名也可以直接修改这个文件,如果改错了可以删掉文件重新通过命令配置。

1
2
3
4
5
6
7
8
9
$ cat .gitconfig
[alias]
co = checkout
ci = commit
br = branch
st = status
[user]
name = Your Name
email = [email protected]


0x05 .gitignore文件

描述:有些时候,你必须把某些文件放到Git工作目录中,但又不能提交它们,比如保存了数据库密码的配置文件啦等等,每次git status都会显示Untracked files,有强迫症的童鞋心里肯定不爽。
在Git工作区的根目录下创建一个特殊的.gitignore文件,然后把要忽略的文件名填进去,Git就会自动忽略这些文件;.gitignore文件本身要放到版本库里,并且可以对.gitignore做版本管理!

  • .gitignore 用于忽略你不想提交到Git上的文件
  • .gitattribute 指定非文本文件的对比合并方式

忽略文件的原则是:

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

.gitignore的通配符:

1
2
3
4
5
*.[ab]   //不提交*.b或者*.b
*.后缀名 //不提交以这个为后缀名(.pyc)
!test.py //不忽略test.py
\!test.py //转意
foo/ //无后缀名文件 (目录)

.gitignore案例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
#(1)举个例子:你在Windows下进行Python开发,Windows会自动在有图片的目录下生成隐藏的缩略图文件,如果有自定义目录,目录下就会有Desktop.ini文件,因此你需要忽略Windows自动生成的垃圾文件:
# Windows: #
Thumbs.db
ehthumbs.db
Desktop.ini

#(2)然后继续忽略Python编译产生的.pyc、.pyo、dist等文件或目录:
# Python:
*.py[cod]
*.so
*.egg
*.egg-info
dist
build

# 加上你自己定义的文件,最终得到一个完整的.git ignore(忽视)文件,内容如下:
# Windows image file caches
Thumbs.db
ehthumbs.db

# Folder config file
Desktop.ini

# Recycle Bin used on file shares
$RECYCLE.BIN/

# Windows Installer files
*.cab
*.msi
*.msm
*.msp

# =========================
# Operating System Files OSX
# =========================
.DS_Store
.AppleDouble
.LSOverride

# Icon must ends with two \r.
Icon
# Thumbnails
._*

# Files that might appear on external disk
.Spotlight-V100
.Trashes

*.py[co]
.idea/

用git check-ignore命令检查.gitignore问题,需要找出来到底哪个规则写错了

1
2
3
4
$ git check-ignore -v .gitignore
$ git check-ignore -v App.class
.gitignore:3:*.class App.class #gitignore的第3行规则忽略了该文件,于是我们就可以知道应该修订哪个规则
$ git config core.fileMode false #关闭Ignore文件的功能

注意事项:

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

0x06 .gitattributes文件

描述:指定非文本文件的对比合并方式,Git的gitattributes文件是一个文本文件,文件中的一行定义一个路径的若干个属性,以行为单位设置一个路径下所有文件的属性,格式如下:

1
2
3
4
5
6
#要匹配的文件模式 属性1 属性2 ...
#在gitattributes文件的一行中,一个属性(以text属性为例)可能有4种状态:
设置text
不设置-text
设置值text=string
未声明通常不出现该属性即可;但是为了覆盖其他文件中的声明,也可以!text

gitattributes文件示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#gitattributes文件中可以定义的属性:
text,控制行尾的规范性 #如果一个文本文件是规范的,则Git库中该文件的行尾总是LF。
* text=auto
*.txt text
*.jpg -text
*.vcproj text eol=crlf
*.sh text eol=lf
*.py eol=lf

#对于工作目录,除了text属性之外,还可以设置eol属性,或core.eol配置变量。
eol #设置行末字符
eol=lf,入库时将行尾规范为LF,检出时禁止将行尾转换为CRLF
eol=crlf,入库时将行尾规范为CRLF,检出时将行尾转换为CRLF 【crlf,已过时,类似于text/windows下默认】
filter #缩进
ident,为路径设置ident属性,路径中的blob对象中的$Id$将会被替换为$Id:char_40_hexadecimal_name
*.c filter=indent #在.gitattributes文件中设置"indent"过滤器过滤*.c文件:

  • 第1行,对任何文件,设置text=auto,表示文件的行尾自动转换。如果是文本文件,则在文件入Git库时,行尾自动转换为LF。如果已经在Git库文件的行尾为CRLF,则该文件在入Git库时,不再转换为LF。
  • 第2行,对于txt文件,标记为文本文件,并进行行尾规范化。
  • 第3行,对于jpg文件,标记为非文本文件,不进行任何的行尾转换。
  • 第4行,对于vcproj文件,标记为文本文件,在文件入Git库时进行规范化,即行尾为LF。但是在检出到工作目录时,行尾自动转换为CRLF。
  • 第5行,对于sh文件,标记为文本文件,在文件入Git库时进行规范化,即行尾为LF。在检出到工作目录时,行尾也不会转换为CRLF(即保持LF)。
  • 第6行,对于py文件只针对工作目录中的文件行尾为LF。

在一个Git库中可以有多个gitattributes文件,不同gitattributes文件中,属性设置的优先级(从高到低)
同一个gitattributes文件中,按照行的先后顺序,如果一个文件的某个属性被多次设置,则后序的设置优先(后覆盖前面);

  • /myproj/info/attributes 文件
  • /myproj/my_path/.gitattributes 文件
  • /myproj/.gitattributes 文件

其他实例:.gitattributes案例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
diff=astextplain | csharp | exif
#*.doc diff=word #直接比较两个不同版本的Word文件

#Git内置的merge驱动:
merge=text | binary | union #whitespace,对应core.whitespace配置变量


# Auto detect text files and perform LF normalization
* text=auto

# Custom for Visual Studio
*.cs diff=csharp
*.sln merge=union
*.csproj merge=union
*.vbproj merge=union
*.fsproj merge=union
*.dbproj merge=union

# Standard to msysgit
*.doc diff=astextplain
*.DOC diff=astextplain
*.docx diff=astextplain
*.DOCX diff=astextplain
*.dot diff=astextplain
*.DOT diff=astextplain
*.pdf diff=astextplain
*.PDF diff=astextplain
*.rtf diff=astextplain
*.RTF diff=astextplain


总结参考:


0x07 基础实例

实例演示:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#初始化仓库
git init test #Git自动为我们创建了唯一一个master分支
Initialized empty Git repository in /mnt/e/githubProject/test/.git/

#在github上建立一个text项目,并且在本地添加一个远程仓库
git remote add origin [email protected]:WeiyiGeek/test.git

#建立测试文件
echo "#test" >> README.md

#添加到工作区
git add README.md
git commit -m "first commit"

##把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。
$ git push -u origin master #会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来

由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。

实例演示2:

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 init test
cd test
#添加一个远程仓库名为gitee,而不是采用默认的origin
git remote add gitee [email protected]:WeiyiGeek/blog.git
#从远程仓库拉取master分支
git pull gitee master
echo "Test FILE" > www.html
git add www.html
git commit -m "test upload"
# 设置上传的远程仓库名称与分支 (只需要设置一次即可)
git push -u gitee master

#如果不希望第一次拉取上传都要设置远程仓库名称,解决方法如下键默认的origin切换到gitee
git branch --set-upstream-to=gitee/master master
#Branch 'master' set up to track remote branch 'master' from 'gitee'.

################ 此时我们来看看 .git/config文件 ####################
[remote "gitee"] #上面再添加远程仓库的名称gitee写入命令
url = [email protected]:WeiyiGeek/test.git
fetch = +refs/heads/*:refs/remotes/gitee/*
[branch "master"] #再设置默认本地master默认上传拉取的远程仓库名称gitee命令
remote = gitee
merge = refs/heads/master

为什么Git添加文件需要add,commit一共两步呢?
因为commit可以一次提交很多文件,所以你可以多次add不同的文件,比如:

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

注意事项:

  • 一定要放到Git目录下(子目录也行),因为这是一个Git仓库放到其他地方Git再厉害也找不到这个文件。