-
git配置 git config --gloabal --list
-
git pull = git fetch + git merge -b
-
移除本地工作区文件 git rm -r --cached xxx
-
由于其分布式特性 代码会存在三个地方 工作区--- git add ./git add -u --- 暂存区 --- commit -m --- 仓库 --- git push --- master
-
push了一个版本要修改: 先修改本地，然后 git commit -amend amend改良，修订之意 再push
-
git pull时报error："your local changes to the following files would be override by merge", git stash stach 是贮藏之意, git pull, git stash pop 解决冲突
-
不会有新的
-
多用 git status, git log, git log --oneline 本地提交历史
-
HEAD 指向当前分支(当前版本更准确) 最新commit git中的分支只是一个引用，删除分支并不会删除commit，没有合并到master的分支是不能删除的
HEAD
really just means "what is my repo currently pointing at".
master git创建一个仓库时的
默认分支，主分支，叫啥都行
origin 原始
仓库
（一般是远程仓库），git给你的主远程仓库起的
默认名字
-
-
关键词 面向修改 把修改推送给对方！
-
git
rebase把自己的代码给覆盖了？ git reflog 找到rebase之前的点，git reset就又回来了
-
branch相关的几个问题：
新建分支并指向上游分支 git branch new_branch remote_branch, 记住这不会切换分支，必须switch
不如使用 git checkout -b branch new_branch
git branch -u （注意使用这个命令时已经切换到相应的分支）
git push -u都可以设置上游分支
上游分支和是否远程分支没有关系
查看本地分支的上游分支: git branch -vv
-
git push origin HEAD:refs/for/xxx
是指
在origin远程仓库，将当前的版本(HEAD)提交到前面指定的仓库的某个分支refs/for/xxx
-
创建远程分支
切换到基分支，然后git branch new_branch（注意在此之后要checkout，要么就 git checkout -b new_branch）
最后 git push origin HEAD:remotes_branch_name
-
回退本地commit
git log grahp 查看找出远程commit_id
git reset commit_id，可以看到后来的变化，剔除变化，然后commit即可
git revert commit_id也能回退，不同的是新建一个提交
-
git
合并分支， 要将a合并到master，则先checkout到master，再git merge wanted_merged_branch,解决冲突后commit
-
近日又搞到两个命令： git switch 应该用switch来切换分支的，
如果没有IDE，怎么rollback
回退文件呢？git restore file 或者 git checkout -- file
目前在分支A上，想
单独拉下分支B上的文件 git chckout B -- file 正是我最近想要的，来比对使两个分支同步
问题又来了，这个里面的 -- （double dash）是干什么用的？ 用来
消除歧义的，比如checkout one 如果one是branch 则为 切换分支，如果one是一个目录则是rollback了，分不清了，所以只有一个--时则特指文件
SOF 其实不止Git， 这是POSIX标准，命令行中也用这个来转义
-
git merge 是对两个分支共同节点之后分离的节点合并起来，所以merge点会有两个parent，合并分支A后，如果在主分支上删除A的变动，再次合并A，A上的变动将不会合并进去，因为共同点已经没有分离了
回退merge应该使用revert而不是本地reset后再次提交，远程commit记录不会变化的
过程描述：分支A开发完成，误在分支A上拉了bugfix分支，将bugfix合并进master，发现问题（大量变动知道基分支错误了），回退master，删除（D文件）分支A变动，20天后再次merge分支A，并未合并进去
-
所有的commit都已经推到Girret评审后，切换分支git merge后，推到Gerrit提示没有变动发生，拒绝发起review，在merge时应该操作: git merge --no-ff, (--no-ff之意是no fast forward 不快进，会生成一个新的commit，
保证了主分支的干净，主分支更清晰)或者直接push到master（不建议） "after git merge, the push to Gerrit fails, indicating no new change" 我是通过修改changeId欺骗Gerrit，然而我后面再如此操作，普通merge后却能继续push生成个review，为啥呢？
-
拉错分支时如何修改？变基 这时候就是rebase的魅力了 或者cherry-pick 这个东西居然可以pick一段 git cherry-pick A B C git cherry-pick A..B (A,B]
阮一峰的博客
怎么知道自己基于哪个分支？
git log --first-parent
git log --graph --decorate --simplify-by-decoration
或者，呃，更大的
git show-branch | sed "s/].*//" | grep "\*" | grep -v "$(git rev-parse --abbrev-ref HEAD)" | head -n1 | sed "s/^.*\[//"
-
修改曾经的commit： git rebase -i HEAD~n 找到要修改的commit，编辑为edit， 修改代码， git commit --amend 最后 git rebase --continue
CSDN
-
特性分支落后了： 特性分支基于rel分支拉取，但是rel分支前进了，于是就可以 git rebase rel 变基，
与git文档一致 摘录网络评论：
本地开发分支拉取远程开发分支用rebase，开发分支合并主干分支的时候用rebase，最后主干分支合并开发分支用merge，最后推送各分支 （
merge和rebase的区别
）
-
gerrit push发起review时报错
squash commits first
, 它的意思是让你先合并提交， 原因是commit中有重复的changeId，git log 找出重复的changeId并修改即可；触发原因是先后cherry-pick了其他分支上对一个commit的两次修改：分支A commitA-->分支B cherry-pick commitA --> 分支A修改commitA --> 分支B cherry-pick commitA
gerrit文档
-
回到以前的状态 git log --oneline 查看要回到的commit 然后 git checkout commit_id 然后可以看代码， 要回去 git switch - 是不是像cd -
-
比较 现在比较时很依赖IDE，git diff branchA branchB 或者直接 git diff branchB 只对比文件名 加 --name-only
也可以比较两个commit git diff commit_id1 commit_id2
比较branch2 与 branch1、branch2的公共祖先之间的差别 git diff branch1 ... branch2
baeldung.com
-
去掉merge中的
commit记录 git rebase --soft commit-id ; git commit ; 为什么会产生这个需求呢？ 分支1上开发落后太多，n个月后需要合到分支2上，在分支2上merge 分支1，解决冲突后，达到了理想状态，但是这个代码push不上去，因为分支1上的历史提交里还会产生冲突，于是回头到分支1上rebase合并成一个提交，回到分支2上再merge，但是git log查看过去的提交历史还在；于是就有了这种需求，时间过于久远，分支1上具体的commit记录已经没有意义
https://stackoverflow.com/a/46921732
-
没有changeId G
errit的基于changeId的评审，在跨branch cherry-pick后，使用起来并不是很好，会形成不相关的链；
另一个是jenkin自动更新pom后没有changeId，导致无法发起review，说缺少changeId，这种情况的出现如下: n-new c-commit t-tag m-merge mm-merge to master
master ------------
feat1 n c t c t mm
feat2 n c t m mm
就在feat2的merge后发起review时，说feat1中的t即jenkins修改的commit没有changeId；所以
解决办法是在feat2上所有开发完成后，待feat1 merge到master后再merge feat2到master
，不急于merge合并feat1上的特性，因为feat2产生于feat1的原因是已经确定了feat1上线早于feat2
另外一个为了避免因为jenkins tag没有changeId的问题，尽量保持在master上进行构建，因为其他分支合并此特性的时候，tag没有changeId
-
特性分支合并的实践 问题: 最后的Mm还需要解决冲突吗？答曰不需要 Nr: 从rel new出来的 Mf: merge feature
rel = = + = Mm
feature Nr + =
merge Nr Mf
就是在合并到release分支前，以防"污染"release 分支，新建一个merge分支来进行merge，在merge分支解决冲突后，再将其merge到release 是可行的，已经过测试， merge的本意就是从最近的分叉开始进行合并
找公共祖先: git merge-base –all commit_id1(Yours/Theirs) commit_id2(Yours/Theirs) merge后会生成一个commit哦，结合理解下
-
误stash pop 有时候在一个分支上的修改，还没写完所以stash，但是误stash pop到了另一个分支，代码是不是丢了呢？ git --hard reset 到之前的操作即可，接着stash pop git stash show是查看stash状态的； 这个说法是错误的，只有在pop时出现冲突，pop失败仍然保留在stash list；所以尽量使用git stash apply stash_hash
正确的方法是： 终端会显示刚才pop的stash_hash； 或者使用 git fsck --no-reflog | awk '/dangling commit/ {print $3}' or git fsck --no-reflog | select-string 'dangling commit' | foreach { $_.ToString().Split(" ")[2] }
参见SF 其中的dangling并不是中文 而是 悬吊着
-
重做merge冲突解决
git checkout -m -- file.txt
-
rebase onto A B分支互相缠绕，现在要把B分支中的一段取出来，放到分支C上，因为在要被取的提交中，A、B分支都曾更改多同一文件，cherry-pick时有大量冲突需要解决，怎么办？ 先switch到分支B git rebase commt-start commit-end --onto C 就行
cnblogs.
-
git交换一个普通commit和merge的顺序，如果采用普通的rebase -i，则要重做很多冲突解决，所以就
另起分支进行cherry-pick这个merge，git cherry-pick -m parent_id，parent_id怎么获取？git show --pretty=raw
SF1
SF2