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 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。