git 版本控制命令笔记
git
获取与创建项目
你得先有一个git仓库,才能用它进行操作。仓库是Git存放你要保存的快照的地方。
创建仓库的两种方式:
- init 通过命令行初始化。
- clone 如果我们想要在已有的仓库的基础上改变可以通过克隆的方式。
init
git init #初始化git仓库
clone
基本的快照
add 添加文件到缓存
在git中,在提交你修改的文件之前,你需要把他们添加到缓存。如果该文件是新建的可以直接通过git add进行添加,但是需要注意的是即使该文件已经添加到了缓存(已经被追踪)——你仍然需要执行git add 将更改的文件添加到缓存。
git add * 将目录中的所有文件都递归地添加到暂存区。
在文件已经添加到缓存后又发生了改动:
git status -s
AM #AM状态的意思是在文件已经添加到缓存后又发生了改动
AM 意味着如果此时进行提交提交的是上一次执行git add 的文件版本而不是本地的发生改动的那个,git并不认为磁盘中的文件和你想快照的文件必须是一致的 ——(如果需要一致)得通过git add 命令告诉他。
status 查看你的文件在工作目录中的缓存状态。
git status 命令查看你的代码在缓存与当前工作目录中的状态。 如果在后面添加参数 -s 以获得更剪短的结果输出。
git status -s
😉执行git status 以查看在你上一次的提交之后有啥被修改了或者临时提交了,并从而决定自己是否需要提交一次快照,同时也能知道有什么改变被记录进去了
git diff 显示写入缓存与已修改但尚未写入缓存的改动的区别
描述已临时提交的或者已修改但是尚未提交的改动。
尚未缓存的改动
git diff #尚未缓存的改动
git status 显示你上次提交更新后所更改或者写入缓存的改动,而git diff 一行一行显示这些改动具体是啥。通常执行完git status 之后执行 git diff 是个好的习惯。
查看已缓存的改动
git diff --cached #查看已缓存的改动
查看已缓存和未缓存的所有的改动
git diff HEAD
简单总结:
git diff 来查看执行git status的结果的详细信息 —— 一行一行地显示这些文件是如何被修改或者写入缓存的。
git commit 记录缓存内容的快照
执行完成了 git add 之后是成功地将文件添加到缓存,再执行git commit就将它实际存为快照了
git commit -m '对提交的声明'
git commit -m '对提交的解释说明!'
提交注释是很重要的。
git commit -a #自动将在提交之前将已记录,修改的文件放入缓存区。
上面的命令行的作用是为任何的已有记录的文件执行 git add ,任何在你最近的提交中已经存在,并且之后被修改的文件。不过仍然需要
通过git add 来添加新的文件。
git reset HEAD 取消缓存已缓存的内容
git reset HEAD -- file #--后面写文件名
-- 这个符号是用来告诉git 这时你已经不再列选项,剩下的是文件路径。养成使用它分隔选项和路径的习惯很重要,即使在你可能并不需要的时候。
看下面的命令行:
git reset HEAD -- file #此时file对应文件的路径,--和file之间一定要有空格否则会出错
上面命令行的作用是将缓存区里的file(之前已经通过add,添加到缓存 ) 取消缓存,也就是说取消当前文件的最近一次的git add 操作。
git rm 将文件从缓存区移除
git rm会将条目从缓存区移除。这与git reset HEAD -- file 不同。取消缓存的意思是将缓存区恢复为我们做出修改之前的样子。而git rm则是彻底将该文件从缓存区踢出,因此他不会在下一个提交快照之内,进而有效地删除它。
git rm file 会将文件file从缓存区和你的硬盘(工作目录)中删除。如果要在工作目录中留下则 使用 git rm -- cached
*同时在工作目录和缓存中移除好像需要使用 git rm -f file (选项 f)
git mv
效果相当于 git rm file -- cached ,在工作目录中进行重命名然后 git add
分支与合并
分支:
可以执行 :
git branch 分支名 #创建了一个分支
git branch 列出,创建与管理分支
列出分支:
git branch #列出可用的分支,会在当前的分支前面会有一个* 并且在有色模式下为绿色
创建分支:
git branch test #创建了名为test的分支
git checkout 切换分支
切换分支:
git checkout test #从当前的分支切换到test分支
注意点:
在创建分支test之后,如果有更新和提交,在分支切换到test分支时工作目录会还原为test分支刚创建时的样子。
创建新分支并立刻切换到它
git checkout -b test #创建新分支test,然后立刻切换到该分支。
删除分支
git branch -d test #删除分支test
分支的合并merge
我们新创建了一个分支进行独立开发最终是需要将该分支合并到主分支的。
git merge test #将test分支合并到当前的分支
更复杂的合并
下面将演示一个案例,体现git强大的分支合并能力
合并冲突
在不同的分支中对相同区块的代码做了修改,电脑自己猜不透神马的情况下,冲突就摆在我们前面了。我们看下面的两个分支中对同一行的代码做了改动之后的例子:
git log 显示一个分支中提交的更改记录
git log 当前快照的所有的提交消息的工具,叫做git log.
git log #用于查看当前快照的所有提交消息的工具。
git log --oneline #历史记录的紧凑版
需要扩展,修改。更多git log相关的问题。
git tag
给历史记录中的重要的一点打上标签,如果你达到一个重要的阶段,并希望永远记住那个特别的提交快照,你可以使用git tag 给它打上一个标签。该tag 命令基本上会给该特殊提交打上永久的书签,从而使你在将来能够用它与其他提交比较。通常,你会在切取一个发布版本或者交付一些东西的时候打个标签。
例如:我们想为我们的Hello word项目发布一个"1.0" 版本,我们可以使用 git tag -a v1.0命令给最新一次的提交打上HEAD "v1.0" 的标签。-a 选项:创建一个带有注解的标签,从而使你为标签添加注解。绝大部分的时候都会这么做的。不用 -a 也是可以执行的,但它不会记录这标签是啥时候打的,谁打的,也不会让你添加个标签的注解。推荐使用有注解的。
分享与更新项目
使用git fetch 更新你的项目,使用git push 分享你的改动。你可以用git remote管理你的远程仓库。
远程仓库相关 git remote
git remote 列出远端仓库,git remote add 添加远端仓库,git remote rm 删除已存在的远端仓库。
列出
git remote #列出远端别名。
如果没有任何参数,git 会列出它存储的仓库别名了事,默认情况下如果你的仓库是克隆的,git 会自动将你项目克隆自的仓库添加到列表中,并取名origin,如添加上参数 -v 则可以看到每个别名的实际链接地址。
你可以看到该项目仓库的链接地址两次,是因为Git允许你为每个远端仓库添加不同的推送与获取的链接,以备你读写是使用不同的协议。
添加远端仓库 git remote add (url)
git remote add 远端仓库的别名 远端仓库的url
删除现存的远端库的别名 git remote rm
git remote rm github #删除别名为github的远端仓库。
git fetch
从远端仓库下载新分支与数据。
git pull
从远端仓库提取数据并尝试合并到当前的分支
git pull 会提取远端的分支并合并到你当前所在的任意分支,与git fetch 不同的是git pull相当于在git fetch 上还添加了 git merge的功能。git pull的方式虽然简单,但是git fetch更加稳重不易出错。
git push
推送你的新的分支与数据到远端的仓库。
如果在你上次提取,合并之后,另有人推送了,Git服务器会拒绝你的推送,直到你是最新的为止。
下面命令行以将远端仓库的最新版更新到本地:
git fetch github #github是远端仓库的别名
git merge github/master #将github仓库的分支合并到本地仓的master分支上。
1
1
1
1
1
1
1
补充:
小补充
提交记录
git 会将当前版本与仓库中的上一个版本进行对比,并把所有的差异打包到一起作为一个提交记录。
git 还保存了提交的历史记录。这也是为什么大多提交记录的上面都有父节点的原因。
分支
Git的分支非常轻量。他们只是简单滴指向某个提交记录 —— 仅此而已。早建分支,多用分支
分支相当于就是:
我想基于这个提交以及它所有的父提交进行新的工作。
合并

执行了命令:git merge bugFix 将分支bugFix合并到当期分支,

将master分支合并到bugFix :git checkout bugFix;git merge master

现在每个分支都包含了代码库的所有修改,大功告成!

git rebase
一种合并方式 git rebase.
Rebase实际上就是取出一些的提交记录,“复制”它们,然后在另一个地方逐个放下去。
Rebase 的优势就是可以创造更线性的提交历史,这听上去有些难以理解。如果只允许使用 Rebase 的话,代码库的提交历史将会变得异常清晰。
执行git rebase master (将c3处的分支河合并到主分支)

再次切换分支到主分支也就是master,然后执行:git rebase bugFix将主分支也更新到最新。

相对引用
使用相对引用的话,你就可以从一个易于记忆的地方(比如 bugFix 分支或 HEAD)开始计算。
相对引用非常给力,这里我介绍两个简单的用法:
- 使用 ^ 向上移动 1 个提交记录
- 使用 ~
向上移动多个提交记录,如 ~3
首先看看操作符 (^)。把这个符号加在引用名称的后面,表示让 Git 寻找指定提交记录的父提交。
如果你想在提交树中向上移动很多步的话,敲那么多 ^ 貌似也挺烦人的,Git 当然也考虑到了这一点,于是又引入了操作符 ~。
强制修改分支的位置
我使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:
git branch -f master HEAD~3
上面的命令会将 master 分支强制指向 HEAD 的第 3 级父提交。

浙公网安备 33010602011771号