一、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 status
可以设置为
通过配置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。
若有收获，就点个赞吧
0 人点赞
