Git学习笔记

1. Git简介

 

2. 版本创建

2.1 安装

sudo apt-get install git

2.2 创建一个版本库

(1)创建一个目录git_test,在git_test目录下创建一个版本库,命令:

git init

(2)在git_test目录下创建一个文件code.txt,编辑内容如下:

vim code.txt

(3)使用如下命令可以创建一个版本

git add code,.txt
git commit -m '版本1'

 (4)使用如下命令查看版本记录:

如果修改文件code.txt,再执行上面操作

(版本2只是记录了修改,不是复制一份)

3. 版本回退

(1)现在如果想回到某一个版本,可以使用如下命令:

git reset --hard HEAD^

其中,HEAD表示当前最新版本,HEAD^表示当前版本的前一个版本,HEAD^^表示当前版本的前前个版本,也可以用HEAD~1表示当前版本的前一个版本,HEAD~100表示当前版本的前100个版本。

 (2)假如我们现在又想回到版本2,这个时候使用命令:

git reset --hard 版本号

查看之前的log记录,可以查看版本号:

git reflog

4. 工作区和暂存区

4.1 工作区(Working Directory)

电脑中的目录,比如我们的git_test,就是一个工作区。

4.2 版本库(Repository)

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

(1)使用如下命令查看当前工作树的状态:

git status

上面提示我们code.txt被修改,code2.txt没有被跟踪。

(2)使用如下命令将code.txt和code2.txt加入到暂存区,然后执行 git status 命令:

( git .  相当于git add code.txt code2.txt,是把当前目录所有文件加入到暂存区

 

5. 管理修改

git管理的文件的修改,它只会提交暂存区的修改来创建版本。

(1)编辑code.txt,并使用 git add 命令将其添加到暂存区。

(2)继续编辑code.txt,并在其中添加一行。

(3)git commit 创建一个版本,并使用 git status 查看,发现第二次修改 code.txt 内容之后,并没有将其添加到暂存区,所以创建版本时候并没有提交。

6. 撤销修改

(1)修改后没有将其添加到暂存区,使用  git checkout -- code.txt  来丢弃工作区的改动。

(2)继续编辑code.txt,并在其中添加了如下内容,并将其添加到暂存区。

使用  git reset HEAD code.txt 可以把暂存区的修改撤销掉,重新放回工作区。

 (3)现在若想丢弃 code.txt 的修改,执行如下命令(checkout开始)即可:

6.2 小结

(1)场景1 :当你改乱了 工作区某个文件的内容,想直接丢弃工作区的修改时,用 命令:

git checkout -- filename

(2)场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步:第一步,用命令  git reset HEAD filename,这就回到了场景1,第二步按 场景1 操作。

(3)场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考 3.版本回退

7. 对比文件不同

对比工作区和某个版本中文件的不同:

(1)继续编辑文件 code.txt,在其中添加一行内容。

(2)现在要对比工作区中 code.txt 和 HEAD 版本中的 code.txt的不同,使用如下命令:

git diff HEAD -- code.txt

(3)使用下面命令丢弃工作区的改动。

对比两个版本文件的不同:

(1)现在要对比 HEAD 和 HEAD^ 版本中 code.txt的不同,使用如下命令:

(HEAD版本减两行是HEAD的前个版本)

8. 删除文件

(1)我们把目录中的code2.txt删除。

这个时候,git知道删了文件,因此,工作区和版本区就不一致了,git status 命令会立刻提示哪些文件被删除了。

(2)现在你有两个选择,一个确实要从版本库中删除改文件,那就用命令:

git rm file

删除掉,并且 git commit。

 另一种情况是删除错了,可以直接使用git checkout -- code2.txt, 这样文件code2.txt就回来了。

 8.2 小结

命令 git rm 用于删除一个文件。

如果一个文件已经被提交到版本库,那么你永远不用担心误删,但是要小心,你只能恢复文件到最新版本,你会丢失最近一次提交后你修改的内容。

9. 基本操作小结

10. git分支管理

10.1 基本操作

10.11 创建与合并分支

 

(1)一开始的时候,master分支是一条线,git用master指向最新的提交,再用HEAD指向master,就能确定当前分支,以及当前分支的提交点。每次提交,master分支都会向前移动一步,这样,随着你不断提交,master分支的线也越来越长。

(2)当我们创建新的分支,例如dev时,git新建了一个指针叫dev,指向master相同的提交,再把HEAD指向dev,就表示当前分支在dev上。

 Git创建一个分支很快,因为除了增加一个dev指针,改改HEAD的指向,工作区的文件没有任何改变。

(3)不过,从现在开始,对工作区的修改和提交就是针对dev分支了,比如新提交一次后,dev指针往前移动一步,而master指针不变。

(4)假如我们在dev上的工作完成了,就可以把dev合并到master上。git怎么合并呢?最简单的方法,就是直接把master指向dev的当前提交,就完成了合并。

git 合并分支也很快,就改改指针,工作区内容也不变。

(5)合并完成分支后,甚至可以删除dev分支。删除dev分支就是把dev指针给删除掉,删掉后,我们就剩下了一条master分支。

10.12 创建dev分支并切换

(1)执行如下命令,可以查看当前有几个分支并且看到在哪个分支下工作。

git branch

(2)下面创建一个分支dev并切换到其上进行工作

git checkout -b dev

 

 

(3)下面修改code.txt,并进行提交。  

 

 

10.13 切换回master分支

git checkout master

10.14 合并分支

git merge dev

 

注意:上面的Fast-forward信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master指向dev的当前提交,所以合并速度非常快。

10.2 解决冲突

合并分支往往不是一帆风顺的。(两个分支,修改同一个文件情况)

(1)再创建一个新分支dev

(2)修改code.txt,并进行提交。

(3)切换回master分支

(4)在master的code.txt添加一行内容并进行提交

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

(5)执行如下命令尝试将dev分支合并到master分支上来。

 Git告诉我们,code.txt文件存在冲突,必须手动解决冲突后再提交。

(6)git status 也可以告诉我们冲突的文件

(7)查看code.txt内容

 

(9)用 <<<<<<<,=========,>>>>>>>>标记不同分支的内容,我们修改如下后保存:

手动融合后:

(10)现在master和dev分支变成如下图:

(11)用带参数的git log也可以看到分支的合并情况:

git log --graph --pretty=oneline

10.3 分支管理策略

通常,合并分支时,如果可能,git会用fast forward模式,但是有些快速合并并不能成但合并时没有冲突,这个时候会合并之后并做一次新版的提交。

但这种模式下,删除分支后,会丢掉分支信息。

(1)创建切换到dev分支下。

git checkout -b dev

(2)新建一个文件code3.txt编辑内容如下,并提交一个commit。

(3)切换回master分支,编辑code.txt并进行一个提交

如图操作:

(4)合并dev分支的内容到master分支

git merge dev

(5)出现如下,这是因为这次不能快速合并,所以git 提示输入合并说明信息,输入之后合并内容之后git会自动创建一次新的提交(ctrl+x退出)。

  

(6)删除dev分支

git branch -d dev

10.31 强制禁用fast forward模式

如果强制,git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。

(1)创建并切换到dev分支

(2)修改code.txt文件,并提交一个commit

(3)切换回master分支

(4)准备合并dev分支,请注意 --no-ff 参数,表示禁用Fast forward:

git merge --no-ff -m '禁用fast-forward合并' dev

因为本次合并要创建一个新的commit,所以加上 -m 参数,把commit描述写进去。

(5)合并后,用 git log 查看分支历史:

 

10.4 bug分支(什么时候禁用快速合并)

总结:修复bug时,每个bug都可以通过一个新的bug分支来修复,修复后,合并分支(记得禁用快速合并),再将临时分支删除。

当手头工作没有完成时,先把现场工作 git stash 一下,然后去修复bug,修复后,再git stash pop,回到工作现场。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

(1)当你接到一个代号001的bug的任务时,很自然,你想创建一个分支bug-001来修复它,但是,当你正在dev上进行的工作还没有提交。

并不是你不想提交,而是工作只进行到一半,还没法提交,预计完成还需要一天。但是,必须在两个小时内修复改bug,怎么办?

(2)git 还提供了一个 stash 功能,可以把当前工作现场“储存”起来,等以后恢复现场后继续工作。

(3)首先,要确定在哪个分支上修复bug,假定需要在master分支上修复,就从master创建临时分支。

 

(4)现在修复bug,把add new line删掉,然后提交。

(5)修复完成后,切换到master分支,并完成合并,最后删除bug-001分支。需要禁用快速合并!这样可以在log里显示bug合并信息。

 

(6)现在bug-001修复完成,是时候回到dev分支干活了。

(7)工作区是干净的,用 git stash list命令查看:

作业现场还在,git把stash内容存在某个地方了,需要恢复一下:

git stash pop

10.5 小结

11. github使用

11.1 创建仓库

11.2 添加ssh账户

(1)如何生成key

例如,Ubuntu根目录下,执行:

ssh-keygen -t rsa -C "jdouzi@qq.com"

全部回车

把id_rsa.pub中内容复制到网页的key中,完成。

11.3 克隆项目

git clone xxx

11.4 推送代码

git push origin 分支名

例:git push origin douzi

11.5 跟踪远程

(1)将本地分支跟踪服务器分支

git branch --set-upstream-to=origin/远程分支名 本地分支名

例:
git branch --set-upstream-to=origin/douzi douzi

(2)使用 git push 把本地分支推送到远程你跟踪的分支

11.6 拉取代码

git pull origin 分支名称

例:
git pull origin douzi

使用上述命令会把远程分支douzi上的代码,下载并合并到本地所在分支。

12. 工作git使用流程

 

原文地址:https://www.cnblogs.com/douzujun/p/12187388.html