- 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 --pull rebase 比git pull看起来更清晰（因为成了一条线） https://www.jianshu.com/p/dc367c8dca8e rebase rebase就是重新确定base，不会有新的
- 多用 git status, git log, git log --oneline 本地提交历史
- HEAD orgin master是什么意思？ What are the git concepts of HEAD, master, origin? - Stack Overflow https://www.jianshu.com/p/4219b6f62ce3HEAD 指向当前分支(当前版本更准确) 最新commit git中的分支只是一个引用，删除分支并不会删除commit，没有合并到master的分支是不能删除的 HEAD really just means "what is my repo currently pointing at".master git创建一个仓库时的 默认分支，主分支，叫啥都行origin 原始 仓库（一般是远程仓库），git给你的主远程仓库起的 默认名字
- git 为什么要设置暂存区 git为什么要设置暂存区？ - 知乎 git add .后，而后commit前后悔了， 此时不想push一些文件到远程，git rm --cached暂存区就可以实现部分提交，比如你正在修复一个bug和开发特性，可以先提交bug修复那部分 Why would I want stage before committing in Git? - Stack Overflow
- 关键词 面向修改 把修改推送给对方！
- git rebase把自己的代码给覆盖了？ git reflog 找到rebase之前的点，git reset就又回来了
- branch相关的几个问题：新建分支并指向上游分支 git branch new_branch remote_branch, 记住这不会切换分支，必须switch不如使用 git checkout -b branch new_branchgit branch -u （注意使用这个命令时已经切换到相应的分支）git push -u都可以设置上游分支上游分支和是否远程分支没有关系建立上下游关系后，直接在当前分支git pull就默认pull到上游分支 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
- 回退本地commitgit log grahp 查看找出远程commit_idgit 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, 或者直接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，最后推送各分支
- 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记录已经没有意义 git remove merge commit from history - Stack Overflow
没有changeId Gerrit的基于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
版权声明：本文为KHZ_222原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接和本声明。