Menu Close

Git使用教程

lcc0556

1. Git介绍

1.1. Git是什么？

Git是目前世界上最先进的分布式版本控制系统。

1.2. SVN与Git的最主要的区别？

　　SVN是集中式版本控制系统，版本库是集中放在中央服务器的，而干活的时候，用的都是自己的电脑，所以首先要从中央服务器哪里得到最新的版本，然后干活，干完后，需要把自己做完的活推送到中央服务器。集中式版本控制系统是必须联网才能工作，如果在局域网还可以，带宽够大，速度够快，如果在互联网下，如果网速慢的话，就纳闷了。

　　Git是分布式版本控制系统，那么它就没有中央服务器的，每个人的电脑就是一个完整的版本库，这样，工作的时候就不需要联网了，因为版本都是在自己的电脑上。既然每个人的电脑都有一个完整的版本库，那多个人如何协作呢？比如说自己在电脑上改了文件A，其他人也在电脑上改了文件A，这时，你们两之间只需把各自的修改推送给对方，就可以互相看到对方的修改了。

1.3. 工作区域

　　Git本地有三个工作区域：工作目录（Working Directory）、暂存区(Stage/Index)、资源库(Repository或Git Directory)。如果在加上远程的git仓库(Remote Directory)就可以分为四个工作区域。文件在这四个区域之间的转换关系如下：

file

  • workspace：工作区，就是平时存放项目代码的地方。
  • Index/Stage：暂存区，用于临时存放你的改动，事实上只是一个文件，保存即将提交到文件列表信息。
  • Repository：仓库区（或版本库,也即本地仓库），就是安全存放数据的位置，这里面有你提交到所有版本的数据。其中HEAD指向最新放入仓库的版本。
  • Remote：远程仓库，托管代码的服务器，可以简单的认为是你项目组中一台电脑用于远程数据交换。

1.4. 简单工作流程

  1. 在工作目录中添加、修改、删除文件(文件被记录在workspace区)；
  2. 将需要进行版本管理的文件放入暂存区(文件被记录在staged区)；
  3. 将暂存区域的文件提交git仓库(文件被记录在repository区)；
  4. 将本地git仓库修改推送到远程仓库(文件被记录在remote区)。

2. Git安装

2.1. windows上安装Git

第一步：从Git官网下载安装包
下载地址：https://git-scm.com/download/win

file

第二步：执行安装文件

file

第三步：验证git安装是否成功

  • 命令行输入：git --version，提示如下标识安装成功
    file

  • 回到电脑桌面，鼠标右击如果看到有两个git单词则安装成功
    file

file

Git Bash : Unix与Linux风格的命令行，使用最多。
Git CMD : Windows风格的命令行。
Git GUI : 图形界面的Git，不建议初学者使用，尽量先熟悉常用命令。

2.2. Linux上安装Git

第一步：使用yum安装Git

yum -y install git

备注： yum安装git被安装在/usr/libexec/git-core目录下

第二步：验证git安装是否成功

git --version

2.3. 获取帮助

$ git help
$ git <verb> --help
$ man git-<verb>

3. 初次运行 Git 前的配置

Git 自带一个 git config 的工具来帮助设置控制 Git 外观和行为的配置变量。 这些变量存储在三个不同的位置：

/etc/gitconfig 文件: 包含系统上每一个用户及他们仓库的通用配置。 如果在执行 git config 时带上 --system 选项，那么它就会读写该文件中的配置变量。 （由于它是系统配置文件，因此你需要管理员或超级用户权限来修改它。）

~/.gitconfig 或 ~/.config/git/config 文件：只针对当前用户。 你可以传递 --global 选项让 Git 读写此文件，这会对你系统上 所有 的仓库生效。

当前使用仓库的 Git 目录中的 config 文件（即 .git/config）：针对该仓库。 你可以传递 --local 选项让 Git 强制读写此文件，虽然默认情况下用的就是它。（当然，你需要进入某个 Git 仓库中才能让该选项生效。）

每一个级别会覆盖上一级别的配置，所以 .git/config 的配置变量会覆盖 /etc/gitconfig 中的配置变量。

在 Windows 系统中，Git 会查找 $HOME 目录下（一般情况下是 C:\Users\$USER ）的 .gitconfig 文件。 Git 同样也会寻找 /etc/gitconfig 文件，但只限于 MSys 的根目录下，即安装 Git 时所选的目标位置。

你可以通过以下命令查看所有的配置以及它们所在的文件：

git config --list --show-origin

file

3.1. 配置本地参数

  • 设置用户名

    $ git config user.name '用户名'
# 修改用户名
git config --replace-all user.name '要修改的用户名'
# 删除用户名
git config --unset user.name

  • 设置用户邮箱
    注意：该配置会在github主页上显示谁提交了该文件

    $ git config user.email '电子邮件'
# 修改邮箱
git config --replace-all user.email '要修改的邮箱'
# 删除邮箱
git config --unset user.email

  • 设置密码

    $ git config user.password '密码'
# 修改密码
git config --replace-all user.password '要修改的密码'
# 删除密码
git config --unset user.password

注意，默认配置的参数是在本地仓库级别，即默认参数是： --local，如果对用户配置不同的用户名和邮箱，需要使用参数：--global 。另外也可以使用命令 git config --eidt 来对配置文件进行编辑。

3.2. 查看本地配置参数

# 查看所有配置
git config --list  (简写：git config -l)
# 查看系统配置,Windows文件保存在 .\Git\etc\gitconfig 中，Linux文件保存在 /etc/gitconfig 中。
git config --system --list
# 查看用户配置,Windows文件保存在 C:\Users\用户名\.gitconfig 中，Linux文件保存在 /home/用户名/.gitconfig 中。
git config --global --list
# 查看当前仓库中的配置，Linux文件保存在 当前仓库目录/.git/config 中
git config --local --list
# 查看用户名配置
git config user.name
# 查看密码配置
git config user.password

3.3. 解决每次git pull、git push都需要输入账号和密码的问题

有以下三种方式解决git clone时每次都需要输入用户名和密码：

第一种：SSH免密方式

使用git bash ssh-keygen或puttygen.exe生成公钥。

第二种：配置全局开机存储认证信息

下面命令会将下次弹框的账号和密码保存起来，永久使用：

# Linux 该内容记录在 ~/.gitconfig 文件中
git config --global credential.helper store
# Windows Windows上默认已经启用凭证存储和自动验证
git config --global credential.helper wincred

如果想要清除该账号和密码，使用如下命令：

git config --global credential.helper reset

想要临时存储（默认15min），使用如下命令：

git config --global credential.helper cache

第三种：地址中携带用户信息

在https链接里加入 username:password ：

git remote add origin https://username:password@xxx.git

4. Git 项目搭建

4.1. 创建工作目录

工作目录（WorkSpace）一般就是你希望Git帮助你管理的文件夹，可以是你的项目目录，也可以是一个空目录，建议不要用中文，日常使用只要记住下图中的6个命令：

file

4.2. 搭建本地仓库(Repository)

创建Repository的方法有两种：一种是创建全新的仓库，另一种是克隆远程仓库。

第一种：创建全新的仓库

1）创建全新的仓库，需要在项目的根目录执行 git init命令，它帮我们新建了一个Git代码库。

2）执行命令后，仅仅在项目目录下多出了一个.git的目录，关于版本等所有信息都在这个目录中。

第二种：克隆远程仓库

1）在本地某个空目录中执行git clone [url]将远程服务器上的仓库克隆到该目录中。

file

5. Git 文件操作

　　版本控制就是对文件版本的控制，要对文件进行创建、修改、提交等操作，首先要知道文件当前在什么状态，不然可能会提交了现在还不想提交的文件，或者要提交的文件没提交上。

5.1. 文件的四种状态

　　GIT不关心文件两个版本之间的具体差别，而是关心文件的整体是否有改变，若文件被改变，在添加提交时就生成文件新版本的快照，而判断文件整体是否改变的方法就是用SHA-1算法计算文件的校验和。

file

  • Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 和 get commit 状态变为Staged.

  • Unmodify: 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件

  • Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改。

  • Staged: 暂存状态. 执行git commit则将修改同步到本地仓库中, 这时本地仓库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified。

下面的图很好的解释了这四种状态的转变：

file

  • 新建文件 ---> Untracked
  • 使用add命令将新建的文件加入到暂存区 ---> Staged
  • 使用commit命令将暂存区的文件提交到本地仓库 ---> Unmodified
  • 如果对Unmodified状态的文件进行修改 ---> modified
  • 如果对Unmodified状态的文件进行remove操作 ---> Untracked

5.2. 查看文件状态

#查看指定文件状态
git status [filename]

#查看所有文件状态
git status

#精简的方式显示文件状态
git status -s

5.3. 文件的主要操作

file

  • 创建本地仓库

    git clone <url> #克隆远程仓库到本地仓库
git init #在本地的当前目录里初始化git仓库

  • 修改和提交

    git status  #查看WorkSpace的状态
git diff #显示WorkSpace和Stage中的状态差异
git add <file> / git add .  #从WorkSpace保存到Stage,add后的文件才会被git跟踪
git mv <old> <new> #文件改名
git rm <file> #删除文件
git rm --cached <file> #从Stage中移除，停止跟踪文件但不删除
git commit -m "message" #从Stage提交更新到Local Repo
git commit --amend #修改最后一次提交

  • 查看提交历史

    git log #查看commit的历史记录(当前分支)
git log -p <file> #查看指定文件的提交历史
git blame <file> #以列表方式查看指定文件的提交历史

  • 撤销

    git checkout --<file> #撤销WorkSpace中的更新，将Stage的文件提取覆盖当前文件（撤销后无法找回）
git reset HEAD <file> #撤销Stage中的更新,移出到WorkSpace中（用于反悔 git add <file>）
#撤销Local Repo中的更新
#回退到相应版本号，同样也可以回退到未来的版本号:
git rest --hard HEAD^
git rest --hard HEAD~1
git rest --63c1c746b5b70448518ca2411874b9cd394f5ff6
git reflog ##查看HEAD的变更记录，包括已经撤销的更新
#恢复撤销操作:
git reset --hard HEAD@{1}
git reset --hard d03ab23
#--head：撤销并删除相应的更新
#--soft：撤销相应的更新，把这些更新的内容放到Stage中

  • 分支与标签

    git branch #显示所有本地分支
git checkout <branch/tag> #切换到指定分支或标签
git branch <new-branch> #创建新分支
git branch -d <branch> #删除本地分支
git tag #列出所有本地标签
git tag <tagname> #基于最新提交创建标签
git tag -d <tagname> #删除标签

  • 合并与衍合

    git merge <branch> #合并指定分支到当前分支
git rebase <branch> #衍合指定分支到当前分支

  • 远程仓库

    git remote -v #查看远程版本库信息
git remote show <remote> #查看指定远程版本库信息
#添加远程版本库,把本地库和远程库关联起来
git remote add <remote> <url>
git remote add origin git@github.com~
#从远程库获取代码
git fetch <remote>
#提交本地仓库到远程仓库
git push -u origin master #上传代码并快速合并
git push -u origin master -f #强制push，不管冲突
git push -u origin master --allow-unrelated-histories #把两个不同的项目合并
git push <remote> :<branch/tag-name> #删除远程分支或标签
git push --tags #上传所有标签
#同步远程仓库到本地
git pull <remote> <branch> #下载代码并快速合并
git pull origin master
# origin就是代表远程仓库的相关数据，它既包含远程仓库url信息，又包括远程仓库在本地的缓存分支信息。

  • 其他

    #删除文件
rm <file>
git rm <file>
#创建分支，提交到分支
git branch [name]
git push -u origin [name]
#删除当前目录中所有未追踪的文件
git clean -xf
#处理中文文件名
git config --global core.quotepath false

6. 简单操作

6.1. 创建新文件并提交到本地仓库

第一步：创建一个文件并查看文件状态

touch a.txt
echo 'git study' > a.txt
git status a.txt

file

第二步：将文件添加暂存区并查看文件状态

git add a.txt
git status a.txt

file

此时，如果不想提交这个文件，可以使用如下命令进行撤销操作：

git restore --staged a.txt
或者
git rm --cached a.txt

第三步：提交暂存区中的文件到本地仓库

git commit a.txt -m "提交信息"
# 如果未写文件名，则表示提交暂存区中的所有文件

file

第四步：继续修改该文件

file

**第五步：查看提交日志"

git log
或
git log --pretty=oneline --abbrev-commit
或
git log --graph --pretty=oneline --abbrev-commit
或
git reflog  # Reference logs（参考日志）

  • 使用git log命令只可以查看到HEAD指针及其之前的版本信息，如果版本发生过回退操作，则可能会出现HEAD指针之后仍存在历史提交版本的情况，而这些提交版本信息通过git log命令是看不到的。

  • 使用git reflog命令，就可查看到所有历史版本信息。由于查看所有历史版本信息大多是为了进行版本回退或恢复操作，从中找到所需的commit索引，所以该命令被命名为reflog，即：引用日志。

git log命令与git reflog命令作用范围示意图：

file

6.2. 从本地仓库回退（撤销本地的commit）

git reset命令是从本地仓库回退到历史的某个版本，它有3种方式：

  • --mixed：将文件回退到工作区，此时会保留工作区中的文件，但会丢弃暂存区中的文件；该参数为默认值，等同于git reset。
  • --soft：将文件回退到暂存区，此时会保留工作区和暂存区中的文件。
  • --hard：将文件回退到修改前，此时会丢弃工作区和暂存区中的文件。

具体实践参考文档：https://juejin.cn/post/7076384260357095454

file

6.3. 从Repository中删除文件

从本地仓库删除某个文件的做法有两种，一种是先执行操作系统命令删除文件，再执行git add -u命令删除Repository中的文件；另一种是使用git rm删除Repository中的文件。具体做法如下：

# 在本地仓库删除文件
git rm a.txt

# 在本地仓库删除文件夹
git rm -r doc/   # 此处-r表示递归所有子目录

# 提交代码
git commit -m "删除文件"

file

file

6.4. 查看未传送(git push)到远程代码库的(git commit)提交

  • git status： 只能查看未传送提交的次数
  • git cherry -v：只能查看未传送提交的描述/说明
  • git log master ^origin/master：则可以查看未传送提交的详细信息

file

6.5. 将本地未提交上传到远程仓库

git push

file

6.6. 从远程仓库拉取代码到本地仓库

git pull

file

6.7. 在本地解决冲突

场景：张三与李四同时拉取了文件b.txt，他们在并行修改该文件，此时张三修改了文件 b.txt先上传到远程仓库，李四也修改了文件 b.txt，当李四将修改后的文件上传到远程仓库会发生什么？

1）张三的操作过程

echo "zhangsan add line:1" >> b.txt
git add b.txt
git commit b.txt -m "zhangsan-add line 1"
git push

2）李四的操作过程

echo "lisi add line:1" >> b.txt
git add b.txt
git commit b.txt -m "lisi-add line 1"
git push

file

此时李四要进行如下操作解决冲突：

file

第一种解决方法：比较简单

执行下列命令，默认将pull下来的代码与现有改动的代码进行合并：

git config pull.rebase false
git pull
# 直接使用 git pull --rebase。如果拉取不产生冲突，会直接 rebase，不会产生分支合并操作，如果有冲突则需要手动 fix 后，自行合并。

file

该操作可能会造成代码冲突（对同一行数据进行了变更），需要处理下这个问题，代码冲突如果2个人都改了同一个文件，需要联系之前push的同学，看看这块代码怎么保存。

file

张三再次拉取文件时会被新的文件覆盖，不需要解决冲突。

file

我们知道怎么解决冲突，但是在工作中还是要尽量避免，养成以下好习惯，让你尽可能不产生代码冲突。尽可能频繁地使用 git pull 同步代码，每次修改都基于最新的源码，大大减少发生冲突的概率。还要减少每次提交代码的行数，每次做完一个小修改就提交并上传代码。这样即使发生冲突了，你也能很好地解决。你肯定不希望有几十处，几百行代码发生冲突吧，那场面想想都可怕。

第二种解决方法：回退到合并之前的代码，再进行pull拉取最新代码

注意：这种解决方法仅适用于2个分支之间的合并（git merge）操作，比如你是将dev开发分支合并到test分支之前没pull，那这时候test分支需要回退到未合并前的版本。
test上合并上去的代码将会丢失，等你test分支能成功pull后，需要重新合并（merge）开发分支dev上的代码合并到test上。所以记得保留dev开发分支这个版本的代码再把test回退到上一个版本，等pull成功，再重新在test分支上合并dev分支代码。

7. 分支操作

7.1. 为什么要有分支

　　比如我们开发完了一个app上线了，接下那就是迭代功能开发了，如果上线的app出现了一个严重的bug，要你放下手头新功能的开发去解决这个bug，然后再发布一个新版本，如果你要是就在你要迭代功能的项目上进行修改发布的话，那肯定是不行的，且先不谈有没有新的bug出现，时间是也是不允许的，发布的前提还要把新功能完善好才行，要是删掉新功能的代码也不怎么现实，要是业务逻辑少一点还好说，要是多的话那还真是有点无从下手了，所以git的分支就很好的解决了这个问题。 如下图:

file

master就是我们的主代码，一直优化，到v1.4版本发布了，然后接着往下开发v2.0、v2.1版本，但是v1.4版本出现了一个严重的bug，这时候我们就在这个v1.4版本创建一个分支HotFix来对bug进行修复。到了v1.6版本bug修复好发布出去，然后再跟原来的master主代码进行合并一下把代码添加到v2.1版本就OK了，剩下就接着迭代开发了。

7.2. Git 的常用分支介绍

Master/Develop 分支
Master分支是最近发布到生产环境的代码， 这个分支只能从其他分支合并，不能在这个分支直接修改。Develop 分支是基于 Master 分支创建的，它是主开发分支，包含所有要发布到下一个 Release 的代码，这个分支主要也是从其他分支合并，比如 Feature 分支。

file

Feature 分支
这个分支主要是用来开发一个新的功能，Feature 分支做完后，必须合并回 Develop 分支进入下一个Release, 合并完分支后一般会删点这个 Feature 分支。

file

Release 分支
当你需要一个发布一个新 Release 的时候，我们基于 Develop 分支创建一个 Release 分支，同时，其它开发人员可以基于 Develop 分支新建 Feature (记住：一旦打了Release 分支之后不要从 Develop 分支上合并新的改动到 Release 分支)。 发布 Release 分支时，合并 Release 到 Master 和 Develop， 同时在 Master 分支上打个 Tag 记住 Release 版本号，然后可以删除 Release 分支了。

file

Hotfix 分支
当我们在生产环境中发现新的 Bug 时候，我们需要创建一个 Hotfix, hotfix 分支基于 Master 分支创建，完成 Hotfix 后，我们合并回 Master 和 Develop 分支，同时在 Master 上打一个 tag。所以 Hotfix 的改动会进入下一个 Release。

file

7.3. IDEA中操作git分支

场景：开发者A创建一个分支，并在分支上进行开发

提前将远程仓库的代码克隆到本地，然后用 IDEA 打开，IDEA 自动关联上 Git。然后通过 Git -> 分支 来创建新分支。创建分支也是一个常用的操作，例如临时修改bug、开发不确定是否加入的功能等，都可以创建一个分支，再等待合适的时机合并到主干。

file

选择 新分支，并在弹出的圣话框中输入一个分支的名称，创建完成后注意IDEA的右下角，如下图，表示已经自动切换到新创建的分支上，当前工作在这个分支上。也可以使用git branch命令来查看分支。

file

未完待续……

附录

附录A. 相关联的文章

附录B. 其他参考文章

附录’. Linux 下升级Git

centos默认的的yum仓库中的默认版本很低，有时我们需要安装高版本git，参考如下操作：

第一步：卸载Centos自带的git

yum remove git

第二步：下载需要安装的版本号

wget https://mirrors.edge.kernel.org/pub/software/scm/git/git-2.41.0.tar.gz --no-check-certificate

第三步：安装依赖包

yum install curl-devel expat-devel gettext-devel openssl-devel zlib-devel gcc perl-ExtUtils-MakeMaker

注意：安装编译源码所需依赖的时候，yum自动帮你安装了git，这时候你需要先卸载这个旧版的git。

yum -y remove git

第四步：安装Git

tar -zxf git-2.41.0.tar.gz
cd git-2.41.0
make all
make prefix=/usr/local/git install

第五步：添加环境变量

vim /etc/profile
    export PATH=$PATH:/usr/local/git/bin
source  /etc/profile

第六步：查看版本号

git --version

file

附录D、如何在 Git 中忽略文件和文件夹

在任何当前工作的 Git 仓库中，每个文件都是这样的：

  • 追踪的（tracked）- 这些是 Git 所知道的所有文件或目录。这些是新添加（用 git add 添加）和提交（用 git commit 提交）到主仓库的文件和目录。

  • 未被追踪的（untracked） - 这些是在工作目录中创建的，但还没有被暂存（或用 git add 命令添加）的任何新文件或目录。

  • 被忽略的（ignored） - 这些是 Git 知道的要全部排除、忽略或在 Git 仓库中不需要注意的所有文件或目录。本质上，这是一种告诉 Git 哪些未被追踪的文件应该保持不被追踪并且永远不会被提交的方法。

所有被忽略的文件都会被保存在一个 .gitignore 文件中。该文件中设定的规则决定哪些文件或目录不被Git管理。

1）忽略规则优先级
在 .gitingore 文件中，每一行指定一个忽略规则，Git 检查忽略规则的时候有多个来源，它的优先级如下（由高到低）：

  • 从命令行中读取可用的忽略规则
  • 当前目录定义的规则
  • 父级目录定义的规则，依次递推
  • $GIT_DIR/info/exclude 文件中定义的规则
  • core.excludesfile 中定义的全局规则

2）忽略规则匹配语法

  • 空格不匹配任意文件，可作为分隔符，可用反斜杠转义
  • 以＃开头的行都会被 Git 忽略。即#开头的文件标识注释，可以使用反斜杠进行转义。
  • 可以使用标准的glob模式匹配。所谓的glob模式是指shell所使用的简化了的正则表达式。
  • 以/结尾表示只匹配文件夹以及在该文件夹路径下的内容，但是不匹配该文件。
  • 以/开头表示匹配项目与目录；如果一个模式不包含斜杠，则它匹配相对于当前 .gitignore 文件路径的内容，如果该模式不在 .gitignore 文件中，则相对于项目根目录。
  • 以星号*通配多个字符，即匹配多个任意字符；使用两个星号** 表示匹配任意中间目录，比如a/**/z可以匹配 a/z, a/b/z 或 a/b/c/z等。
  • 以问号?通配单个字符，即匹配一个任意字符；
  • 以方括号[]包含单个字符的匹配列表，即匹配任何一个列在方括号中的字符。比如[abc]表示要么匹配一个a，要么匹配一个b，要么匹配一个c；如果在方括号中使用短划线分隔两个字符，表示所有在这两个字符范围内的都可以匹配。比如[0-9]表示匹配所有0到9的数字，[a-z]表示匹配任意的小写字母）。
  • 以叹号!表示不忽略(跟踪)匹配到的文件或目录，即要忽略指定模式以外的文件或目录，可以在模式前加上惊叹号（!）取反。需要特别注意的是：如果文件的父目录已经被前面的规则排除掉了，那么对这个文件用"!"规则是不起作用的。也就是说"!"开头的模式表示否定，该文件将会再次被包含，如果排除了该文件的父级目录，则使用"!"也不会再次被包含。可以使用反斜杠进行转义。

需要谨记：git对于.ignore配置文件是按行从上到下进行规则匹配的，意味着如果前面的规则匹配的范围更大，则后面的规则将不会生效。另外需要注意的是：如果你不慎在创建.gitignore文件之前就push了项目，那么即使你在.gitignore文件中写入新的过滤规则，这些规则也不会起作用，Git仍然会对所有文件进行版本管理。简单来说出现这种问题的原因就是Git已经开始管理这些文件了，所以你无法再通过过滤规则过滤它们。所以大家一定要养成在项目开始就创建.gitignore文件的习惯，否则一旦push，处理起来会非常麻烦。

示例：

#               表示此为注释,将被Git忽略
*.a             表示忽略所有 .a 结尾的文件
!lib.a          表示lib.a除外
/TODO           表示仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
build/          表示忽略 build/目录下的所有文件，过滤整个build文件夹；
doc/*.txt       表示会忽略doc/notes.txt但不包括 doc/server/arch.txt
bin/:           表示忽略当前路径下的bin文件夹，该文件夹下的所有内容都会被忽略，不忽略 bin 文件
/bin:           表示忽略根目录下的bin文件
/*.c:           表示忽略cat.c，不忽略 build/cat.c
debug/*.obj:    表示忽略debug/io.obj，不忽略 debug/common/io.obj和tools/debug/io.obj
**/foo:         表示忽略/foo,a/foo,a/b/foo等
a/**/b:         表示忽略a/b, a/x/b,a/x/y/b等
!/bin/run.sh    表示不忽略bin目录下的run.sh文件
*.log:          表示忽略所有 .log 文件
config.php:     表示忽略当前路径的 config.php 文件
/mtk/           表示过滤整个文件夹
*.zip           表示过滤所有.zip文件
/mtk/do.c       表示过滤某个具体文件

被过滤掉的文件就不会出现在git仓库中（gitlab或github）了，当然本地库中还有，只是push的时候不会上传。

需要注意的是，gitignore还可以指定要将哪些文件添加到版本管理中，如下：

!*.zip
!/mtk/one.txt

唯一的区别就是规则开头多了一个感叹号，Git会将满足这类规则的文件添加到版本管理中。为什么要有两种规则呢？
想象一个场景：假如我们只需要管理/mtk/目录中的one.txt文件，这个目录中的其他文件都不需要管理，那么.gitignore规则应写为：

/mtk/*
!/mtk/one.txt

假设我们只有过滤规则，而没有添加规则，那么我们就需要把/mtk/目录下除了one.txt以外的所有文件都写出来！
注意上面的/mtk/*不能写为/mtk/，否则父目录被前面的规则排除掉了，one.txt文件虽然加了!过滤规则，也不会生效！

还有一些规则如下：

fd1/*
说明：忽略目录 fd1 下的全部内容；注意，不管是根目录下的 /fd1/ 目录，还是某个子目录 /child/fd1/ 目录，都会被忽略；

/fd1/*
说明：忽略根目录下的 /fd1/ 目录的全部内容；

/*
!.gitignore
!/fw/
/fw/*
!/fw/bin/
!/fw/sf/
说明：忽略全部内容，但是不忽略 .gitignore 文件、根目录下的 /fw/bin/ 和 /fw/sf/ 目录；注意要先对bin/的父目录使用!规则，使其不被排除。
Post Views: 282