标签:git init tom 移动 bash out 最新版 怎么办 界面 head
查看git有没有安装,直接输入命令
git
如果未安装,会提示安装命令,根据提示安装即可
1)先安装homebrew
在命令行输入以下命令
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
2)使用homebrew安装git
brew install git
1)创建版本库
使用如下命令创建版本库
# 将当前目录作为一个git仓库
git init
2)查看当前版本库状态
git status
3)添加文件到暂存区
# 添加单个文件
git add 1.txt
# 添加多个文件
git add 1.txt 2.txt
# 提交新文件(new)和被修改(modified)文件,不包括被删除(deleted)文件
git add .
# 提交被修改(modified)和被删除(deleted)文件,不包括新文件(new)
git add -U
# 添加所有修改(上两个功能的集合)
git add -A
4)比较当前工作区、暂存区、分支之间的差异
# 查看当前工作区与暂存区的差异,也就是修改了还没有add的部分(不包括新建文件)
git diff
# 查看暂存区与分支之间的差异,也就是add了还没有commit的部分
git diff --cached
5)撤销修改
撤销修改有两种情况:
一是这个文件自修改后还没有被放到暂存区,现在,撤销修改就回到和版本库一模一样的状态;
二是已经添加到暂存区后,又作了修改,现在,撤销修改就回到添加到暂存区后的状态。
总之,就是让这个文件回到最近一次git commit
或git add
时的状态。
git checkout -- 1.txt
如果已经add到暂存区但是还没有提交,想要回退怎么办呢,可以使用如下命令
# 把暂存区的修改撤销掉(unstage),重新放回工作区
git reset HEAD 1.txt
注意:git reset
既可以回退版本,也可以把暂存区的修改回退到工作区,当我们用HEAD
时,表示最新的版本。
然后再使用git checkout
丢弃工作区的修改就可以了
4)提交
# 格式:git commit -m <message>,不加message会跳转到vim界面
git commit -m "create 1.txt"
5)查看提交的版本记录(注意版本回退后看不到回退版本号之后记录)
git log
# 让结果一行显示
git log --pretty=oneline
6)版本回退
# 回退到上一个版本(HEAD表示当前版本)
git reset --hard HEAD^
# 回退到上两个版本
git reset --hard HEAD^^
# 回退到上五个版本
git reset ---hard HEAD~5
7)查看使用git 命令进行操作的日志(可以查看所有的版本记录)
git reflog
8)删除文件
加入你删除了一个文件
rm 1.txt
如果你确实要删除这个文件,使用git rm
就行
git rm 1.txt
git commit -m "remove 1.txt"
如果删错了,想要恢复,也容易,因为版本库还有,可以很轻松地把误删文件恢复到最新版本
git checkout -- 1.txt
git checkout
其实是用版本库里的版本替换工作区的版本,无论工作区是修改还是删除,都可以“一键还原”。
1)工作区(Working Directory)
工作区就是所在目录
2)版本库(Repository)
工作区有一个隐藏目录.git
,这个不算工作区,而是Git的版本库。
Git的版本库里存了很多东西,其中最重要的就是称为stage(或者叫index)的暂存区,还有Git为我们自动创建的第一个分支master
,以及指向master
的一个指针叫HEAD
。
每次提交,Git都把它们串成一条时间线,这条时间线就是一个分支,git默认有一个master分支,称为主分支
一开始的时候,master
分支是一条线,Git用master
指向最新的提交,再用HEAD
指向master
,就能确定当前分支,以及当前分支的提交点
每次提交,master
分支都会向前移动一步,这样,随着你不断提交,master
分支的线也越来越长。
当我们创建新的分支,例如dev
时,Git新建了一个指针叫dev
,指向master
相同的提交,再把HEAD
指向dev
,就表示当前分支在dev
上:
不过,从现在开始,对工作区的修改和提交就是针对dev
分支了,比如新提交一次后,dev
指针往前移动一步,而master
指针不变:
假如我们在dev
上的工作完成了,就可以把dev
合并到master
上。Git怎么合并呢?最简单的方法,就是直接把master
指向dev
的当前提交,就完成了合并:
合并完分支后,甚至可以删除dev
分支。删除dev
分支就是把dev
指针给删掉,删掉后,我们就剩下了一条master
分支:
1)创建分支
# 创建分支
git branch dev
# 切换到dev分支
# 创建并切换到dev分支(上述两条命令合一)
git checkout -b dev
2)查看分支
git branch
3)合并分支
# 切换到master分支
git checkout master
# 将dev分支合并到当前分支
git merge dev
git merge
命令用与合并指定分支到当前分支,注意到上面的Fast-forward
信息,Git告诉我们,这次合并是“快进模式”,也就是直接把master
指向dev
的当前提交,所以合并速度非常快。
4)删除分支
合并之后就可以删除dev分支了,命令为
git branch -d dev
因为创建、合并和删除分支非常快,所以Git鼓励你使用分支完成某个任务,合并后再删掉分支,这和直接在master
分支上工作效果是一样的,但过程更安全。
注意:如果在一个分支上修改了但没有commit,那么切换到其他的分支后还是能看到之前分支做的修改,因为工作区和暂存区对所有分支来说是公共的
加入我们两个分支上都分别做了修改,这种情况下,Git无法执行“快速合并”,只能试图把各自的修改合并起来,但这种合并就可能会有冲突,提示
CONFLICT (content): Merge conflict in readme.txt
Automatic merge failed; fix conflicts and then commit the result.
使用git status
来查看冲突文件
打开冲突文件,可以看到git用<<<<<<<<
, =========
, >>>>>>>>
标记出不同分支的内容,我们可以手动修改后保存再提交,现在,master
分支和feature1
分支变成了下图所示:
使用带参数的git log可以看到分支的合并情况
git log --graph --pretty=oneline --abbrev-commit
通常,合并分支时,如果可能,Git会用Fast forward
模式,但这种模式下,删除分支后,会丢掉分支信息。
如果要强制禁用Fast forward
模式,Git就会在merge时生成一个新的commit,这样,从分支历史上就可以看出分支信息。
# 切换到master分支
git checkout master
# --no-ff表示禁用fast forward模式合并
git merge --no-ff -m "merger with no-ff" dev
注意使用--no-ff
模式会提交一个新的commit,所以要加上-m "message"
不使用fast forward模式,merge后如下图
在实际开发中,我们应该按照几个基本原则进行分支管理:
首先,master
分支应该是非常稳定的,也就是仅用来发布新版本,平时不能在上面干活;
那在哪干活呢?干活都在dev
分支上,也就是说,dev
分支是不稳定的,到某个时候,比如1.0版本发布时,再把dev
分支合并到master
上,在master
分支发布1.0版本;
你和你的小伙伴们每个人都在dev
分支上干活,每个人都有自己的分支,时不时地往dev
分支上合并就可以了。
所以,团队合作的分支看起来就像这样:
标签:git init tom 移动 bash out 最新版 怎么办 界面 head
原文地址:https://www.cnblogs.com/zzliu/p/11336786.html