花了好几天的时间,才迁移完git学习笔记,进行了重新整理,记录了常用操作。不知不觉Git
已经用了2年的时间,虽然不久,但已经深深爱上了这个家伙~~~
git config
使用方法如下,如果没有指定位置参数省略的话,大部分命令默认为:--local
1 | git config [<--system> | <--global> | <--local>] [option] |
配置优先级
配置生效优先级:1.
> 2.
> 3.
,即相同参数的配置优先级
.git/config
工作目录下的配置,使用:git config --local
~/.gitconfig
用户目录下的配置,使用:git config --global
/etc/gitconfig
对所有用户都适用的配置,使用:git cofing --system
选项
查看生效的配置
1 | git config -l #查看所有配置 |
查看某个参数的配置
1 | git config user.name #查看当前工作目录下的“用户名称”的配置 |
设置用户名称和用户Email地址
1 | git config --global user.name "John Doe" |
换行符:CRLF/LF
在Windows系统上,把它设置成true
,这样当签出代码时,LF
会被转换成CRLF
1 | git config --global core.autocrlf true |
Linux或Mac系统上,因此你不想Git在签出文件时进行自动的转换;当一个以CRLF
为行结束符的文件不小心被引入时你肯定想进行修正,设置成input
来告诉Git在提交时把CRLF
转换成LF
,签出时不转换
1 | git config --global core.autocrlf input |
如果仅运行在Windows上的项目,可以设置false
取消此功能,把回车符记录在库中
1 | git config --global core.autocrlf false |
换行符:SafeCRLF
拒绝提交包含混合换行符的文件
1 | git config --global core.safecrlf true |
允许提交包含混合换行符的文件
1 | git config --global core.safecrlf false |
提交包含混合换行符的文件时给出警告
1 | git config --global core.safecrlf warn |
core.quotepath
在使用git的时候,经常会碰到有一些中文文件名或者路径被转义成\xx\xx\xx之类的,此时可以通过git的配置来改变默认转义
1 | git config --global core.quotepath false |
core.pager
core.pager指定 Git 运行诸如log、diff等所使用的分页器,你能设置成用more或者任何你喜欢的分页器(默认用的是less), 当然你也可以什么都不用,设置空字符串:
1 | git config --global core.pager '' |
其它配置
1 | git config --global core.editor vim #设置文本编辑器 |
工作区
暂存区
暂存区,又称为--stage
或--index
,是一个介于工作区和版本库的中间状态,当执行提交时,实际上是将暂存区的内容提交到版本库中。
版本库
工作区/暂存区/版本库,三者的关系图
HEAD
HEAD
是当前分支引用的指针,它总是指向该分支上的最后一次提交。这表示 HEAD
将是下一次提交的父节点。通常,理解HEAD
的最简方式,就是将它看做 你的上一次提交 的快照。
符号^
可以用于指代父提交
HEAD^
代表版本库中的上一次提交,即最近一次提交的父提交HEAD^^
则代表HEAD^
的父提交
对于一个提交有多个父提交,可以在符号^
后面用数字表示是第几个父提交
查看快照
1 | $ git cat-file -p HEAD |
查看引用日志的输出
1 | $ git show HEAD@{0} |
SSH Key
查看已经保存的SSH密钥
1 | ls -lart ~/.ssh |
生成SSH密钥
1 | ssh-keygen -t rsa -C "your_email@example.com" |
查看公钥(*.pub
)文件的内容,如果没有修改密钥的位置和保存的路径,直接复制cat
出来的内容,粘帖到你需要用到的地方
1 | cat ~/.ssh/id_rsa.pub |
git clone
克隆操作,使用方法如下:1
git clone [<options>] [--] <repository> [<directory>]
包含工作区的版本库
在本地创建一个[<directory>]
,则会将此名称做为克隆的文件夹名称
1 | git clone <repository> [<directory>] |
裸版本库,不包含工作区
不包含工作区,直接就是版本库的内容,这样的版本库称为裸版本库。一般约定俗成裸版本库的目录名以.git
为后缀,所以下面实例中将克隆出来的裸版本库目录名写作<directory.git>
1 | git clone --bare <repository> <directory.git> |
git clone --mirror
克隆出来的裸版本对上游版本进行了注册,这样可以在裸版本库中使用git fetch
命令和上游版本库进行持续同步
支持的多种协议
常用的一些协议,不是全部
1 | git clone file:///opt/git/project.git |
git remote
查看当前工作目录的远程仓库信息
1 | git remote -v |
1 | $ git remote -v |
添加远程仓库
1 | git remote add [name] [url] |
修改远程仓库的url地址
1 | git remote set-url <name> <new_url> |
修改某个远程仓库的简写名称
1 | git remote rename <old_name> <new_name> |
移除某个远程仓库的配置信息,不会删除任何文件
1 | git remote rm | remove <name> |
git fetch
拉取远程仓库的更新数据
只是将远端的数据拉到本地仓库,不会自动合并到当前工作分支。
1 | git fetch <repository-name> <branch-name> #repository-name:远程仓库的简写名称 |
拉取所有远程仓库
1 | git fetch --all |
git pull
获取远程仓库的更新数据,再自动合并到本地仓库中的当前分支
1 | git pull <repository-name> <repository-branch-name> |
相当于做了以下2步操作,如果有冲突,将会合并失败
1 | git fetch origin master |
获取远程仓库的更新数据,再自动合并到本地仓库中的其它分支
1 | git pull <repository-name> <repository-branch-name>:<local-branch-name> |
获取远程仓库上所有的tag
1 | git pull <repository-name> --tags |
git push
将本地分支的更新,推送到远程仓库
1 | git push <repository-name> <local-branch-name>:[repository-branch-name] |
通常的操作,省略掉远程分支名[repository-branch-name]
,则表示将本地分支推送与之存在“追踪关系”的远程分支(通常两者同名),如果该远程分支不存在,则会被新建。
1 | git push <repository-name> <local-branch-name> |
删除远程仓库的分支
第一种方式,如果省略[local-branch-name]
,推送一个空的本地分支到远程分支,即删除掉[远程分支],[本地分支]不会删除
1 | git push <repository-name> :<repository-branch-name> |
示例:删除远程仓库的b3
分支
1 | $ git push origin :b3 |
第二种方式,使用--delete
选项
1 | git push <repository-name> <repository-branch-name> --delete |
示例:删除远程仓库的b2
分支
1 | $ git push origin b2 --delete |
强制更新,覆盖的方式推送
注意:此操作非常危险,因为能够将历史记录抹除掉,比如远程分支有3个提交:1,2,3,而本地分支有2个提交:4,5,并且和远程分支的提交不一样,如果强制推送了之后,远程分支上原来的3个提交就会丢失掉,变成和本地分支一样。总而言之,请三思而后行!!!
强制更新,会在远程仓库产生一个“非块进式”的合并(non-fast-forward merge)
1 | git push <repository-name> <local-branch-name> -f | --force |
操作注意:
- 在github中,通常会关闭对
master
分支的强制更新,关闭保护的步骤:在项目的Settings
下的Branches
中,找到Protected branches
,将其关闭掉即可。 - 在gitlab中,通常会关闭对
master
分支的强制更新,关闭保护的步骤:在项目的Settings
下,找到Protected branches
,将其关闭掉即可。
推送标签
默认情况下,git push
并不会把标签推送到远程仓库,只有通过显式命令才能推送标签到远程仓库
1 | git push <repository-name> <local-tag-name> |
推送所有的标签
将本地所有的标签,推送到远程仓库(远程仓库没有的标签),注意是否有权限
1 | git push <repository-name> --tags |
推送本地所有的分支,不包含标签
1 | git push <repository-name> --all |
git init
初始化本地仓库
先在本地创建一个空目录,然后在创建的目录里使用git init
初始化仓库
1 | $ mkdir my-work |
一步操作,仓库空目录,并初始化仓库
1 | $ git init my-work |
git add
添加未跟踪的文件
使用git add <文件名1>[,<文件名2>,<文件名3>]
添加未跟踪的文件,这不会提交到本地仓库中。如需要提交,使用git commit -m "提交的注释"
1 | $ git status -s test.txt #查看精简状态,显示有一个未跟踪的文件 |
添加已经追踪的文件
同样的使用git add <文件名1>[,<文件名2>,<文件名3>]
添加已跟踪的文件,这不会提交到本地仓库中。如需要提交,使用git commit -m "提交的注释"
1 | $ git status #查看状态,有一个文件的内容修改了 |
巧用git add
,快速回退测试代码
假设已经开发好了某个功能,这时候用git add
添加,但不做git commit
场景一:这时候我再去添加些测试代码测试,比如
System.out.println
这种代码,测试下来发现我刚才git add
的代码都是OK的,这时候我用git checkout
就能快速安全的删掉刚才添加的测试代码。
场景二:我发现刚才git add
的代码不够完美,修改完成之后,再次用git add
添加,就会合并到上一次git add
的代码中了,然后做为一次git commit
。
git status
查看当前分支的文件变化状态
1 | git status |
查看精简状态
1 | git status -s |
M
字符的位置在第二列,颜色为红色,表示工作区当前的文件与暂存区的文件相比有改动
1 | $ git status -s |
M
字符的位置在第一列,颜色为绿色,表示版本库中的文件与暂存区中的文件相比有改动
1 | $ git status -s |
同时显示所在的分支
1 | $ git status -sb |
git cherry
查看本地分支领先远程仓库的提交
1 | $ git cherry |
git diff
比较工作区和暂存区
1 | git diff |
逐词比较,而非默认的逐行比较
1 | git diff --word-diff |
比较暂存区和HEAD
(本地git仓库)
1 | git diff --cached |
比较工作区和HEAD
(本地git仓库)
1 | git diff HEAD |
比较两个提交
用SHA-1
值(前7位即可)比较两次提交之间的差异。注意顺序不一样,查看到的结果也会不一样。
1 | git diff <$id1> <$id2> |
比较两个分支
只比较已经提交的内容
1 | git diff <branch1> <branch2> |
比较两个远程分支
注意:可能需要先执行git fetch
1 | git diff pro/master pro/b1 |
当前分支比较另外一个分支
1 | git diff <branch2> [current-branch] |
比较之后,显示简要的增改行数统计
1 | $ git diff --stat |
比较二进制文件差异
1 | git diff --binary |
git stash
储藏当前工作区和暂存区修改的内容
使用场景,当需要紧急处理一个bug时,工作区内容又没有完成,不适合提交,将未完成的修改保存到一个栈上,而你可以在任何时候重新应用这些改动。
1 | git stash |
示例:
1 | $ git stash |
储藏的完整命令
1 | git stash [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] [-u|--include-untracked] [-a|--all] [<message>] |
如果需要在保存储藏的时候指定说明
1 | git stash save <message> |
1 | $ git stash save "9 modify" |
使用参数--patch
会显示工作区和HEAD
的差异,通过对比差异文件的编辑决定在进度中最终要保存的工作的内容,通过编辑差异文件可以在进度中排除无关内容
1 | git stash --patch |
1 | $ git stash --patch |
使用-k
或--keep-index
参数,在保存进度后不将暂存区
重置(默认会将暂存区
和工作区
强制重置,即命令:--no-keep-index
的效果)
1 | git bash -k | --keep-index |
1 | $ git status #当前暂存区有一个修改的文件 |
使用-u|--include-untracked
,同时储藏未跟踪文件。
1 | git stash save -u|--include-untracked |
使用-a|--all
来储藏所有的改动,包括未跟踪文件
1 | git stash save -a|--all |
查看已经保存的储藏列表
1 | $ git stash list |
删除储藏
如果没有指定是第几个储藏时,默认会删除最近的一次储藏
1 | git stash drop [-q|--quiet] [<stash@{n}>] |
1 | $ git stash drop stash@{0} |
删除所有的储藏
1 | git stash clear |
查看[某次]储藏修改的内容
1 | git stash show [<stash@{n}>] |
示例:
1 | $ git stash show #查看最后一次的储藏 |
恢复保存的工作进度
1 | git stash <pop | apply> [--index] [-q|--quiet] [<stash@{n}>] |
如果不使用任何参数,恢复最近一次保存的工作进度
1 | git stash pop #会从储藏列表中删除刚刚恢复的暂存 |
如果使用<stash@{n}>
参数,则从该<stash@{n}>
中恢复保存的内容
1 | git stash pop <stash@{n}> #会从储藏列表中删除该`<stash@{n}>` |
--index
除了恢复工作区的文件外,还会恢复暂存区的内容
1 | git stash pop --index |
使用储藏的内容创建新的分支
<branch-name>
不能是已经存在的分支,并切换到创建的新分支,删除掉该储藏
1 | git stash branch <branch-name> [<stash@{n}>] |
1 | $ git stash branch b2 |
查看储藏列表的SHA-1
值
1 | $ git reflog show refs/stash |
git commit
仓库中的文件可能存在于这三种状态
Untracked files
→ 文件未被跟踪Changes to be committed
→ 文件已暂存,这是下次提交的内容Changes not staged for commit
→ 文件被修改,但并没有添加到暂存区。如果commit
时没有带-a
选项,此状态下的文件不会被提交。
1 | $ git status |
提交暂存区的内容
提交状态为Changes to be committed
的内容
1 | git commit [-m <message>] |
提交暂存区和工作区的内容
提交状态为Changes to be committed
和Changes not staged for commit
的内容
1 | git commit -a [-m <message>] |
1 | $ git status |
修改或者撤销最后一次提交
1 | git commit --amend #进入交互终端模式 |
修改最后一次提交,退出编辑器之后会直接commit
。如果要取消,则在编辑器里清空掉提交信息再退出即可。使用场景如:修改提交信息、补正刚才修改的内容(需要先git add
)、少添加文件了(需要先git add
),谨慎操作!!
git checkout
汇总显示(工作区和暂存区)与HEAD
的差异
1 | git checkout [HEAD] |
1 | $ git status |
撤销工作区的修改
用暂存区中的内容覆盖工作区的内容,如果使用.
,而没有指定具体的file
,会替换工作区所有有改动的文件
1 | git checkout [--] <. | file> |
1 | $ git status |
用HEAD
中的内容替换暂存区和工作区的修改
取出最近的一次提交的内容,替换暂存区和工作区的修改,如果使用.
,而没有指定具体的file
,会替换暂存区和工作区中所有有改动的文件
1 | git checkout [--] <. | file> |
1 | $ git status #暂存区和工作区都有修改 |
使用其它分支的内容替换当前分支上暂存区和工作区的内容
HEAD
的指向不会变化
1 | git checkout <branch-name> [--] <file> |
1 | Administrator@Jerry-WIN8-TP MINGW64 /d/workspaces/test/progit (master) |
git reset
基本操作
将当前的分支重设(reset)到指定的<commit>
或者HEAD
(如果不显示指定commit
,默认是HEAD
,即最新的一次提交),并且根据选项
有可能更新暂存区
和工作区
1 | git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>] |
--soft
:暂存区
和工作区
中的内容不作任何改变,仅仅把HEAD
指向<commit>
。这个模式的效果是,执行完毕后,自从<commit>
以来的所有改变都会显示为Changes to be committed
(git status
) 。不会丢失任何改动
1 | git reset --soft <commit> |
1 | $ git hist #现在有3个提交 |
--hard
:重设暂存区
和工作区
,自从<commit>
以来在工作区
中的任何改变都被丢弃,并把HEAD
指向<commit>
。会丢失改动
1 | git reset --hard <commit> |
1 | $ git hist #现在有3个提交 |
--mixed
:仅重设暂存区
,但是不重设工作区
。这个模式是默认模式,即当不显示告知git reset
模式时,会使用--mixed
模式。这个模式的效果是,工作区
中文件的修改都会被保留,不会丢弃,但是也不会被标记成Changes to be committed
。不会丢失任何改动
1 | git reset <commit> |
1 | $ git hist #现在有3个提交 |
重置暂存区
将暂存区添加的内容,回退到工作区,改动不会丢失。如果指定了文件<file>
,则只处理此文件
1 | git reset HEAD |
1 | $ git hist #现在有3个提交 |
实战:两个提交压缩为一个
使用--soft
参数调用重置命令,回到最近两次提交之前
1 | git reset --soft HEAD^^ |
查看版本状态和最新日志,如果需要修改就进行修改
执行提交操作,即完成最新两个提交压缩为一个
1 | git commit -m"Message" |
git rebase
交互式变基操作
<since>
和<till>
代表历史提交的SHA-1
值,变基的范围是从<since>
(不包括<since>
)的下一个提交到<till>
,如果<till>
没有给出,则变基的范围到当前HEAD
。
1 | git rebase -i <since> [<till>] |
1 | $ git hist #现在有5个提交 |
- 开头的几行由上到下依次对应历史的提交,如果删除掉这些提交保存退出交互式模式,则不执行变基动作
pick
,或简写p
,默认的动作,即应用此提交reword
,或简写r
。在变基时会应用此提交,但是在提交的时候允许用户修改提交说明edit
,或简写e
。在变基时会应用此提交,但是在应用后你可以进行内容编辑,需要使用git commit --amend
执行提交,以便对提交进行修补。当用户执行git commit --amend
完成提交后,还需要执行git rebase --continue
继续变基操作。用户在变基暂停状态下可以执行多次提交,从而实现把一个提交分解为多个提交squash
,简写s
。该提交会与前面的提交压缩为一个fixup
,简写f
。类似动作squash
,但是提交的提交说明被丢弃- 可以通过修改变基任务文件中各个提交的先后顺序,进而改变最终变基后提交的先后顺序
- 可以通过改变变基任务文件,删除包含相应提交的行,这样该提交就不会被应用,进而在变基后的提交中被删除
在变基遇到冲突而暂停的情况下,先完成冲突解决(添加到暂存区,不提交),然后在恢复变基操作的时候使用该命令
1 | git rebase --continue |
在变基遇到冲突而暂停的情况下,跳过当前提交的时候使用,谨慎用
1 | git rebase –abort |
在变基遇到冲突而暂停的情况下,终止变基操作,回到之前的分支时候使用
1 | git rebase –skip |
将其它分支上的修改应用到当前分支
将远程仓库的更新,合并到当前分支上产生一个新的提交,如果工作区或者暂存区有未提交的更改,变基动作不会执行
1 | git fetch origin master |
git branch
显示所有分支信息
1 | git branch |
1 | $ git branch #显示所有分支名称 |
创建新分支
创建新分支之后,不会自动切换到新分支上
1 | git branch <new-branch-name> |
基于<commit>
创建新分支,不会自动切换到新分支上
1 | git branch <new-branch-name> <commit> |
使用git checkout
创建新分支,并自动切换到这个分支上
1 | git checkout -b <new-branch-name> |
使用git checkout
基于标签创建新分支,并自动切换到这个分支上
1 | git checkout -b <new-branch-name> <tag-name> |
使用git checkout
基于标签创建新分支,没有指定<new-branch-name>
,HEAD
会进入到游离指针状态
1 | git checkout -b <tag-name> |
1 | $ git checkout v5 |
退出游离指针状态
1 | git checkout <branch-name> #切换到其它分支 |
创建新分支来跟踪远程分支,并自动切换到这个分支上
1 | git checkout -b <new-branch-name> <remote-name>/<remote-branch-name> |
重命名分支
如果<new-branch-name>
已经存在,重命名动作停止
1 | git branch -m <old-branch-name> <new-branch-name> |
如果<new-branch-name>
已经存在,重命名动作继续,请谨慎操作
1 | git branch -M <old-branch-name> <new-branch-name> |
1 | $ git branch -v |
删除分支
如果分支上存在未被合并的提交,删除动作停止
1 | git branch -d <branch-name> |
如果分支上存在未被合并的提交,删除动作继续,请谨慎操作
1 | git branch -D <branch-name> |
1 | $ git branch -v |
查看已经合并到当前分支的分支
1 | git branch --merged |
查看没有合并到当前分支的分支
1 | git branch --no-merged |
1 | $ git branch -v |
git merge
有未提交修改情况下,不要执行merge!遵守这条警告,防患于未然
基本操作
1 | git merge [<options>] [<commit>...] |
- 默认合并成功后会自动提交,使用
--no-commit
选项,则合并后的内容会放入暂存区,需要手动提交 <commit>
可以是提交的SHA-1
值、分支、标签等<commit>
如果是多个提交,合并成功后,当前HEAD
是第一个<commit>
的父提交,第一个<commit>
是第二个<commit>
的父提交,依次类推
1 | $ git hist b2 #b2分支上有7个提交,领先master分支2个提交 |
不要Fast-Foward
合并,会生成merge
提交信息
1 | git merge [<commit>...] --no-ff |
不要Fast-Foward
合并,手动生成merge
提交信息
1 | git merge [<commit>...] --no-ff -m"<Message>" |
1 | $ git merge 82fa977 --no-ff |
将分支合并到当前分支
1 | git merge <branch> |
终止合并操作
冲突时执行中止merge
操作,merge manual
中说,这条命令会尽力恢复到Merge
之前的状态(可能失败!)
1 | git merge --abort |
git tag
创建轻量级标签
轻量级标签就像是个不会变化的分支,实际上它就是个指向特定提交对象的引用。如果只是临时性加注标签,或者不需要旁注额外信息,用轻量级标签也没问题
1 | git tag <new-tag-name> |
1 | $ git tag v1.0.0 #创建一个标签 |
创建含附注标签
含附注标签,实际上是存储在仓库中的一个独立对象,它有自身的校验和信息,包含着标签的名字,电子邮件地址和日期,以及标签说明,标签本身也允许使用GNU Privacy Guard (GPG)
来签署或验证。一般我们都建议使用含附注型的标签,以便保留相关信息。
1 | git tag -a <new-tag-name> -m "<Message>" |
如果有自己的GPG
私钥,还可以用GPG
来签署标签,只需要把之前的-a
改为-s
1 | git tag -s <new-tag-name> -m "<Message>" |
GPG
签署工作
首先,在开始签名之前你需要先配置GPG
并安装个人密钥。
1 | $ gpg --list-keys |
如果你还没有安装一个密钥,可以使用gpg --gen-key
生成一个。
1 | gpg --gen-key |
一旦你有一个可以签署的私钥,可以通过设置Git
的user.signingkey
选项来签署。
1 | git config --global user.signingkey 0A46826A |
如果已经设置好一个GPG
私钥,可以使用它来签署新的标签。所有需要做的只是使用-s
代替-a
即可:
1 | $ git tag -s v1.5 -m 'my signed 1.5 tag' |
如果在那个标签上运行git show
,会看到你的GPG
签名附属在后面:
1 | $ git show v1.5 |
要验证一个签署的标签,可以运行git tag -v [tag-name]
。这个命令使用GPG
来验证签名。为了验证能正常工作,签署者的公钥需要在你的钥匙链中。
1 | $ git tag -v v1.4.2.1 |
如果没有签署者的公钥,那么你将会得到类似下面的东西:
1 | gpg: Signature made Wed Sep 13 02:08:25 2006 PDT using DSA key ID F3119B9A |
在最新版本的Git
中(v1.7.9
及以上),也可以签署个人提交。 如果相对于标签而言你对直接签署到提交更感兴趣的话,所有要做的只是增加一个-S
到git commit
命令。
1 | $ git commit -a -S -m 'signed commit' |
git log
也有一个--show-signature
选项来查看及验证这些签名。
1 | $ git log --show-signature -1 |
查看所有的标签
1 | git tag |
1 | $ git tag |
标签匹配查询
使用*
支持模糊匹配
1 | git tag -l | --list "tag-name*" |
1 | $ git tag -l "*1*" |
查看标签的信息
1 | git tag show <tag-name> |
删除标签
1 | git tag -d <tag-name> |
文件内容追溯
追溯整个文件的内容
会逐行显示文件,在每一行的行首显示此行最早是在什么版本引入的,由谁引入的
1 | git blame <file> |
1 | $ git blame readme.md |
追溯指定的行号
n
:起始行号;m
:结束行号,如果未指定,则使用文件的最后一行的行号
1 | git blame -L <n[,m]> <file> |
1 | $ git blame readme.md -L 3 |
git ls-files
显示暂存区和版本库中的文件
1 | git ls-files |
查看历史版本的文件列表
1 | git ls-files --with-tree=HEAD^ |
git rm
工作区删除文件
1 | git rm <file> |
1 | $ git rm readme.md |
暂存区删除文件
从暂存区删除文件,工作区不会删除。删除的文件在工作区存在,状态变为未追踪
1 | git rm --cached <file> |
1 | $ git rm --cached readme.md |
git clean
显示将要被删除的目录和文件
针对那些未被跟踪的文件和目录
1 | git clean -nd |
删除掉未被跟踪的文件和目录
1 | git clean -fd |
git mv
移动或者重命名文件
如果移动或者重命名文件操作成功会添加到暂存区
1 | git mv [<options>] <source>... <destination> |
-n | --dry-run
:演练移动或者重命名文件,看看操作是否会成功
1 | git mv -n | --dry-run <source>... <destination> |
1 | $ git mv readme.md t1.md -n #演练将readme.md重命名为t1.md |
-f | --force
:强制移动或者重命名文件,不管目标是否已经存在
1 | git mv -f | --force <source>... <destination> |
git log
1 | git log 显示提交历史信息 |
忽略文件
工作区创建文件.gitignore
工作区创建文件.gitignore
,然后在里面添加忽略规则。.gitignore
这个文件本身会提交到版本库中去,用来保存的是公共的需要排除的文件。.gitignore
的语法规范如下:
- 以
#
开头的行是注释 - 以
/
做为行尾字符,则要忽略的是目录 - 以
!
做为行首字符,则是取反模式 - 空白行不做处理
- 支持正则表达模式匹配
*
匹配零个或多个任意字符[abc]
匹配任何一个在方括号中的字符?
匹配任意一个字符[0-9a-zA-Z]
在方括号中使用短划线分隔两个字符,表示所有在这两个字符范围内的都可以匹配(比如[0-9a-zA-Z]
表示匹配所有0
到9
的数字和所有字母)\
转义字符[ ^abc]
匹配不是a
,b
,c
中任一字符即可{ab,bb,cx}
匹配ab
,bb
,cx
中任一类型即可
1 | $ touch .gitignore |
注意:.gitignore
只能忽略那些没有被版本库追踪的文件,如果文件已经提交到了版本管理中,则在.gitignore
中对这些文件的忽略是无效的,可以使用以下方式进行临时忽略
1 | git update-index --assume-unchanged /path/to/file #忽略跟踪 |
但此方式在git rebase
操作之后,这些被忽略的文件内容如果被修改过了,会被强制恢复到git rebase
这个时候的版本内容。如果要从根本上忽略这些文件,请使用git rm
删除掉这些文件,然后提交到版本库中
编辑.git/info/exclude
独享忽略列表,不需要提交到版本库中,不会影响其他人
1 | $ vi .git/info/exclude |
用户目录下的全局.gitignore
在用户目录下创建~/.gitignore
文件,以同样的规则来添加哪些文件是不需要版本控制的
1 | git config --global core.excludesfile ~/.gitignore #需要执行此命令,才能是全局配置生效 |
git grep
操作语法
1 | git grep [<options>] [-e] <pattern> [<rev>...] [[--] <path>...] |
1 | git grep "工作区文件内容搜索" |
windows平台下的msysGit中shell环境配置
编辑配置文件/etc/inputrc
,修改或者添加以下配置,重启后就能在shell
界面输入中文
1 | # disable/enable 8bit input |
ls
命令显示中文,将alias
命令添加到配置文件/etc/profile
中
1 | alias ls='ls --show-control-chars --color=auto' |
解决gitk
和Git Gui
乱码,在/etc/gitconfig
中添加或修改以下配置
1 | [gui] |
在/etc/git-completion.bash
末尾位置添加cd /d
,可以让msysGit
打开定位到D
盘
windows平台下的msysGit工具
gitk
显示所有的分支
1 | gitk --all |
显示某天以来的所有提交
1 | gitk --since="[YYYY-MM-dd]|[2 days ago][2 weeks ago]..." |
gui
1 | git gui |