Git

发表于 | 更新于:
字数统计: 3.3k 字 | 阅读时长 ≈ 12 分钟

git查看命令地址

git.png
github接口文档：https://developer.github.com/v3/repos/

不了解GitHub,可以看 https://github.com/xirong/my-git/blob/master/how-to-use-github.md

作为一名开发者，GitHub上面有很多东西值得关注学习，可是刚刚接触GitHub，怎样一步步学习使用GitHub？怎样更高效的利用GitHub？ 在这里搜集整理网络上面的资料，汇总成这么一篇repo 《GitHub使用指南》，供大家一起学习。

GitHub Skills

更多关于 GitHub 的内容请查看：GitHubHelp 查找需要的信息。

原文地址：http://www.worldhello.net/gotgithub/index.html

一、Git 有什么奇技淫巧？

  • 如何以光速查看一行代码的提交记录
  • 在保存所有的文件的情况下，删除所有的commit记录：
  1. 检出
1
git checkout --orphan latest_branch
  1. 添加所有文件夹
1
git add -A
  1. 评论消息改动
1
git commit -am "just come and commit"
  1. 删除分支
1
git branch -D master
  1. 将现有分支设置为master
1
git branch -m master
  1. push
1
git push -f origin master
  1. 在尝试过所有命令都不能把你从深渊里挽救出来的时候, git reflog 也许能起作用。
  2. 比如撤销一次 rebase（rebase 可是会直接修改历史的，一定要了解原理后再使用） Undoing a git rebase
  3. 每次 merge 完总是出现很多 .orig 文件，使用 git clean -f 干掉所有 untracked files
  4. rebase 一个 diverged 分支一直要解决冲突很痛苦，可以尝试在自己的分支先 squash 一下，git rebase -i，然后再 rebase 主干，解决一次冲突就 ok 了
  5. 本地有很多其实早就被删除的远程分支，可以用 git remote prune origin 全部清除掉，这样再 checkout 别的分支时就清晰多了.

  6. 1
    git bisect

有没有过写了一天的代码，checkin无数，结果突然发现之前没注意的地方break的时候？
这个时候要在茫茫commits里寻找那个错误的commit是多么的痛苦啊。git-bisect就是大救星！
git-bisect本质上就是一个二分法，用起来也很简单：

1
2
3
git bisect start        #start
git bisect bad          #current branch is bad
git bisect good <SHA-1> #some old commit that is good

然后只要不停的告诉git当前commit是不是好的，

1
git bisect good

or

1
git bisect bad

就能找到罪魁祸首了！

二、Git log常见用法

三、git checkout 命令详解

四、git重要的三个命令stash, checkout, reset的一些总结

  1. 正常的情形，修改工作区的文件然后add，commit，我使用git一般的流程是：git status ——> git stash save “message…”——> git pull –> git stash pop ——> git add . 或 git add filename ——> git commit -m ‘message…’ ——> git push 其中 . 表示所有的文件。
  2. 只需要撤销工作区的文件修改，即用暂存区的文件覆盖工作区中的文件

git checkout – filename

  1. 当修改的文件已经add到暂存区，需要撤销这次添加，即撤销上一次git add filename 操作：

git reset – filename / git reset HEAD filename
撤销暂存区内所有的文件改动:
git reset / git reset HEAD

  1. 当对上次提交不满意，可以让HEAD指针回退，而暂存区和工作区可以不用动

git reset –soft HEAD^

  1. 如果让工作区不改变，而暂存区和引用（HEAD指针）回退一次

git reset –mixed HEAD^

  1. 当需要彻底撤销最近的提交，HEAD指针、暂存区、工作区都回到上次的提交状态，自上一次以来的提交全部丢失

git reset –hard HEAD^

git stash 用于保存和恢复工作进度。

  • git stash 保存当前的工作进度。会分别对暂存区和工作区的状态进行保存。

  • git stash list 显示进度列表。此命令显然暗示了git stash 可以多次保存工作进度，并用在恢复时候选择。

  • git stash drop [] 删除一个存储的进度。默认删除最新的进度。

  • git stash clear 删除所有存储的进度。

  • git stash pop [–index] []

    • –index 参数：不仅恢复工作区，还恢复暂存区
    • 指定恢复某一个具体进度。如果没有这个参数，默认恢复最新进度
    • 如：以下命令恢复编号为0的进度的工作区和暂存区 
      1
      # git stash pop --index stash@{0}
    1. 如果不使用任何参数，会恢复最新保存的工作进度，并将恢复的工作进度从存储的工作进度列表中清除。
    2. 如果提供参数（来自git stash list显示的列表），则从该中恢复。恢复完毕也将从进度列表中删除。
    3. 选项–index除了恢复工作区的文件外，还尝试恢复暂存区。这也就是为什么恢复进度的时候显示的状态和保存进度前的略有不同。

  • git stash [save [–patch] [-k|–[no]keep-index] [-q|–quiet] []]

    • 这条命令实际上是git stash命令的完整版。
      • save，即如果需要在保存工作进度的时候使 用指定的说明，必须使用如下格式： git stash save “message…”
      • 使用参数–patch会显示工作区和HEAD的差异，通过对差异文件的编辑决定在进度中 最终要保存的工作区的内容，通过编辑差异文件可以在进度中排除无关内容。
      • 使用-k或者–keep-index参数，在保存进度后不会将暂存区重置。默认会将暂存区和工 作区强制重置。

  • git stash apply [–index] [] 除了不删除恢复的进度之外，其余和git stash pop 命令一样。

    检出命令git checkout是git最常用的命令之一，同时也是一个很危险的命令，因为这条命令会重写工作区。

检出命令的用法如下：
用法一：git checkout [-q] [] [–] …
用法二：git checkout []
用法三：git checkout [-m] [[-b]–orphan] ] []

注：
<1> 为了避免路径和引用（或者提交ID）同名而发生冲突，可以在前用两个连续的短线（短号）–作为分隔。
<2> 在用法一中，

  1. 省略commit：用暂存区的文件覆盖工作区的文件。
  2. 加上commit：用指定提交中的文件覆盖暂存区和工作区中的文件。

<3>在用法二中，会改变HEAD头指针

  1. 加上：因为只有HEAD切换到一个分支才可以对提交进行跟踪，否则仍然会进入“分离头指针”的状态。在“分离头指针”状态下的提交不能被引用关联到，从而可能丢失。

所以用法二（加上）最主要的作用就是切换到某分支。
(2）省略：则相当于对工作区进行状态检查。
<4>在用法三中，主要是创建和切换到新的分支（），新的分支从指定的提交开始创建。新分支和我们熟悉的master分支没有什么实质的不同，都是在refs/heads命名空间下的引用。

下图所示的版本库模型图描述了git checkout实际完成的操作。

image.png
使用：

  • git checkout branch 检出branch分支。要完成图中的三个步骤，更新HEAD以指向branch分支，以及用branch 指向的树更新暂存区和工作区。
  • git checkout / git checkout HEAD 汇总显示工作区、暂存区与HEAD的差异。
  • git checkout – filename 用暂存区中filename文件来覆盖工作区中的filename文件。相当于撤销自上次执行git add filename以来（如果执行过）的本地修改。
  • git checkout – . / git checkout . 这条命令最危险！会撤销所有本地的修改（相对于暂存区）。相当于用暂存区的所有文件直接覆盖本地文件，不给用户任何确认的机会！

git reset是Git最常用的命令之一，也是最危险最容易误用的命令。

用法一：git reset [-q] [] [–] …
用法二：git reset [–soft –mixed | –hard | –merge | –keep] [-q] []
注：
（1）第一种用法（包含了路径的用法）不会重置引用，更不会改变工作区，而是用指定提交状态()下的文件()替换掉暂存区中的文件。
例如：git reset HEAD
　　相当于取消之前执行的git add 命令时改变的暂存区。
（2）第二种用法（不使用路径的用法）则会重置引用。根据不同的选项，可以对暂存区或工作区进行重置。
参照下面的版本库模型图，可以看不同的参数对第二种重置语法的影响。
image.png
命令格式：git reset [–soft | –mixed | –hard] []
（1）使用参数–soft，如 git reset –soft
　　会执行上图中的操作①。即只更改引用的指向，不改变暂存区和工作区。
（2）使用参数–mixed或者不使用参数（默认为–mixed），如 git reset
　　会执行上图中的操作①和②。即更改引用的指向及重置暂存区，但是不改变工作区。
（3）使用参数–hard，如git reset –hard
　　会执行上图中的全部动作①、②、③，（理解为此时工作区、暂存区、commit都相同）即：
　　　　①替换引用的指向。引用指向新的提交ID。
　　　　②替换暂存区。替换后，暂存区的内容和引用指向的目录树一致。
　　　　③替换工作区。替换后，工作区的内容变得和暂存区一致，也和HEAD所指向的目录树内容相同。
注： 引用即HEAD指针

使用：
git reset / git reset HEAD
仅用HEAD指向的目录树重置暂存区，工作区不会受到影响，相当于将之前用git add命令更新到暂存区的内容撤出暂存区。引用也未改变，因为引用重置到HEAD相当于没有重置。
git reset – filename / git reset HEAD filename
仅将文件filename 的改动撤出暂存区，暂存区中其他文件不改变。相当于命令git add filename 的反射操作。
git reset –soft HEAD^
工作区和暂存区不改变，但是引用向前回退一次。当对最新的提交说明或者提交的更改不满意时，撤销最新的提交以便重新提交。
之前提到过修补提交命令git commit –amend，用于对最新的提交进行重新提交以修补错误的提交说明或者错误的提交文件。修补提交命令实际上相当于执行了下面两条命令。（注：文件.git/COMMIT_EDITMSG保存了上次的提交日志）
　　git reset –soft HEAD^
　　git commit -e -F .git/COMMIT_EDITMSG
git reset HEAD^ / git reset –mixed HEAD^
工作区不改变，但是暂存区会回退到上一次提交之前，引用也会回退一次。
git reset –hard HEAD^
彻底撤销最近的提交。引用回退到前一次，而且工作区和暂存区都会回退到上一次提交的状态。自上一次以来的提交全部丢失。

五、如何以光速查看一行代码的提交记录

怎么查是谁写的，命令行工具git blame

1
git blame -L 99,99 package.json

即使把这个命令设置为快捷方式，一行一行的查询也是非常耗费精力的，那么有没有一眼可以看到的方式呢？那就是直接在 GitHub 上查。