Git的那些事,怎么利用git高效管理项目,git commit,git reset,git revert

1. Git 维护的三棵树

  • workingDir 工作目录,持有的实际文件,修改代码都是在这里发生的
  • inex 缓存目录,临时保存你的改动,add 之后就是进入这个缓存目录
  • HEAD 一般是指向最新一次 commit 的引用,调用commit后就到这里


    gitindex.png

2. 本地添加远程仓库的关联

如果你本地有一个git仓库并且书写了很多代码,你的远程仓库有一个空的仓库,现在需要把本地的代码关联到远程仓库的话,你可以这么做

git remote add origin <server>  

server就是指的远程仓库地址,比如(git@github.com:kingtouch/My_Test.git

3.创建代码仓库

git init <directory>  

创建一个空的 Git 仓库。运行这个命令会创建一个名为 directory,只包含 .git 子目录的空目录。

git clone <repo> <directory>  

将位于 <repo> 的仓库克隆到本地机器上的 <directory> 目录。

4.保存修改

当你修改了很多文件之后想要保存修改需要怎么做呢?在Git的工作流中其实就是从工作区到缓存区到HEAD流转的过程

  • 查看更改状态
   git  status  
  • 将更改添加到缓存去
   git  add .  

添加所有更改到缓存去

当然也可以添加指定文件和文件夹下的修改,如下方式

    git add <file>  
    git add <directory>  
  • 将缓存区添加到HEAD

可以使用如下三种commit指令

   git commit   
   git commit -m "提交内容描述"  
   git commit  -a   
  • Git 提供了可以重写项目历史的命令,如下指令
   git commit --amend  

它允许你将缓存的修改和之前最近的提交合并到一起形成一个新的提交快照,如果提交到远程的话会覆盖之前的快照显示的是新提交的快照

5.查看状态

查看状态分为两种方式

  • git Status 查看工作区和缓存区的状态
  • git log 显示已经commit的记录

git log这个命令帮组我们查看历史提交信息,根据不同的命令组合可以查看更加详细的提交信息

git log  
//输出所有提交历史信息  

git log -n <limit>  
//输出limit条提交历史信息。  

git log --oneline  
//将每个提交压缩到一行。当你需要查看项目历史的上层情况时这会很有用。  

git log --stat  
//这个命令显示更详细的信息,包含哪些文件被更改了。  

git log -p  
//这个命令显示了更为详细的信息。显示每个提交全部的差异  

git log --author="<pattern>"  
git log --grep="<pattern>"  
//前者搜索特定作者的提交  
//后者搜索提交信息匹配特定 <pattern> 的提交。<pattern> 都可以是字符串或正则表达  
//式。  

git log <since>..<until>  
//搜索<since> 和 <until> 之间的提交。两个参数可以是提交 ID、分支名、HEAD   
//或是任何一种引用。  

git log <file>  
//搜索指定文件的历史提交信息。 

git reflog
//这个命令可以显示我们git执行了那些操作,并且可以配合git reset  来恢复到指定操作的状态,非常有用。

6.检出

检出我们使用git checkout指令来实现。这个命令有三个不同的作用:检出文件、检出提交和检出分支。

  • 检出文件
git checkout <commitid> <file>  
//这样可以检出指定commitid上的指定文件,看下面具体命令
git checkout a8dye7d readme.md  

执行后将把 a8dye7d 上的readme.md文件的修改检出,且加入到缓存区,即add之后的状态

  • 检出提交
1.git checkout <commit>  
//需要指定的提交id来检出某个指定的提交,执行后更新工作目录中的所有文件,使得和这个commitId提交中的文件一致。这会使你处在分离 HEAD 的状态
  • 检出分支
1.git checkout <branch>  
//执行后工作区切换到了branch分支上,注意调用前要保证当前操作都commit

7.回滚

git提供了git revert和git reset来代码回滚

  • git revert
1.git revert <commit>  

生成一个撤消了 <commit> 引入的修改的新提交,然后应用到当前分支.
操作是将选择的某一次提交记录重做.原始commit还存在,只是让我们重新编辑这个commit,提交会产生一个新的commit。如果revert的commit和后面的commit有修改相同的文件的话,多数会产生冲突。如果是新添加的一个文件,这个文件会重新处于编辑状态待add。

  • git reset

当你用 git reset 来重设更改时(提交不再被任何引用或引用日志所引用),我们无法获得原来的样子——这个撤销是永远的。使用这个工具的时候务必要小心,因为这是少数几个可能会造成工作丢失的命令之一。

git reset <file>  
//从缓存区移除特定文件,它会取消这个文件的缓存,而不覆盖任何更改。只针对add后的文件

git reset  
//从缓存区移除所有文件,而不覆盖任何更改。只针对add后的所有文件
git reset --hard  
//匹配最后一次commit ,把所有工作区和缓存区(即add和没有add的修改)全部抛弃,不保存记录

git reset <commit>  
//将当前分支回退到 <commit>,将缓存区重设到这个提交,这个commit之后的修改都还保存在工作区,相当于没有add的状态

git reset --hard <commit>  
//将当前分支回退到 <commit>,这个commit之后的修改全部清除没有记录

8.合并

git提供两种方式合并rebasemerg

git rebase <base>  
//<base>可以使 commitID、分支名、标签,或是 HEAD 的相对引用

rebase 把提交commit记录从一个分支移到了另一个分支,保持了一个线性的项目提交历史,如上这个命令执行后会将base上的commit记录迁移到当前分支上,如果有相同的文件修改会有冲突产生。

图片1.png

如图很明显,在Master上调用 git rebase Feature后,Feature上的commit1 和commit2 迁移到了Master上,形成一条线性的提交记录
当然我们也可以使用git rebase <base> -i来交互式合并

来看看merg,可以使用如下命令

git merg <branch>  

使用merg不会像rebase一样保持整个commit线性记录,他会生成一个新的mergcommit其中包括了被merg分支的所有更改,如下图。


图片2.png

9.同步代码

我们可以使用git fetchgit pull来保持代码同步

git fetch 命令将提交从远程仓库导入到你的本地仓库

1.git fetch <remote>  
2.//拉取<remote>仓库中所有的分支。同时会从另一个仓库中下载所有需要的提交和文件。  
3.  
4.git fetch <remote> <branch>  
5.//和上一个命令相同,但只拉取指定的分支。  
6.//<remote>是连接的名称,一般为origin 

git pull 将上游更改合并到你的本地仓库

git pull <remote>  
//拉取当前分支对应的远程副本中的更改,并立即并入本地副本。效果和 git fetch 后接 git //merge origin/. 一致。  

git pull --rebase <remote>  
//和上一个命令相同,但使用 git rebase 合并远程分支和本地分支,而不是使用 git merge。  

//rebase和merg的区别上面有介绍  

git push 将本地仓库中的提交转移到远程仓库中,和pull 恰好相反

git push <remote> <branch>  
//将指定的分支推送到 <remote> 上,如果remote上没有这个branch ,远程会创建这个  
//branch。如果push会导致目标仓库非快速向前合并时,Git 不允许你 push。  
  
git push <remote> --force  
//和上一个命令相同,但即使会导致非快速向前合并也强制推送。除非你确定你所做的事,否则  
//不要使用 --force 标记。  
  
git push <remote> --all  
//将所有本地分支推送到指定的远程仓库。  
  
git push <remote> --tags  
//--tags 将你所有的本地标签推送到远程仓库中去。
//<remote>是连接的名称,一般为origin  

10.分支管理

git branch  
//列出仓库中所有分支。  

git branch <branch>  
//创建一个名为 <branch> 的分支。不会 自动切换到那个分支去。  

git checkout  -b <branch>  
//依托当前分支,复制一个名为 <branch> 的分支。会 自动切换到那个分支去。  

git branch -d <branch>  
//删除指定分支。这是一个安全的操作,Git 会阻止你删除包含未合并更改的分支。  

git branch -D <branch>  
//强制删除指定分支,即使包含未合并更改。如果你希望永远删除某条开发线的所有提交,你应  
//该用这个命令。  

git branch -m <branch>  
//将当前分支命名为 <branch>。  

git push origin --delete <branch>  
//将远程的中央分支删除  
```java
``
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 212,185评论 6 493
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 90,445评论 3 385
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 157,684评论 0 348
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 56,564评论 1 284
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 65,681评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,874评论 1 290
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,025评论 3 408
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,761评论 0 268
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,217评论 1 303
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,545评论 2 327
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,694评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,351评论 4 332
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,988评论 3 315
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,778评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,007评论 1 266
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,427评论 2 360
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,580评论 2 349

推荐阅读更多精彩内容