git小技巧

一、git commit提交之后，发现有错误怎么办？

当commit之后发现代码有错，简单直接的方法就是进行修改代码，然后第二次commit。

这样git log可以看到两次commit的信息

其他思路

如果你commit了之后还没有推到远程仓库，commit信息还在本地，此时可以根据git log的hashid来重置commit版本信息。

git reset

git reset –mixed
复制代码

此为默认方式，不带任何参数的git reset，即时这种方式，它回退到某个版本，只保留源码，回退commit和index信息

git reset –soft
复制代码

回退到某个版本，只回退了commit的信息，不会恢复到index file一级。如果还要提交，直接commit即可

git reset –hard
复制代码

彻底回退到某个版本，本地的源码也会变为上一个版本的内容

修改备注信息

git commit -amend
复制代码

---

二、怎么在项目开始/项目中正确的添加忽略文件或目录？

忽略文件

git rm与git rm --cache的区别

当我们需要删除暂存区或分支上的文件, 同时工作区也不需要这个文件了, 可以使用

git rm file_path
git commit -m 'delete somefile'
git push
复制代码

当我们需要删除暂存区或分支上的文件, 但本地又需要使用, 只是不希望这个文件被版本控制, 可以使用

git rm --cached file_path
git commit -m 'delete remote somefile'
git push
复制代码

忽略一个已经被跟踪的目录（再也不管它了）：

git rm -r --cached dir
echo dir/ >> .gitignore
git add .gitignore
git commit -am 'ignore dir forever'
复制代码

三、怎么给git命令创建快捷方式？

git alias
复制代码

第一种方法

通过配置git本身：

git config --global alias.s status
复制代码

从此，git s就是git status

第二种方法

vim ~/.gitconfig
复制代码

第三种方法： 配置系统的别名

vi ~/zssrc
复制代码

四、git stach是什么？

git stash 可用来暂存当前正在进行的工作， 比如想pull 最新代码， 又不想加新commit， 或者另外一种情况，为了fix 一个紧急的bug, 先stash, 使返回到自己上一个commit, 改完bug之后再stash pop, 继续原来的工作。

基础命令

$git stash
$do some work
$git stash pop
复制代码

进阶

   git stash save "work in progress for foo feature"
复制代码

当你多次使用’git stash’命令后，你的栈里将充满了未提交的代码，这时候你会对将哪个版本应用回来有些困惑，

’git stash list’ 命令可以将当前的Git栈信息打印出来，你只需要将找到对应的版本号，例如使用’git stash apply stash@{1}’就可以将你指定版本号为stash@{1}的工作取出来，当你将所有的栈都应用回来的时候，可以使用’git stash clear’来将栈清空。

git stash          # save uncommitted changes
# pull, edit, etc.
git stash list     # list stashed changes in this git
git show stash@{0} # see the last stash 
git stash pop      # apply last stash and remove it from the list

git stash --help   # for more info
复制代码

五、git rebase是什么？

rebase 的概念/作用其实很简单——就是「变基」。具体来说，就是改变一条分支的「基点」，使原分支从指定的地方（commit）重新长出来。并且，由于是一条新分支，你可以随意修改其中的 commits，也就是——重写分支历史。

而 rebase 的主要目的即删繁就简。

下面讲下关键步骤：

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]    [<upstream> [<branch>]]
git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]    --root [<branch>]
git rebase --continue | --skip | --abort | --edit-todo
复制代码

所有 rebase 的操作对象都是 commit。（你可以 rebase 一个分支 git rebase -i branchX，但实际上还是作用于该分支最新的 commit。）

以这个 commit 为「新基点」发起 rebase 后，会打印出一篇 commit 历史让你修改。

其中最常用的修改就是把 commit 前的 pick 改为 s (squash, /skwɔʃ/, 意为挤压)，作用为保留该 commit 作出的修改，但删去该节点，只给它一个留名的机会。(用专业的话讲就是——不保留待合并分支上的历史信息，也不提交、不移动HEAD。）多个以 s 为前缀的 commit 最终会整合成一个 commit，各个 commit 的描述部分也被整合到一起。

而最终极的修改就是直接删去 commit(s) ——篡改历史。这也就意味着，对应的改动也一并灰飞烟灭。（所以为什么说 rebase 是个危险的操作，就是因为篡改了历史！想想如果别人基于你国正史 fork 了一条分支，而你日后竟变基了会发生什么吧！）

改完之后 :x（Vim下的保存退出命令），Git 就去检测冲突了，此时类似于合并。 合并将按你留下的 commit(s) 重演历史，你可以修改每一次 commit 的具体代码。而如果你不是为了修改，只是为了简化树……我的办法是只留下一条 commit，用最新工程完全覆盖来解决冲突。（不知有没有更好的方法）

冲突解决完后 git rebase --continue，你就可以正式「书写」历史啦——撰写新的 commit 描述。这时那真是，想怎么写就怎么写~

这般本地 rebase 完成后，记得 git push -f，-f 用于强制将新历史推送至远程仓库。 至此，rebase 就彻底结束了。

看看你新造的树吧，是不是特简洁，特优美？（如果不是……你 rebase 干嘛……）

当一个系统的专有名词（黑话）足够多，就创造了文化。

在贡献开源代码时，git rebase可以直接把log同步过来，而不会有 git merge 的log。

怎么打标签，打标签有啥用？

打标签

同大多数 VCS 一样，Git 也可以对某一时间点上的版本打上标签。人们在发布某个软件版本（比如 v1.0 等等）的时候，经常这么做。本节我们一起来学习如何列出所有可用的标签，如何新建标签，以及各种不同类型标签之间的差别。 列出已有的标签

列出现有标签的命令非常简单，直接运行 git tag 即可：

git tag
v0.1
v1.3
复制代码

显示的标签按字母顺序排列，所以标签的先后并不表示重要程度的轻重。

我们可以用特定的搜索模式列出符合条件的标签。在 Git 自身项目仓库中，有着超过 240 个标签，如果你只对 1.4.2 系列的版本感兴趣，可以运行下面的命令：

git tag -l 'v1.4.2.*'
v1.4.2.1
v1.4.2.2
v1.4.2.3
v1.4.2.4
复制代码

新建标签

Git 使用的标签有两种类型：轻量级的（lightweight）和含附注的（annotated）。轻量级标签就像是个不会变化的分支，实际上它就是个指向特定提交对象的引用。而含附注标签，实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，电子邮件地址和日期，以及标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证。一般我们都建议使用含附注型的标签，以便保留相关信息；当然，如果只是临时性加注标签，或者不需要旁注额外信息，用轻量级标签也没问题。 含附注的标签

创建一个含附注类型的标签非常简单，用 -a （译注：取 annotated 的首字母）指定标签名字即可：

git tag -a v1.4 -m 'my version 1.4'
git tag
v0.1
v1.3
v1.4
复制代码

而 -m 选项则指定了对应的标签说明，Git 会将此说明一同保存在标签对象中。如果没有给出该选项，Git 会启动文本编辑软件供你输入标签说明。

可以使用 git show 命令查看相应标签的版本信息，并连同显示打标签时的提交对象。

git show push_v1.2
tag push_v1.2
Tagger: machuang <780@qq.com>
Date:   Sun Sep 10 12:06:50 2017 +0800

version 1.2 project coding end at 2017-8-23.
This tag create at 2017-9-10
s

commit f1759f45b598611231d9e768
Merge: f8f4 saf9
Author: XScarletAngel <7369@qq.com>
Date:   Wed Aug 23 18:30:27 2017 +0800

    Merge branch 'branch1.2' of git.du.com:admin/admin into branch1.2

    * 'branch1.2' of git.du.com:admin/admin:
      Test
复制代码

我们可以看到在提交对象信息上面，列出了此标签的提交者和提交时间，以及相应的标签说明。

根据commitid打标签

git tag -a <tag名> <commit对应的hash码>
复制代码

tag推送到远程仓库

默认情况下，git push并不会把tag标签传送到远端服务器上，只有通过显式命令才能分享标签到远端仓库。 1.push单个tag，命令格式为：

git push origin [tagname]
复制代码

例如：

git push origin v1.0 #将本地v1.0的tag推送到远端服务器
复制代码

2.push所有tag，命令格式为：

git push [origin] --tags
复制代码

例如：

git push --tags
复制代码

或

git push origin --tags
复制代码

以上命令经检验通过，如果不起作用，请在Git控制台上确认你的账号是否有权限推送Tag。