Git 对非当前分支进行fast-forward 合并
正常来说,进行fast-forward 合并「git pull
」都是针对当前分支的。但是,我相信你会遇到需要对非当前分支进行fast-forward 合并的情况。如果你已经知道stash
命令,那么你可能会先stash
;再切换到目标分支,然后git pull
,最后切换回你的工作分支。这样切来切去分支的操作,不管是频不频繁,我都是很反感的。最后还是常规操作「stackoverflow」找到的正确的方法「偷懒」
正常来说,进行fast-forward 合并「git pull
」都是针对当前分支的。但是,我相信你会遇到需要对非当前分支进行fast-forward 合并的情况。如果你已经知道stash
命令,那么你可能会先stash
;再切换到目标分支,然后git pull
,最后切换回你的工作分支。这样切来切去分支的操作,不管是频不频繁,我都是很反感的。最后还是常规操作「stackoverflow」找到的正确的方法「偷懒」
为什么要查哪个分支有特定commit 呢?以前的我是直接打开每一个分支的历史记录,人眼检查commit hash。然后,后来变懒了「分支多了,commit 比较久远」;当然,最终通过面向谷歌解决问题达成我偷懒的目的。
在实际开发的时候,有时候我们可能会遗漏了某些文件的修改。等到我们发现的时候,有可能已经过了有一段时间了「上一个commit 已经不是我们想要补充的」。
cheery-pick
不知道有没有什么故名思意之类的,反正以我的英语水平是看不出来>_<。它可以将指定commit 复制到当前所在的分支;一般情况下,这个命令没有什么用武之地。但如果你有多个分支,其中一个是生产发布用的,一个是开发用的,还有其他的分支;某个功能在开发分支上完成开发并通过测试了。由于某种原因「顺带修复了某个严重bug、或者很多用户请求尽快增加」,需要在下一个小版本更新而不是在下一个大版本「大版本计划在几个月甚至半年」。这时候,cheery-pick
就是你手中的咖哩棒「无往不利」。
简单交代一下:因为手贱,所以需要回滚到指定revision 。过程就不说了,反正一搜索;答案就出来了。
今天再次心血来潮「看看是谁改了某个地方」,想要看看svn 版本管理下的文件每一次变更。
今天心血来潮「看看自己有没有写错」,想要看看svn 版本管理下的文件历史版本。没有试过这种操作,所以google 之。
最近在写关于jQuery 源码的时候,不可避免的要引用jQuery 在GitHub 上对应的文件;有时候还需要精确的引用到某个文件的某几行代码。为此,特意找了一下如何去引用GitHub 的代码。