大话 Git 使用

众众众众众所周知，github 是一个好东西。本篇就来说说 Git 的那些指令，网上已经有很多文章，本篇就本不知名小博主在使用过程中用到的一些指令和问题来记录和说明。如果对你有帮助欢迎点赞收藏，觉得写的不好请跳至文末。

---

一个超简明使用的提交模版：

git clone 仓库地址    //进入下载好的本地仓库文件夹下
git add .
git commit -m "备注提交的部分"
git push   //提交自己的修改
git pull  //如果不能push，需要先从远程仓库拉取到别人的修改

当然，你以为 GitHub 就是这么简单的东西么？曾经的我就是这么以为的，至少上面这几个指令让我成功的提交了几次，直到我遇到了冲突……对于使用来说，我觉得最恼火的就是在提交的时候遇到冲突，这时候就需要我们了解各种 Git 指令，对应情况对症下指令了，下面是一些可能会常用到的指令，以列表的形式给出。

Git 的一些指令用法

关于文件

pwd 命令用于显示当前目录。

通过 git init 命令把这个目录变成 Git 可以管理的仓库，文件下就会有一个名为 .git 的隐藏文件夹。如果你没有看到 .git 目录，那是因为这个目录默认是隐藏的，用 ls -ah 命令就可以看见。

使用标准的 UTF-8 编码。

用命令 git add 告诉 Git，把文件添加到仓库。

提交

git commit 命令，-m 后面输入的是本次提交的说明，可以输入任意内容，当然最好是有意义的，这样你就能从历史记录里方便地找到改动记录。

commit 可以一次提交很多文件，所以你可以多次 add 不同的文件。

git status 命令可以让我们时刻掌握仓库当前的状态。

git diff 命令看具体修改了什么内容。

把修改提交到 git 版本库：

提交修改和提交新文件是一样的两步，第一步是 git add（实际上就是把文件修改添加到暂存区）。

在执行第二步 git commit（实际上就是把暂存区的所有内容提交到当前分支）之前，我们再运行 git status 看看当前仓库的状态。

提交后，我们再用 git status 命令看看仓库的当前状态。

即：git add——>git status——>git commit——>git status。

版本退回

git log 命令显示从最近到最远的提交日志,加上 --pretty=oneline 参数显示为一行：

git log --pretty=oneline

在 Git 中，用 HEAD 表示当前版本，上一个版本就是 HEAD^，上上一个版本就是HEAD^^，当然往上 100 个版本写 100 个 ^ 比较容易数不过来，所以写成 HEAD~100。

退回上一个版本 git reset --hard HEAD^。

然后用 git log 再看看现在版本库的状态，用 git log 可以查看提交历史，以便确定要回退到哪个版本。

找到操作文件那步的的 commit id（前面的十六进制数），用 git reset --hard commit_id 指定回到未来的某个版本（未关闭终端窗口的恢复操作）。

Git 提供了一个命令 git reflog 用来记录你的每一次命令。

用 git reflog 查看命令历史，以便确定要回到未来的哪个版本（关闭终端后再想恢复的操作）。

git cat-file 命令显示版本库对象的内容、类型及大小信息,cat 文件名：显示文件内容。

第一次修改 -> git add -> 第二次修改 -> git add -> git commit，每次修改，如果不 add 到暂存区，那就不会加入到 commit 中。

git checkout -- file 可以丢弃工作区的修改

文件自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库一模一样的状态。

文件已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态————让这个文件回到最近一次 git commit 或 git add 时的状态。

用命令 git reset HEAD file 可以把暂存区的修改撤销掉（unstage），重新放回工作区。

当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令 git checkout -- file。

当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD file，就回到了上一点，第二步按上一步（git checkout -- file）操作。

从暂存区提交到了版本库，还没有把自己的本地版本库推送到远程，用退回上一个版本的操作（git reset --hard HEAD^）。

删除文件

rm 文件名：删除该文件。

用 git status 查看哪些文件被删除。

删错了，用 git checkout 文件名：用版本库里的版本替换工作区的版本，无论工作区是修改还是删除，都可以“一键还原”。

git rm 文件名：从版本库删除该文件，并 git commit，之后不能再还原了。

命令 git rm 用于删除一个文件，如果一个文件已经被提交到版本库，误删可恢复，但只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。

关于远程库

添加远程库：在 github 上建立好后，在终端用命令：

git remote add origin git@你的仓库 

在本地关联的就是你的远程库，添加后，远程库的名字就是 origin，这是 Git 默认的叫法，也可以改成别的，但是 origin 这个名字一看就知道是远程库。

git push -u origin master 把本地库的所有内容推送到远程库上，用git push命令，实际上是把当前分支 master 推送到远程。由于远程库是空的，我们第一次推送 master 分支时，加上了 -u 参数，Git 不但会把本地的 master 分支内容推送的远程新的 master 分支，还会把本地的 master 分支和远程的 master 分支关联起来，在以后的推送或者拉取时就可以简化命令。

从现在起，只要本地作了提交，就可以通过命令：

git push origin master

用命令 git clone 克隆一个本地库：

git clone git@你要克隆的仓库

Git 支持多种协议，包括 https，但通过 ssh 支持的原生 git 协议速度最快

创建 dev 分支，然后切换到 dev 分支，git checkout -b dev (git checkout 命令加上 -b 参数表示创建并切换，相当于以下两条命令：

$ git branch dev 
$ git checkout dev

用 git branch 命令查看当前分支，git branch 命令会列出所有分支，当前分支前面会标一个 * 号。

Dev 分支的工作完成，我们就可以切换回 master 分支：git checkout master
把 dev 分支的工作成果合并到 master 分支上：git merge dev，git merge 命令用于合并指定分支到当前分支。

git branch -d dev 删除 dev 分支。

Bug 分支

在 Git 中，由于分支是如此的强大，所以，每个 bug 都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

Git 提供了一个 stash 功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作（如当前正在 dev 上进行的工作还没有提交）。

用 git status 查看工作区，就是干净的（除非有没有被 Git 管理的文件）。

因此可以放心地创建分支来修复 bug。

首先确定要在哪个分支上修复 bug，假定需要在 master 分支上修复，就从 master 创建临时分支：

git checkout master／git checkout -b 分支名

现在修复 bug 然后提交。

修复完成后，切换到 master 分支，并完成合并，最后删除临时分支。

接着回到 dev 分支干活。

用 git stash list 命令看工作现场。

工作现场还在，Git 把 stash 内容存在某个地方了，但是需要恢复一下，有两个办法：
用 git stash apply 恢复，但是恢复后，stash 内容并不删除，需要用 git stash drop 来删除。

用 git stash pop，恢复的同时把 stash 内容也删了。

再用 git stash list 查看就看不到任何 stash 内容，可以多次 stash，恢复的时候，先用 git stash list 查看，然后恢复指定的 stash，用命令：git stash apply stash@{0}。

修复 bug 时通过创建新的 bug 分支进行修复然后合并最后删除，当手头工作没有完成时，先把工作现场 git stash 一下，然后去修复 bug 修复后再 git stash pop，回到工作现场。

每添加一个新功能，最好新建一个 feature 分支，在上面开发，完成后合并，最后删除该 feature 分支。

开发一个新 feature，最好新建一个分支，如果要丢弃一个没有被合并过的分支，可以通过 git branch -D <name> 强行删除。

当你从远程仓库克隆时，实际上 Git 自动把本地的 master 分支和远程的 master 分支对应起来了，并且远程仓库的默认名称是 origin。

要查看远程库的信息，用 git remote。

用 git remote -v 显示更详细的信息。

推送分支，就是把该分支上的所有本地提交推送到远程库 git push。

master 分支是主分支，因此要时刻与远程同步。

Dev 分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步。

Bug 分支只用于在本地修复 bug，没必要推到远程。

Feature 分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

本地新建的分支如果不推送到远程，对其他人就是不可见的。

从本地推送分支，使用 git push origin branch-name，如果推送失败，先用 git pull 抓取远程的新提交。

在本地创建和远程分支对应的分支，使用：

git checkout -b branch-name origin/branch-name

本地和远程分支的名称最好一致。

建立本地分支和远程分支的关联，使用：

 git branch --set-upstream branch-name origin/branch-name

标签

敲命令 git tag <name> 可以打一个新标签。

用命令 git tag 查看所有标签。

默认标签打在最新提交的 commit 上，否则找到历史提交的 commit id，然后用命令 git tag <name> <commit id> 打上标签。

找历史提交的 commit id，用命令 git log --pretty=oneline —abbrev-commit。

标签不是按时间顺序列出，而是按字母排序的，用 git show <tagname> 查看标签信息。

创建带有说明的标签，用 -a 指定标签名，-m 指定说明文字，用命令 git show <tagname> 可以看到说明文字。

通过 -s 用私钥签名一个标签，签名采用 PGP 签名。

创建的标签都只存储在本地，不会自动推送到远程，打错的标签可以在本地安全删除 git tag -d <name>。

推送某个标签到远程，使用命令 git push origin <tagname>。

一次性推送全部尚未推送到远程的本地标签 git push origin —tags。

如果标签已经推送到远程，要删除远程标签先从本地删除再从远程删除，删除命令也是 push。

命令 git push origin :refs/tags/<tagname> 可以删除一个远程标签

关于 Github

在 GitHub 上，可以任意 Fork 开源仓库。

自己拥有 Fork 后的仓库的读写权限。

可以推送 pull request 给官方仓库来贡献代码。

添加一个新的远程仓库，在本地库上使用命令 git remote add <远程库名字> <SSH地址>，再用 git remote -v 查看远程库信息。

git 给远程库起的默认名称是 origin，如果有多个远程库，我们需要用不同的名称来标识不同的远程库：

git push <远程库名> master

敲一行命令告诉 Git 用 st 就表示 status：git config --global alias.st status，--global 参数是全局参数，也就是这些命令在这台电脑的所有 Git 仓库下都有用，加上 --global 是针对当前用户起作用的，如果不加则只针对当前的仓库起作用。

配置一个 git last，让其显示最后一次提交信息 git config --global alias.last 'log -1'，用 git last 就能显示最近一次的提交。

每个仓库的 Git 配置文件都放在 .git/config 文件中：cat .git/config

当前用户的 Git 配置文件放在用户主目录下的一个隐藏文件 .gitconfig 中：cat .gitconfig。

配置别名也可以直接修改这个文件，如果改错了，可以删掉文件重新通过命令配置。

搭建 Git 服务器作为私有仓库使用。

Git push —-force可以在没有pull的情况下直接“暴力”push。

总结

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

创建+切换分支：git checkout -b <name>

合并某分支到当前分支：git merge <name>

删除分支：git branch -d <name>


在两个分支上同时修改一个文件会发生冲突，当 Git 无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成，用 git log —graph 命令可以看到分支合并图。

git merge --no-ff -m"again and again" dev，用git log看看分支历史，合并后的历史有分支，能看出来曾经做过合并，而 fast forward 合并就看不出来曾经做过合并。

在实际开发中，按照几个基本原则进行分支管理：

• Master 分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活。
• 在 dev 分支上干活，也就是说，dev 分支是不稳定的，到某个时候，比如 1.0 版 本发布时，再把 dev
  分支合并到 master 上，在 master 分支发布 1.0 版本。
• 你和你的小伙伴们每个人都在 dev 分支上干活，每个人都有自己的分支，时不时地往 dev 分支上合并就可以了。

剩下的关于 Git 的学习，最有效的方法可能就是实践了，现在就开始建立你的 Github 账号吧。

---

不足之处，欢迎指正。