主要内容
git , github, gitlab 相关
更新历史
2017-08-18 增加 删除/回滚 多次远程提交
2020-04-28 git摘樱桃 cherry-pick
git 的后悔药
场景1:直接丢弃工作区的修改(还没有add)
git checkout -- file
场景2: 丢弃暂存区(已经add,未commit)
分两步,第一步用命令 git reset HEAD file
,就回到了场景1,第二步按场景1操作。
场景3:已经提交了不合适的修改到版本库(已经commit, 未push)
git reset --hard HEAD^ #还原到上个
git reset --hard commitId
场景4:已经推送到远程(已经push)
删除某一次远程提交
git revert commitId
git push origin master
删除/回滚 多次远程提交
git rebase -i "commit id"
在编辑框中删除相关commit,如pick 5b3ba7a test2,然后保存退出(如果遇到冲突需要先解决冲突)!git push origin master -f
这里需要强制推送, 如果是保护branch, 需要临时解除保护。
cherry-pick
将代码从一个分支转移到另一个分支,是多分支代码库的常见需求。
一种情况是,你需要另一个分支的所有代码变动,那么就采用合并git merge
。另一种情况是,你只需要部分代码变动(某几个提交),这时可以采用 Cherry pick
。
基本用法
指定提交commit
1 | git cherry-pick <commitHash> |
会将指定的提交commitHash,应用于当前分支。这会在当前分支产生一个新的提交,当然哈希值不一样。
比如,
代码仓库有
master
和develop
两个分支1
2
3a - b - c - d Master
\
e - f - g develop现在将提交f应用到master分支
1
2
3
4
5# 切换到 master 分支
$ git checkout master
# Cherry pick 操作
$ git cherry-pick f操作完成以后,代码库就变成
1
2
3a - b - c - d - f Master
\
e - f - g develop注意: Master 的 f 和 develop 的 f hash值不同
最近一次提交
git cherry-pick feature
将feature分支的最近一次提交,转移到当前分支。
多个提交
多个
git cherry-pick <HashA> <HashB>
将 A 和 B 两个提交应用到当前分支。这会在当前分支生成两个对应的新提交。连续
git cherry-pick A..B
转移从 A 到 B 的所有提交。它们必须按照正确的顺序放置:提交 A 必须早于提交 B,否则命令将失败,但不会报错。
注意,使用上面的命令,提交 A 将不会包含在 Cherry pick 中。如果要包含提交 A,可以使用下面的语法。git cherry-pick A^..B
配置项
1 | git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] [-S[<keyid>]] <commit>... |
-e,--edit
打开外部编辑器,编辑提交信息-n,--no-commit
只更新工作区和暂存区,不产生新的提交。-x
在提交信息的末尾追加一行(cherry picked from commit …),方便以后查到这个提交是如何产生的。-s,--signoff
在提交信息的末尾追加一行操作者的签名,表示是谁进行了这个操作。-m parent-number,--mainline parent-number
如果原始提交是一个合并节点,来自于两个分支的合并,那么 Cherry pick 默认将失败,因为它不知道应该采用哪个分支的代码变动。-m
配置项告诉 Git,应该采用哪个分支的变动。它的参数parent-number是一个从1开始的整数,代表原始提交的父分支编号。git cherry-pick -m 1 <commitHash>
Cherry pick 采用提交commitHash来自编号1的父分支的变动。
一般来说,1号父分支是接受变动的分支(the branch being merged into),2号父分支是作为变动来源的分支(the branch being merged from)。
后续命令
如果操作过程中发生代码冲突,Cherry pick 会停下来,让用户决定如何继续操作。
1 | # Cherry pick 过程继续执行 |