Git的学习及使用

Git的使用

1. Git简介

Git是目前世界上最先进的分布式版本控制系统（没有之一）。

1.1 版本控制

1.1.1 手动版本控制

手动版本控制是早期版本控制的方法，它需要开发人员手动管理版本的变更和追踪。它的优点是简单易用，不需要额外的工具或系统支持；缺点是不够自动化，容易出错，难以管理和跟踪版本变更。

例如当我们写论文时每次对论文进行修改需要不断的另存为一个新的word文件。如果我们把文档发给了其他人后，其他人对文档进行了修改再发送给我们的时候我们并不知道他对文档进行了怎样的修改。

1.1.2 自动版本控制

自动版本控制是一种更现代化的版本控制方法，它使用自动化的工具和系统来管理版本的变更和追踪。它的优点是高效、自动化的管理，能够追踪和管理版本的变更，支持分支和合并操作。自动化版本控制不但可以记录每次文件的改动，还可以和同事协同编辑。

就像这样每次都能记录文件的改动：

自动版本控制工具(其他的都不好用，用Git)：

• vss：微软
• cvs：开源
• svn：google
• git：分布式版本控制工具（标准）

1.2 分布式版本控制

1.2.1 集中式版本控制系统（SVN)

集中式版本控制系统最大的缺点需要联网才能工作，上传文件速度慢受网速的影响较大。那分布式版本控制系统与集中式版本控制系统有何不同呢？首先，分布式版本控制系统根本没有“中 央服务器”，每个人的电脑上都是一个完整的版本库，这样，你工作的时候，就不需要联网了，因为版本 库就在你自己的电脑上。既然每个人电脑上都有一个完整的版本库，那多个人如何协作呢？比方说你在 自己电脑上改了文件A，你的同事也在他的电脑上改了文件A，这时，你们俩之间只需把各自的修改推送 给对方，就可以互相看到对方的修改了。

和集中式版本控制系统相比，分布式版本控制系统的安全性要高很多，因为每个人电脑里都有完整 的版本库，某一个人的电脑坏掉了不要紧，随便从其他人那里复制一个就可以了。而集中式版本控制系 统的中央服务器要是出了问题，所有人都没法干活了。 在实际使用分布式版本控制系统的时候，其实很少在两人之间的电脑上推送版本库的修改，因为可 能你们俩不在一个局域网内，两台电脑互相访问不了，也可能今天你的同事病了，他的电脑压根没有开 机。因此，分布式版本控制系统通常也有一台充当“中央服务器”的电脑，但这个服务器的作用仅仅是用 来方便“交换”大家的修改，没有它大家也一样干活，只是交换修改不方便而已。

1.2.2 分布式版本控制系统(Git)

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

CVS作为最早的开源而且免费的集中式版本控制系统，直到现在还有不少人在用。由于CVS自身设 计的问题，会造成提交文件不完整，版本库莫名其妙损坏的情况。

同样是开源而且免费的SVN修正了 CVS的一些稳定性问题，是目前用得最多的集中式版本库控制系统。

除了免费的外，还有收费的集中式版本控制系统，比如IBM的ClearCase（以前是Rational公司的， 被IBM收购了），特点是安装比Windows还大，运行比蜗牛还慢，能用ClearCase的一般是世界500强， 他们有个共同的特点是财大气粗，或者人傻钱多。

微软自己也有一个集中式版本控制系统叫VSS，集成在Visual Studio中。由于其反人类的设计，连 微软自己都不好意思用了。 分布式版本控制系统除了Git以及促使Git诞生的BitKeeper外，还有类似Git的Mercurial和Bazaar 等。这些分布式版本控制系统各有特点，但最快、最简单也最流行的依然是Git！

2. Git实战

2.1 安装Git

最早Git是在Linux上开发的，很长一段时间内，Git也只能在Linux和Unix系统上跑。不过，慢慢地 有人把它移植到了Windows上。现在，Git可以在Linux、Unix、Mac和Windows这几大平台上正常运行了。

在Windows上使用Git，可以从Git官网直接下载安装程序，（网速慢的同学请移步国内镜像），然 后按默认选项安装即可。 安装完成后，在开始菜单里找到“Git”->“Git Bash”，蹦出一个类似命令行窗口的东西，就说明Git安装成功。

安装完成后，还需要最后一步设置，在命令行输入：

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"
$ git config --global --get user.name #得到user.name的值
$ git config --global -l #列表参数

注意 git config 命令的 --global 参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

2.2 创建版本库

什么是版本库呢？版本库又名仓库，英文名repository，你可以简单理解成一个目录，这个目录里面的所有文件都可以被Git管理起来，每个文件的修改、删除，Git都能跟踪，以便任何时刻都可以追踪历史，或者在将来某个时刻可以“还原”。

2.2.1 创建版本库

在一个你喜欢的目录里来创建版本库(注意路径不能出现中文)，右键运行GitBash Here，输入命令。

#创建版本库目录 起一个你想起的名字这里名字叫 learngit
mkdir learngit
#进入learngit目录
cd learngit
#通过git init命令将这个目录变成Git可以管理的仓库
git init

创建完成后，当前目录下多了一个 .git 的目录，这个目录是Git来跟踪管理版本库的，没事千万不要手动修改这个目录里面的文件，不然改乱了，就把Git仓库给破坏了。

2.2.2 添加文件到版本库

现在我们编写一个 readme.txt 文件，内容如下：

Git is a version control system.
Git is free software.

一定要放到 learngit 目录下（子目录也行），因为这是一个Git仓库，放到其他地方Git再厉害也找 不到这个文件。和把大象放到冰箱需要3步相比，把一个文件放到Git仓库只需要两步。

1.用命令 git add 告诉Git，把文件添加到仓库：

git add readme.txt

2.用命令git commit告诉git，把文件提交到了仓库

#语法格式 git commit -m [提交的注释说明]
git commit -m "wrote a readme file"
#查看git日志
git log

简单解释一下 git commit 命令， -m 后面输入的是本次提交的说明，可以输入任意内容，当然最好 是有意义的，这样你就能从历史记录里方便地找到改动记录。

嫌麻烦不想输入 -m “xxx” 行不行？确实有办法可以这么干，但是强烈不建议你这么干，因为输入 说明对自己对别人阅读都很重要。实在不想输入说明的童鞋请自行Google，我不告诉你这个参数。 git commit 命令执行成功后会告诉你， 1 file changed ：1个文件被改动（我们新添加的 readme.txt文件）； 2 insertions ：插入了两行内容（readme.txt有两行内容）。 为什么Git添加文件需要 add ， commit 一共两步呢？因为 commit 可以一次提交很多文件，所以你 可以多次 add 不同的文件，比如：

#创建多个文件
touch file1.txt，file2.txt，file3.txt
git add file1.txt
git add file2.txt file3.txt #或者git add * 添加所有untrack文件到stage

使用git status查看git状态

git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
new file: file1.txt
new file: file2.txt
new file: file3.txt

提交

git commit -m "add 3 files"

总结

• git add . 把工作区文件添加到暂存区
• git commit -m “xxxx”：把暂存区(stage)文件提交到分支
• git status：查看git版本库状态
• git log：查看版本提交

2.3 版本控制

2.3.1 修改readme.txt

修改readme.txt文件，改成如下内容：

Git is a distributed version control system.
Git is free software.

运行 git status 命令看看结果：

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.txt
no changes added to commit (use "git add" and/or "git commit -a")

git status 命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们， readme.txt 被修改过了，但还没有准备提交的修改。

虽然Git告诉我们 readme.txt 被修改了，但如果能看看具体修改了什么内容，自然是很好的。比如 你休假两周从国外回来，第一天上班时，已经记不清上次怎么修改的 readme.txt ，所以，需要用 git diff 这个命令看看：

git diff(只能显示还未提交的文本文件修改详情):

$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index 46d49bf..9247db6 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
Git is free software.

git diff 顾名思义就是查看difference，显示的格式正是Unix通用的diff格式，可以从上面的命令 输出看到，我们在第一行添加了一个 distributed 单词。

知道了对 readme.txt 作了什么修改后，再把它提交到仓库就放心多了,提交修改和提交新文件是 一样的两步，第一步是 git add ：

git add readme.txt

同样没有任何输出。在执行第二步 git commit 之前，我们再运行 git status 看看当前仓库的状态：

git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: readme.txt

git status 告诉我们，将要被提交的修改包括 readme.txt ，下一步，就可以放心地提交了：

git commit -m "add distributed"
[master e475afc] add distributed
1 file changed, 1 insertion(+), 1 deletion(-)

提交后，我们再用 git status 命令看看仓库的当前状态

git status
On branch master
nothing to commit, working tree clean

Git告诉我们当前没有需要提交的修改，而且，工作目录是干净（working tree clean）的。

2.3.2 版本回退

1.准备3个版本，将readme.txt文件进行三次修改并将其提交三次

2.使用git log命令查看版本

git log
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:06:15 2018 +0800
append GPL
commit e475afc93c209a690c39c13a46716e8fa000c366
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 21:03:36 2018 +0800
add distributed
commit eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0
Author: Michael Liao <askxuefeng@gmail.com>
Date: Fri May 18 20:59:18 2018 +0800
wrote a readme file

git log 命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是 append GPL ，上一次是 add distributed ，最早的一次是 wrote a readme file 。 如果嫌输出信息太多，看得眼花缭乱的，可以试试加上 **–**pretty=oneline 参数：

git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file
#1094adb7b9b3807259d8cb... 这个就是版本号commit id

3.版本回退(两种方式)

#HEAD表示当前版本 HEAD^表示上个版本，HEAD^^表示上上个版本，以此类推
git reset --hard HEAD^
HEAD is now at e475afc add distributed

当版本还原后，之前最新的版本已经看不到了，因此可以查看之前的git log输出的信息来查看回退版本之前最新版本的版本号来回到指定版本。

#1094a就是之前最新版本的版本号，由于版本号很长，但我们不用全复制过来，只需复制需要回到版本的版本号的前几位即可。
git reset --hard 1094a

若是在之前的输出结果中找不到原来版本的版本号我们也可以通过使用git reflog命令来查看之前的每一次命令来寻找版本号：

git reflog
e475afc HEAD@{1}: reset: moving to HEAD^
1094adb (HEAD -> master) HEAD@{2}: commit: append GPL
e475afc HEAD@{3}: commit: add distributed
eaadf4e HEAD@{4}: commit (initial): wrote a readme file

2.3.3 工作区和暂存区

Git和其他版本控制系统如SVN的一个不同之处就是有暂存区的概念。先来看名词解释。

1.工作区

就是你在电脑里能看到的目录，比如我的 learngit 文件夹就是一个工作区：

2.版本库（暂存区+分支）

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

（1）版本库的基本状态

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支 master ，以及指向 master 的一个指针叫 HEAD 。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

第一步是用 git add 把文件添加进去，实际上就是把文件修改添加到暂存区；

第二步是用 git commit 提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个 master 分支，所以，现在， git commit 就是往 master 分支上提交更改。 你可以简单理解为，需要提交的文件修改通通放到暂存区，然后，一次性提交暂存区的所有修改。 先对 readme.txt 做个修改，比如加上一行内容：

Git is a distributed version control system. 

Git is free software distributed under the GPL. 

Git has a mutable index called stage.

然后，在工作区新增一个 LICENSE 文本文件（内容随便写）。

先用 git status 查看一下状态：

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.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
LICENSE
no changes added to commit (use "git add" and/or "git commit -a")

所以， git add 命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行 git commit 就可以一次性把暂存区的所有修改提交到分支。

git commit -m "understand how stage works"
[master e43a48b] understand how stage works
2 files changed, 2 insertions(+)
create mode 100644 LICENSE

一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

git status
On branch master
nothing to commit, working tree clean

(3) commit后的版本库状态

2.3.4 撤销修改

1.放弃工作区的修改

#git checkout -- [所要放弃修改的文件] 将文件在工作区的所有修改撤销
git checkout -- readme.txt

2.放弃暂存区的修改

#git reset HEAD [所要放弃修改的文件] git reset 命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用 HEAD 时，表示最新的版本。
git reset HEAD readme.txt

• –soft ：仅仅移动本地库 HEAD 指针
• –mixed: 移动本地库 HEAD 指针，重置暂存区
• –hard：移动HEAD指针，重置暂存区，工作区，省略git checkout – file

2.3.5 删除文件

1.删除工作区文件

#删除工作区文件
rm test.txt

2.删除版本库文件

#当文件上传到版本库后 使用git rm [所要删除的文件]  这个命令会将工作区以及版本库的该文件一并删除
git rm test.txt

3.恢复删除文件

#如果我们使用rm删除工作区文件时删除错了文件，只要没有用git rm删除版本库文件(版本库文件还在)我们可以使用git checkout -- [所要恢复的文件]
git checkout -- test.txt
#git checkout 其实是用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

注意：从来没有被添加到版本库就被删除的文件，是无法恢复的

3.远程仓库

主要有github、gitee

3.1 使用远程库

3.1.1 HTTS 协议

1.到远程仓库复制HTTS链接

2.在命令行输入以下命令来下载开源项目

git clone [所复制的HTTS链接]
#第一次访问需要输入自己的远程库用户名密码

3.1.2 SSH协议

1.生成公钥(SSH属于非对称性加密，MD5属于对称性加密)

2.在远程仓库绑定公钥

3.复制SSH链接

4.下载开源项目

git clone [所复制的SSH链接]

3.2添加远程仓库

1.首先在本地新建一个目录用来存储

3.3 链接远程仓库

3.4 分支管理

分支管理就像两个平行宇宙，两个宇宙的一个人互不影响各自在学习自己的东西，在某个时间点时，两个宇宙互相融合，那么这个人就学会了两种东西。

分支管理的作用：可以创建一个属于自己的分支，别人在别的分支上工作，自己则在属于自己的分支上工作，两个分支同时进行工作并且互不影响，等代码写完后再与别人的分支进行融合，既安全又不影响他人工作。

3.3.1 创建与合并分支

刚开始只有一个master分支，HEAD指向master，每当master分支提交一个工作，master分支就会往前移动一步。

当我们创建一个新的分支dev,并切换到该分支的时候，Git会新建一个dev指针，HEAD指向dev，就表示当前在dev分支上。我们对工作的修改和提交就是针对idev分支的与master分支没有关系，每当我们在dev分支上提交了一次，dev分支就会向前移动一步，master分支则不受影响。

当我们在dev上的工作完成时，就可以将dev分支与master分支进行合并。

回到master分支将dev分支与master分支合并。

#创建并切换到分支dev
git checkout -b dev
#这条命令相当于两条命令
git branch dev #创建dev分支
git checkout dev #切换到dev分支

查看当前所有分支

git branch 
#此时显示dev master两条分支存在 git branch 命令会列出所有分支，当前分支前面会标一个 * 号。
* dev
master

在dev分支上修改文件并提交

#修改编辑文件
vim test.txt
#添加到暂存区
git add .
#提交
git commit -m "dev修改文件"

提交后切换回master分支

git checkout master

将master分支与dev分支进行合并

#在master分支与dev分支合并
git merge dev

此时查看master分支中的test.txt内容会发现与dev分支中修改的内容相同。此时也可以将dev分支进行删除。

删除dev分支

#git branch -d [分支名]
git branch -d dev

相关命令总结：

#git checkout
  #git checkout -- [file]把版本库的文件重置到工作区(撤销工作区的修改)
  #git checkout master：切换到master分支
  #git checkout -b dev 创建dev分支，并且切换到dev分支
#git branch
  #git baranch 列表分支信息，有*的为当前分支
  #git baranch -d [分支名] 删除分支
#get merge [所要合并的分支名] 合并分支
#master合并dev分支
git checkout master
git merge dev 
#使master分支合并dev分支

3.3.2 版本冲突

当两个或多个分支对同一个文件或者代码进行修改时可能会产生版本冲突。

准备新的feature1分支，并对test.txt文件进行修改

#创建并切换到feature1分支
git checkout -b feature1
#查看test.txt文件当前内容
cat test.txt
#当前内容  
test.txt:这个文件还未修改
#对test.txt文件进行修改
vim test.txt
#修改后内容
这个文件还未修改
feature1进行修改
#提交test.txt文件
git add .
git commit -m "这是feature1进行的修改"

切换回master分支对文件test.txt文件进行修改

#切换回master分支
git checkout master
#对test.txt文件进行修改并提交
vim test.txt
#修改后的内容
这个文件还未修改
main 进行修改
#提交test.txt文件
git add .
git commit -m "这是main对文件的修改”

现在， master 分支和 feature1 分支各自都分别有新的提交，变成了这样：

这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲 突。

将master分支与featrue1进行合并

$ git merge feature1
Auto-merging test.txt
CONFLICT (content): Merge conflict in test.txt
Automatic merge failed; fix conflicts and then commit the result.
#我们可以看出git会提醒我们test.txt文件存在冲突,必须手动解决冲突后再提交。

下面git status命令也可看出存在冲突文件

查看test.txt文件内容

我们可以看出Git用 <<<<<<< ， ======= ， >>>>>>> 标记出不同分支的内容。

下面将其手动修改后进行保存：

vim testt.txt

手动修改后内容：

再次提交即可

git add .
git commit -m "手动修改后的提交"

现在， master 分支和 feature1 分支变成了下图所示：

用带参数的 git log 也可以看到分支的合并情况：

#查看日志 --graph参数表示以图表的形式显示
git log --oneline --graph

显示出来的：

3.3.3 分支管理策略

1.fast forward模式( 如果添加–no-ff参数会禁用fast forward模式会添加一个合并分支的注释信息)

通常，合并分支时，如果可能，Git会用 Fast forward 模式，但这种模式下，删除分支后，会丢掉分支信息。

如果要强制禁用 Fast forward 模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。

–no-ff 方式的 git merge ：

创建并切换dev分支

git checkout -b dev

修改test.txt文件，并提交一个新的commit

git add test.txt
git commit -m "add merge"

切换回main分支

git checkout main

准备合并dev 分支，添加 --no-ff参数，表示禁用Fast forward：

get merge --no-ff -m "merge with no-ff" dev

因为本次合并要创建一个新的commit，所以加上 -m 参数，把commit描述写进去。 合并后，此时git log的分支历史为：

注意：git merge 默认采用Fast forwrad模式进行合并

2.ort模式：ORT 合并策略的原理是，在合并时只将那些在当前分支中不存在的提交添加到目标分支中，而不会将当前分支的提交添加到目标分支中1。这意味着，如果某个提交在目标分支中已经存在，则不会再次添加到目标分支中，从而避免了重复的合并提交。

#<source_branch> 是要合并到目标分支的源分支名称。 加上参数--strategy=ort表示采用ort模式进行合并
git merge --strategy=ort <source_branch>

在实际开发中，我们应该按照几个基本原则进行分支管理：

• master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
• 那在哪干活呢？干活都在 dev 分支上，也就是说， dev 分支是不稳定的，到某个时候，比如1.0版
• 本发布时，再把 dev 分支合并到 master 上，在 master 分支发布1.0版本；
• 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合 并就可以了

团队合作的分支看起来就像这样：

#创建本地dev分支
git checkout -b dev
#提交dev给服务器
git push origin dev
#创建bob的本地分支
git checkout -b bob
#创建env.txt
touch env.txt
#提交
git add .
git commit -m "add env bob"
#回到dev，合并bob分支
git checkout dev
git merge bob
#上传dev到远程
git push origin dev

cd f:\mickey
git clone git@gitee.com:lxsong77/learngit.git
#注意，只下载master分支，其他分支不会被clone
git checkout -b dev
git branch --set-upstream-to=origin/dev dev
#等价于
git checkout -b dev origin/dev
#拉取dev分支
git pull origin dev
#创建mickey分支
git checkout -b mickey
#修改env.txt增加内容"mickey env"
vim env.txt
#提交
git add .
git commit -m "update env by mickey"
#合并到dev
git checkout dev
git merge mickey
#上传
git push origin dev

合并到master分支

#拉取最新代码
git pull origin master
git pull origin dev
git checkout master
git merge dev
#上传
git push origin master

3.3.4 分支实战

1.Bug分支

当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支 issue-101 来修复 它，但是，等等，当前正在 dev 上进行的工作还没有提交，这是我们便需要一个命令来

3.5 标签管理

1.创建标签

切换到需要打标签的分支上：

#git tag [标签名]
git tag v1.0

查看所有标签

#查看所有标签
git tag

当我们忘记打标签的时候，如果需要在之前的版本上打标签我们可以通过历史提交的commit id来打上标签

#git tag [标签名] [commit id]
git tag v3.0 27a864b

还可以创建带有说明的标签，用 -a 指定标签名， -m 指定说明文字：

#git tag -a v0.1 -m [注释] [commit id 或者不写打在当前分支]
git tag -a v0.1 -m "version 0.1 released" b0fbe25

总结：

• 命令 git tag 用于新建一个标签，默认为 HEAD ，也可以指定一个commit id；
• 命令 git tag -a -m “blablabla…” 可以指定标签信息；
• 命令 git tag 可以查看所有标签。

2.操作标签

如果标签打错可以删除标签

#删除标签 git tag -d [标签名或者commit id]
git tag -d v1.0

将标签推送给远程库

#git push origin <tagname>
git push origin v1.0
#把全部标签推送
git push origin --tags

删除远程库标签

#需要先删除本地标签
git tag -d v1.0
#再删除远程库里的标签
git push origin :refs/tags/v1.

4. 自定义Git

4.1 git config 自定义设置

在安装Git一节中，我们已经配置了 user.name 和 user.email ，实际上，Git还有很多可配置项。 比如，让Git显示颜色，会让命令输出看起来更醒目：

$ git config --global color.ui true

这样，Git会适当地显示不同的颜色，比如 git status 命令：

文件名就会标上颜色。

4.2 忽略特殊文件

有些时候，你必须把某些文件放到Git工作目录中，但又不能提交它们，比如保存了数据库密码的配 置文件啦，等等，每次 git status 都会显示 Untracked files … ，有强迫症的童鞋心里肯定不爽。

好在Git考虑到了大家的感受，这个问题解决起来也很简单，在Git工作区的根目录下创建一个特殊的 .gitignore 文件，然后把要忽略的文件名填进去，Git就会自动忽略这些文件。

不需要从头写 .gitignore 文件，GitHub已经为我们准备了各种配置文件，只需要组合一下就可以使用了。所有配置文件可以直接在线浏览：https://github.com/github/gitignore

忽略文件的原则是：

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

举个例子：

假设你在Windows下进行Java开发，我们需要忽视例如out目录、.idea目录…

这样我们就可以通过修改.gitignore文件内容来忽略这些文件：

.gitignore:

### IntelliJ IDEA ###
out/
!**/src/main/**/out/
!**/src/test/**/out/
### java
*.iml
.idea/

### Eclipse ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
bin/
!**/src/main/**/bin/
!**/src/test/**/bin/

### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/

### VS Code ###
.vscode/

### Mac OS ###
.DS_Store

设置完.gitignore文件后将其也提交到Git中即可。

但有时想添加一个被忽视的文件到Git时但发现提交不了，我们可以加上-f参数强制将其添加到Git：

git add -f App.class

或者你发现，可能是 .gitignore 写得有问题，需要找出来到底哪个规则写错了，可以用 git check-ignore 命令检查：

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

Git会告诉我们， .gitignore 的第3行规则忽略了该文件，于是我们就可以知道应该修订哪个规 则。

总结：

• 忽略某些文件时，需要编写 .gitignore ；
• .gitignore 文件本身要放到版本库里，并且可以对.gitignore 做版本管理！

5. idea使用Git

1.在idea中创建一个项目

2.创建本地版本库

3. 修改忽略文件

4.将项目进行提交

commit时输入注释点击提交

5.链接远程库

在远程仓库新建一个仓库

获得SSH链接：

链接远程库

输入shh https链接：

将本地版本库上传到远程版本库

链接完成

6.idea 进行操作

在idea中，add、commit、上传远程库的操作、管理远程版本库链接、将远程库克隆到本地的操作如下：

新建分支、新建标签操作如下：

切换分支合并分支、从远程库拉取、删除分支操作如下：

注意：当对远程库进行切换分支(CheckOut)操作时如果本地没有没有此分支，则会在本地新建此分支。

新建分支：

Fetch：

git fetch"是一个用于从远程Git存储库获取更新的Git命令。它与"git pull"命令的区别在于，"git fetch"只是将远程分支的更新拉取到本地存储库(用来保持本地库与远程库的同步)，但不会自动将这些更改合并到您的当前工作分支。这使您可以在合并之前查看远程分支的更改并进行必要的调整。

详细总结：[http://t.csdn.cn/25NRW]