好的commit应该长啥样 https://github.com/torvalds/linux/pull/17#issuecomment-5654674 cherry pick
Git - git-cherry-pick Documentation https://git-scm.com/docs/git-cherry-pick
NAME
git-cherry-pick - Apply the changes introduced by some existing commits
SYNOPSIS
git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff] [-S[<keyid>]] <commit>… git cherry-pick (--continue | --skip | --abort | --quit)
DESCRIPTION
Given one or more existing commits, apply the change each one introduces, recording a new commit for each. This requires your working tree to be clean (no modifications from the HEAD commit).
When it is not obvious how to apply a change, the following happens:
-
The current branch and
HEAD
pointer stay at the last commit successfully made. -
The
CHERRY_PICK_HEAD
ref is set to point at the commit that introduced the change that is difficult to apply. -
Paths in which the change applied cleanly are updated both in the index file and in your working tree.
-
For conflicting paths, the index file records up to three versions, as described in the "TRUE MERGE" section of git-merge[1]. The working tree files will include a description of the conflict bracketed by the usual conflict markers
<<<<<<<
and>>>>>>>
. -
No other modifications are made.
See git-merge[1] for some hints on resolving such conflicts.
Git cherry-pick 这个命令你会经常用到! - 知乎 https://zhuanlan.zhihu.com/p/90816644
Merge,Rebase,Cherry-Pick 了解一下 - 知乎 https://zhuanlan.zhihu.com/p/156726632
Merge 会将两个分支合并到一起,并生成一个新的 commit 记录。新生成的 commit 节点会有两个父节点。一般在开发某个新功能时,会选择新的分支,之后在合并回主线。
rebase 也能合并分支,它会取出一系列 commit 记录,复制它们。然后在目标分支逐个放下去。rebase 的好处是能保持线性的提交历史,从而使历史更加清晰。
在 bugFix 分支上,使用 git rebase master
分支,会将 bugFix 分支上的 commit 记录复制到 master 分支,并且保证了提交历史是线性的。
rebase 除了可以在合并时使用,还可用于整理 commit 记录。
使用 git rebase -i
命令打开交互式的 rebase UI. 在打开的界面中会显示每个 commit 的哈希值以及提交说明,可以在其中调整 commit 的顺序、删除不想要的提交、以及合并提交。
cherry-pick 而是将一些 commit 复制到当前的分支的 HEAD 上,和 rebase 相比,更加灵活,可以随意的选择 commit 进行复制。
通过 git cherry-pick c3 c4 c7
将其他分支上的 3 个 commit 复制到当前的 master.
git cherry-pick
可以理解为”挑拣”提交,它会获取某一个分支的单笔提交,并作为一个新的提交引入到你当前分支上。当我们需要在本地合入其他分支的提交时,如果我们不想对整个分支进行合并,而是只想将某一次提交合入到本地当前分支上,那么就要使用git cherry-pick
了。
Git commits历史是如何做到如此清爽的? - 知乎 https://www.zhihu.com/question/61283395/answer/186122300
多用 rebase
---
我真是服了贵乎了,楼下居然有人能从 commit 风格看出我爱慕虚荣,哈哈哈哈,只能说这葡萄是很甜了
我 rebase 纯粹是因为我不喜欢 git log --graph 的时候一堆 branch 扰乱视线。另外,难道你不知道 rebase 不一定要 squash 的?
Vue作者已经放出了权威答案,我也在这补充一下自己平时的git workflow。在开发一个feature或者修个bug的时候,一般都会在最终要merge进的分支上开个新的分支,所有的工作都commit到这个新的分支上。feature写完或者bug修完,在要merge之前,rebase新分支到最后要merge的分支上,这相当于把你在新分支上的所有新commit依次cherry pick到要merge的分支的最新commit后面,这样后续的merge就一定会是一个非常爽的fast forward。而且在rebase的同时可以进行squash,把逻辑上相似的commit都塞到一个commit里面,然后给他一个描述性比较强的commit message。这套操作下来之后commit历史会非常清晰一目了然,看某些同事的项目的commit历史里面各种save, save work, fix bug, fix bug again的确是一种煎熬,好的commit应该反映出一个项目是怎么一步步开发下来的,是软件开发的航海日志,黑匣子,任何码农都应该建立良好的commit习惯。
Linus曾经在Linux的某个pr下面讨论了好的commit应该长啥样,非常有启发: Add support for AR5BBU22 [0489:e03c] by WNeZRoS · Pull Request #17 · torvalds/linux
Add support for AR5BBU22 [0489:e03c] by ReeJK · Pull Request #17 · torvalds/linux https://github.com/torvalds/linux/pull/17#issuecomment-5654674
你们仍未掌握那天所学的 git 知识 https://yonghaowu.github.io/2017/06/18/TheGitYouShouldKnow/
你们仍未掌握那天所学的 git 知识
工作中必备 git 技能详解
绝大多数人对于 git的认识只停留在git status
, git add
, git push
, git pull
, 好一点会知道git merge
, 那就是全部了。
不信?
试试你能回答出以下问题不:
git push origin master
命令中,origin 代表的是什么,整个命令是什么意思,origin 可以修改不git fetch origin; git rebase origin master
这些命令知道吗?跟 merge 有什么区别?- git如何合并两个补丁,对第三个补丁进行修改?(这个很重要,因为你不会才导致 git commit 的信息没有意义,commit 不够小和多)
又或者,你试过合并commit 吗?commit message 写的不好时如何修改?如何改变 commit 的顺序?
如果以上有不清楚的话,那么我希望以下的文章对你有帮助。
你所不知道的 github 初始化
初始创建一个 github 仓库时,github 会给一些命令你去创建 git本地项目,git init
就不用说了,git remote add origin git@github.com:YongHaoWu/test.git
你知道这里的 origin 是什么吗?
是的,就仅仅是一个名字,对git@github.com:YongHaoWu/test.git
这个 ssh 地址的命名,你可以把 origin
命名为 gakki
—— ` git remote add gakki git@github.com:YongHaoWu/test.git, 以后就可以用
git push gakki master`了。
另外,你还可以 add
好几个名字,比如:你在 github 跟coding 同样都有仓库放代码的情况。
git push -u origin master
, 这里就是把 master(默认 git 分支)推送到 origin, -u
也就是--set-upstream
, 代表的是更新默认推送的地方,这里就是默认以后git pull
和git push
时,都是推送和拉自 origin 。
令 commit 更漂亮
对于 git 工作流,我认为commit 数要多而有意义,branch 也要多而有意义——也就是,一个小功能就要开一个分支,一个分支里要有一些有意义的 commit。 好处就是冲突会很少,review 代码速度加快,commit 都是有意义的,而且利于回退。
要做到这些,离不开掌握git rebase
永远使用 rebase
git rebase
Reapply commits from one branch on top of another branch.
Commonly used to "move" an entire branch to another base, creating copies of the commits in the new location.
相信你可以理解以上的英文:把 A 分支rebase 到 B 分支,也就是把 A 的 commit 与 B 的合并,并且保留 B 独特的 commit。
还是很抽象,对吧?
看一个例子:git pull gakki feat-add-listener
这里就是把 gakki
仓库拉到 feat-add-listerner
分支。实际上,所做的东西等价于:
git fetch gakki //把 gakki 仓库的东西都拉下来本地
git merge gakki/master feat-add-lister //把 gakki 的 master 分支 merge 到 feat-add-lister
因为 pull 的时候, 当出现冲突而你解决掉后,会有多余的merge
信息(commit message),所以我是推荐在自己的分支开发时,使用git fetch gakki
以及 git rebase gakki/master feat-add-lister
(不会出现多余信息,处理冲突更加自由)
合并你的 commits
Author: YongHao Hu <hyh@vincross.com>
Date: Fri Dec 23 17:55:49 2016 +0800
install skill: Fix skill pkg relative path.
commit 37f37e46a2570c0989a46f39169bba510ebdabd8
Author: YongHao Hu <hyh@vincross.com>
Date: Fri Dec 23 10:51:09 2016 +0800
mind: Add comments for understanding.
commit 4eb9b9743d2bdc301a0e97f73d652f67adc82b32
Author: YongHao Hu <hyh@vincross.com>
Date: Thu Dec 22 15:00:02 2016 +0800
skill-third-party: Add default include library.
假设你又以上三个 commit,如何合并,修改呢? git rebase -i HEAD~4
对前四个补丁就行修改,就会进入以下界面:
pick 0194373 skill-third-party: Change PKG_CONFIG_PATH and LD_LIBRARY_PATH.
pick 4eb9b97 skill-third-party: Add default include library.
pick 37f37e4 mind: Add comments for understanding.
pick 84c413a install skill: Fix skill pkg relative path.
# Rebase 986e234..84c413a onto 986e234 (4 commands)
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
有以下常用操作:
- 默认pick, 不做更改
- reword:改 commit message
- squash:当前补丁跟上一个补丁合并
- fixup: 跟 squash 作用一样,但是会丢弃当前 commit 信息,使用上一个的;squash 则是可以让你重新写
需要修改时,把上面四个补丁最前面的 pick 改成对应操作(如 reword,fixup),然后保存退出即可。
不用担心的回退
回退大家应该都知道git reset --hard commitID
, 把整个 git 回退到这个 commitID 里;
其实除了--hard
, 还有 soft
.
hard
是把改动全部都丢弃,而soft
则柔软一些,仅仅是把所做的 commit 丢掉,而改动都保留在本地——通常用来修改,再重新 commit 一遍。
做了胡乱的更改,导致 git log
都不正常,找不回那个 commit 了怎么办?
不用担心, 还有 git reflog
— Reference logs, or "reflogs", record when the tips of branches and other references were updated in the local repository.
用它可以看到你对当前项目所做过的所有 git 操作,所有 git 操作的 id 号——意味着你可以回退到任意的时刻。
所以,只要你没有把改动没有做 commit 就丢失,又或者用git push -f
把 github 仓库覆盖了,你就可以恢复任意时刻的东西。
git stash 暂存更改
时刻要注意,当前修改没有 commit 的时候,不能 checkout 切换分支。
此时不想 commit,便需要 git stash
暂存更改;顾名思义,stash 使用 stack(栈)实现,所以可以 git stash
存多次,然后切换分支后, git stash pop
撤出来
比 grep 更好用的 git grep
相比于 grep -R keyword ./
, 我是更喜欢用 git grep keyword
, 差不多是一样的,不过git grep
只是会找当前的 目录中git 有 track(跟踪)的文件【也就是变动时,git status 会检测到变化的文件】
超级进阶:分割commit
commit 03bb9a14f5ea00d51d2edc14587b37b1ab9ccf5d
Author: YongHao Hu christopherwuy@gmail.com
Date: Fri Jul 10 17:23:02 2015 +0800
msvcp110: Add tr2_sys__Unlink implementation and test.
commit 24137cd93c783ced61ca152cb4384287e6859ba4
Author: YongHao Hu christopherwuy@gmail.com
Date: Tue Jul 7 11:04:25 2015 +0800
msvcp110: Add tr2_sys__Symlink implementation and test.
commit 51702048d9ecd1dc3887a63c057761a8547ce5f6
Author: YongHao Hu christopherwuy@gmail.com
Date: Thu Jul 2 23:23:51 2015 +0800
msvcp110: Add tr2_sys__Link implementation and test.
假设我们想要分割 msvcp110: Add tr2_sys__Unlink implementation and test. 这个 commit,可以直接使用 git rebase -i HEAD~7(数字随意,反正在 Unlink 这个 commit 前就可以了),选择 Unlink 这个 commit, 改成 edit。 一般情况下,就是这样修改 commit 的,修改后再 git rebase –continue.
但是,我们需要的是分割补丁: 选择 git rebase HEAD^, 撤销这次 commit,再把想改动的文件 git add, 再 git commit, 这样就可以分割很多补丁。
最后,git rebase –continue 就可以了。
Git - git-cherry-pick Documentation https://git-scm.com/docs/git-cherry-pick/en
【对错误commit-message的撤销】
git commit -a -m 'OK'
git commit -a -m "M 1、咨询页富文本-html标签;";git push origin master:master
modify a.file
git commit -a -m 'OK' 错误操作
git commit -a -m "M 1、咨询页富文本-html标签;";git push origin master:master 【查出该次的commitId 】
git log 查到commitId,【4b8b4e108943c0c12d31f8b0cc0b6a5eed49c0d7】
git commit -a -m 'OK'
git commit -a -m "M 1、云新闻地名、业务名数据迁出到数据集文件,便于集中管理和后续维护;";git push origin master:master
$ git reset 4b8b4e108943c0c12d31f8b0cc0b6a5eed49c0d7
Unstaged changes after reset:
M README.md
M src/api/teamDataset.js
M src/pages/cloundNews.vue
M src/pages/newsWebView.vue
git commit -a -m '3NewFile'