git常用命令和基本操作
开始之前
本文仅对平时工作和学习中对git的使用做一个总结, 同时本文不再讲述什么是git, git是怎么诞生的, git的安装与配置, 以及一些专业术语(主要是不敢乱说)等, 本文只专注于用. 如果需要相关知识, 请查看廖雪峰老师的教程, 如果英文能力比较好可以直接看Git官方教程(当然, 也有中文版的教程)
但是我们必须要知道, 为什么要用git?
1 为什么用git
我问过别人, 为啥用git? 他告诉我, git好啊, 我追问好在哪? 他说git是分布式管理的啊,很牛逼的!然而到目前为止, 我对分布式仍然不是特别理解.所以我举个来说明为啥要用git
1.1 产品第一次找你
我收到一个需求, 某个功能被舍弃了! 我内心一万个妈卖批, 但又无可奈何, 谁让人家是产品锦鲤! 简单粗暴, 删! 可是鉴于以往产品锦鲤的表现, 我又很嘀咕, 万一将来又要启用这个功能, 难道我要重写一遍?但是这难不倒聪明的我, 我把这段代码copy出来一份, 存起来不就好了嘛, perfect!
1.2 产品第二次找你
没多久产品锦鲤又来了, 这次是另一个功能要重新改版, 这个1个功能里面有10个小的细节点, 产品说这个这个还有这个, 而且是分版本慢慢砍掉! 所以我开始, copy一份v1.1.1的代码文件, copy一份1.1.3的代码文件…
过不了多久, 我记不清我到底copy了多少份代码, 或者存放在哪里了, 或者电脑坏了我也没备份, 或者哪天某个功能又重新启用了, 我不得不逐个的去翻之前的文件保存!看着这一堆的文件, 我想删又不敢删, 想留着这一坨, 又怕越积越多!
1.3 公司壮大了
由于业务突出, 公司发展迅猛, 原本iOS客户端就你一个程序员, 突然变成了5个! 我的代码中耦合了同事A的代码, 同事A的代码公用了同事B的封装! 同时, 别的同事也遇到了产品锦鲤的"刁难"! 此时, 我再需要改动时, 我必须得想想: 我改动会不会影响别的同事? 我做了哪些改动?哪天改的? 万一改错了同事会不会拿刀砍死我?我拿起桌上的一本书
我太难了!
1.4 git闪亮登场
上面我自己举了个例子, 不太恰当, 抱歉各位, 产品大佬请放下手里的刀!
那么, git能干嘛?
git就能干上面让你头疼的事, 它能让你不在自己考虑备份不同文件, 你只需要几个命令, 咔咔咔提交到git仓库, 完美解决, 来一张廖雪峰老师的图:
2 四个区、四种状态和一个库
2.1 四个区
这四个区, 指的是代码文件存放的四个不同位置, 其中前三个都是在自己本地存储, 最后一个是在远端gitLab或gitHub或码云等云平台存储.
- 工作区, 就是你创建的那个用来干活的文件夹
- 暂存区: 在.git目录下管理, git add之后存在这里
- 本地仓库: 在.git目录下管理, git commit之后存在这里
- 远程仓库: 本地仓库git push之后存在这里
关系如下图(来源于网络):
2.2 一个库
版本库
在执行git init之后, 你创建的干活文件夹也就是你的工作目录中, 会出现一个.git后缀的隐藏文件, 这就是版本库, 这
顾名思义, 版本库就是用来做版本管理的, 并由git全程跟踪管理. 从你执行git add操作以后, git就开始对你的代码文件等进行跟踪管理, 分门别类当好管家. 它管理着三个目录: 暂存区、本地仓库和对象库(objects). 这两个区和工作区之间的关系如下图:
这里有几个需要注意的地方(他们的工作流程请看这里)
- master(本地仓库): 本质是一个目录树, 管理着你本地仓库里面的所有本地分支目录, 如master、dev、 feature、 test,、debug,、release、热更新分支等等. master只是树的主干
- HEAD: 是一个指针并指向你的工作分支. git分支本质就是指向 commit 对象的可变指针, 通过这个指针git得知你是在哪个分支工作, 这个指针就是HEAD, 换句话说它是你分支的别名.
- objects: git的对象库, 位于".git/objects" 目录下, 里面包含了创建的各种对象及内容.
2.3 四种状态
这里的状态, 指的是修改(新增或删除)被git管理追踪的状态, 分别为:
- Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged
- Staged: 暂存状态. 执行git commit则将修改同步到本地库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified
- Unmodify: 文件已经入库, 未修改, 即本地库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件
- Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改, 返回到unmodify状态. git checkout即从库中取出文件, 覆盖当前修改
关系图如下(来源于网络):
3 git基础操作
主要涉及工作区到暂存区, 暂存区到本地仓库, 以及文件状态日志相关
3.1 git init 初始化仓库
把你准备好的目录变成Git可以管理的本地仓库
$ git init
Initialized empty Git repository in /Users/xxx/.git/
完成之后你就创建了自己的本地仓库, 你会看到下面几个文件!其中所有有关你的此项目的快照数据都存放在这里, Git用它跟踪管理版本库. 注意, 这个不能动
ls -a
. .. .git
3.2 git add 添加内容
此时, 你在本地仓库目录中创建了一个文件, README, 需要添加到仓库! 你可以选择使用git add先添加到暂存区
- git add 文件名, 只添加某一个文件
- git add . 一次性添加所有文件
$ touch README
$ ls
README
$ git add README
3.3 git status 查看状态
此命令用于查看项目的当前状态, 当没有输入git add命令时, 会这样显示
$ git status
Initial commit
Changes to be committed:
(use "git rm --cached ..." to unstage)
// 有一个新文件
new file: README
输入git add命令后, 会这样显示(-s参数, 获取简短输出, 不加-s 默认输出详细内容)
$ git status -s
A README
$
3.4 git diff 查看不同
git diff命令查看git status的结果的详细信息, 显示已写入缓存与已修改但尚未写入缓存的改动的区别
- git diff 尚未缓存的改动
- git diff --cached 查看已缓存的改动
- git diff HEAD 查看已缓存的与未缓存的所有改动
- git diff --stat 显示摘要而非整个
假如你往README文件中, 写入"hello world"
$ git diff
diff --git a/README b/README
index e69de29..69b5711 100644
--- a/README
+++ b/README
@@ -0,0 +1,3 @@
...
3.5 git commit 提交内容快照
当你检查无误之后, 可以使用git commit 命令可以一次性把所有暂存区文件内容变更全部提交到本地git仓库, 在git中 commit代表快照信息
-m参数后面输入的信息代表你对本次修改的说明, 这样方便别人阅读和以后查找, 不是必须但是建议写上有意义的描述
$ git commit -m '添加readme文件'
[master (root-commit) d32cf1f] 添加readme文件
1 files changed, 4 insertions(+)
create mode 100644 README
此时我们再查看状态
$ git status
# On branch master
// 在当前分支上, 没有需要的提交
nothing to commit (working directory clean)
3.6 git commit -a 合并两步
如果你觉得 add commit太麻烦, 你可以用此命令, 一次性完成, 不过非常不建议这么做
3.7 git log 查看提交日志
git log命令显示从最近到最远的提交日志, 且每条日志上都会有当次提交的快照id, 即commit id
$ git log
// 其中HEAD代表当前版本
commit 1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master)
Author: Michael Liao .com>
Date: Fri May 18 21:06:15 2018 +0800
. . .
3.8 git reset 回退
git reset HEAD命令, 用于取消已经在暂存区的文件修改, 如A, B两个文件都产生了修改, 并且git add .存入暂存区, 此时你发现A中文件修改错了, 需要撤回重新修改回到之前的版本, 那么你可以这样做
$ git reset HEAD A
// 重置修改
Unstaged changes after reset:
M A
同样的, 你可以回到你曾经的某个版本中, 当你用git log时会打印出你的曾经提交记录, 此时使用git reset --hard commit id, 就穿梭到了当时提交时的代码版本,当然也可以根据当前的commit id再回到当前的版本
$ git reset --hard 1094adb7b9b3807259d8cb349e7df1d4d6477073
此时, 你修改好了, 关机下班, 第二天回来又后悔了, 又想回退到之前的版本但是又没有之前版本的commit id, 怎么办?
这时, git强力后悔药仍然可以挽救你. 使用git relog用来记录你每次输入的命令
$ git reflog
e475afc HEAD@{1}: reset: moving to HEAD
1094adb (HEAD -> master) HEAD@{2}: commit: commit id1
e475afc HEAD@{3}: commit: commit id2
eaadf4e HEAD@{4}: commit (initial): wrote a readme file
3.9 git rm 删除
- git rm 删除已跟踪文件清单中中的某个文件
- git rm -f 强制删除之前修改过并且已经放到暂存区的文件
- git rm --cached 只删除跟踪清单中文件(删除暂存区), 但本地保留(不删除工作区)
**3.10 git mv **
git mv 命令用于移动或重命名一个文件、目录、软连接
$ git mv README README.md
$ ls
README.md
3.10 git checkout
工作区的文件被修改, 这时你不想修改, 就可以使用git checkout丢弃修改, 这里分为两种情况:
- 只在工作区的修改, 没有被提交到暂存区, 使用git checkout撤销修改后就本地库一模一样
- 修改已经被添加到暂存区, 又作了修改, 这时使用git checkout撤销修改后, 就回到添加到暂存区后的状态
换句话说,
第一种情况是回到上一次 git commit后的状态
第二种情况是回到上一次 git add 后的状态
// 有 -- 代表丢弃修改
// **没有 -- 代表切换分支**
$ git checkout -- file
4 git远程命令
如何对远程仓库进行配置, 这里不再讲述
4.1 git clone 拷贝仓库
如果你们是协同开发需要与他人合作一个项目, 或者自己想要复制一个项目, 看看代码, 这些个项目已经在远端存在了, 你就可以克隆那个项目. 执行命令：
// cd 到你的目录中
// 需要注意的是, git支持多种协议, 换句话说
// 你可以通过git clone SSH:...(默认是此方案, 因为安全还快)
// 你也可以通过 git clone https:...(又慢又麻烦)
git clone [url]
4.2 git remote add 关联仓库
当你在本地建立了仓库, 又在远端建立了远程仓库, 这时, 你想把两者关联在一起, 就输入:
// 如果你在推送的时候推不上去, 就有可能是因为仓库和你本地的SSH验证不通过
// orgin 代表远程库, git默认此写法
$ git remote add origin git@github.com:你的远程仓库账户名/learngit.git
4.3 git push 推送
把本地仓库中已经没问题的所有本地提交, 推送到远程仓库, 这样你的同事也可以看你的代码了推送时. 要指定本地分支, git就会把该分支推送到远程库对应的远程分支上
但是, 并不是所有分支上的修改都必须推送到远端, 这取决于是否需要和远端同步, 以及是否和同事协同开发. 一般来说, test分支, master分支, feature(协同开发)分支需要和远端同步! 如果你本地创建了一个debug分支, 那就没必要和远端同步, 大家都很忙, 没工夫看我们写的 ‘辣鸡’ 代码! 当然, 反正我是不愿意给别人看我改的bug的~~-.-
// orgin master 推送到远程master分支
// 在开发中, master分支是慎重的, 一般都没有权限直接推送远程master分支
// 通常情况下, 我们都是在feature分支进行开发, 当开发完成时, 会推送到test分支
// 等pre 才会由负责人把代码推送到master分支, 当然不同的公司有不同的工作流程, 但是相同的是 你不能往master分支直接推送, 其实你根本没权限, 哈哈哈哈
// 如果远程库是空的, 当你第一次推送时可以加上-u参数, Git不但会把本地的master分支内容推送的远程新的master分支, 还会把本地的master分支和远程的master分支关联起来
$ git push -u origin master
当你第一次push或者clone和git连接时, 会得到一个警告, 其实就是个确认信息的验证
The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?
当你在本地创建了分支, 需要推送到远端
git push origin branch_name
并且建立本地分支和远端分支之间的联系
git push --set-upstream origin branch_name
4.4 git pull 拉取
git pull
5 git管理命令
我们先来讲一下每次是怎么提交的, 前面讲过, HEAD指针指向的是你自己的工作分支, 它并不是只指向master主分支, 它更不是指向提交.
那什么才是指向提交呢? 答案是master! 如果你用过souretree, 你肯定注意过一条主线, master始终指向这条主线, 每次提交master就会走一步, 产生一个新的节点. master分支的版本号一般情况下是低于你的工作分支的(因为master分支一般是生产环境代码, 而你的开发是超于生产环境的)
最最开始时, 你的分支是这样子的
后来, 你checkout出了一个新分支, 这时HEAD指针指向了你的新分支
你或者你们在dev分支上不停的写代码(bug), 慢慢的, 你的工作分支已经超前master分支
直到某天, 你或者你们bug写完了, debug也完成了, 这时你或者你的的leader提交dev分支到master, 这样就完成了分支的合并, 此时master和本地同属一个版本
分支合并完成了, 这次的迭代任务完成, 这时你不想要这个分支了(实际开发中dev分支一般不会删除), 你还可以把这个分支删除, 删除后你的master分支就成了你的工作分支, HEAD也指向了master(在这只作为例子, 假定只有这两个分支)
到此, 你完成了一次版本的迭代开发! 下面我们开始分析上面过程中你遇到的git 管理命令
5.1 git branch 创建或显示或删除分支
// 列出本地所有分支
$ git branch
* dev
master
// 创建新的分支
$ git branch branchname
Switched to branch 'dev'
// 删除分支
$ git branch -d dev
Deleted branch dev (was b17d20e).
创建切换分支还可以用switch
// 创建分支 -c creat
$ git switch -c 分支名
// 切换到分支
git switch 分支名
5.2 git checkout 检出或切换分支
// 切换到某个分支
$ git checkout master
Switched to branch 'master'
5.2 git checkout -b 创建并切换
git checkout命令加上-b参数表示创建和切换命令和在一起, 即:
$ git checkout -b dev
Switched to a new branch 'dev'
等价于
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
5.3 git merge 合并分支
- 先切换到要合并的分支
- 再在当前分支合并需要被合并的分支
// 切换到master分支
// 合并dev分支到master
$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
readme.txt | 1 +
1 file changed, 1 insertion(+)
6 git分支管理
我们来先讲一个让开发者非常 ‘秃然’ 的问题, 冲突!!!
6.1 冲突
造成冲突的原因是, 两个或多个人, 对同一个文件进行了修改! 这里要注意的是, 这句话的重点是对同一个文件进行了修改! 即使你自己开发, 也有可能造成冲突!
6.1.1 我们先来分析, 自己和自己冲突
你本地有master、feature两个分支, 你现在在feature上的README文件中了一句话 “This is a change”. 然后你使用commit到了本地仓库. 之后, 你切换到了master分支, 也在README文件中添加了一句修改 “What changed?”.同样的, 修改之后你提交到了本地仓库. 这个时候你在两个分支对同一个文件都进行了修改, 如图
此时, 如果你把feature分支合并到当前master分支, git无法执行“快速合并”, 只能尝试把你在两个分支上的修改合并起来, 但这种合并就可能会有冲突
$ git merge feature1
Auto-merging readme.txt
CONFLICT (content): Merge conflict in readme.txt
// 果不其然, git 告诉你合并失败, 赶紧去修改冲突再提交
Automatic merge failed; fix conflicts and then commit the result.
你必须修改冲突, 并提交, 提交后的分支, 长这个样子
6.1.2 我们再分析, 自己和别人冲突.
因为是协同开发, 免不了有时候两个人或多个人会在各自的本地仓库的同名分支进行修改, 当你们同时修改同一文件时, 势必就会产生冲突.我们举个
假设你们两个人开发, 甲乙同时修改person.m文件. 原始代码版本是版本1, 甲经过一顿操作开发出了版本2, 并且提交了代码推送到了远程分支! 这时, 乙也开发完成,这是版本3, 这时他也需要提交代码. 因为之前甲已经提交过代码, 即此时远端代码版本由版本1变更为版本2, 而乙仍然是基于版本1进行开发出版本3的. 所以如果乙想提交代码, 必须把远端的代码pull下来, 更新自己本地的代码版本为版本2, 这时, 冲突产生! 好了, 解决冲突提交吧!
6.2 如何解决冲突
解决冲突可是一件非常大的事情! 因为协同开发, 在开发中很可能因为我自己操作不当, 导致代码冲突, 此时我怎么解决? 我把别人代码直接丢弃, 同事估计会拿刀砍死我; 如果我用别人的代码直接更改我本地的代码, 那我岂不是白写了半天bug?
正确流程, 应该这样
- 首先将本地代码暂存起来git stash；
- 然后pull远端代码对本地进行更新, 以使版本一致;
- 再将暂存的代码合并到更新后的代码版本中, 有冲突手动解决(强烈建议解决前咨询相关冲突人员, 以防被打)；
- 最后, 提交commit
6.3 如何避免冲突
通过我自己的使用过程和从网络上搜索资源, 到目前为止, 很不幸的告诉你, 我们只能降低冲突产的概率, 不知道有没有大佬能完全避免冲突, 这点我不确定. 除非你怂恿老板把其他程序员全开除了, 即使这样我们前面也讲过自己和自己还会冲突呢, 狠人都是自己都打的.
我们只能从流程上规范, 以降低出现冲突的概率; 总之只能降低, 很难完全避免(我用很难吧, 我也不知道是否能完全避免)
- 切换分支之前, 务必提交;
- 不要在需要合并的分支(主线, 本次迭代的公共支线)做修改;
- 开发之前做有效的沟通, 尽量避免同一时间段修改同一文件;
6.4 分支策略
在多人开发中, 往往有很多分支, 其中
- master分支, 一般只用来做版本发布, 普通开发者不能动(一般也没有权限动)
- dev分支, 该分支一般情况下用来做开发和自测, 你们都在本地保存了各自的dev分支, 然后每个人不定时向远端推送合并dev分支
- feature分支, 该分支一般出现在有较强的版本迭代管理的项目中, 不常驻
- debug分支, 该分支一般是应对线上重大bug紧急修复, 一般也不常驻
- hotupdate分支, 该分支一般用来做热更新(之前我们的SaaS项目有这个分支)
本文完
我是个Coder界的小学生, 如有不足, 万望不吝指教
转载请注明作者和链接哦!
参考资料:
菜鸟教程
git中文教程
廖雪峰老师的git教程