使用 Git 已经好几年了，却始终只是熟悉一些常用的操作。对于 Git Rebase 却很少用到，直到这一次，不得不用。 一、起因 上线构建的过程中扫了一眼代码变更，突然发现，commit 提交竟然多达 62 次。我们来看看都提交了什么东西： 这里我们先不说 git 提交规范，就单纯这么多次无用的 commit 就很让人不舒服。可能很多人觉得无所谓，无非是多了一些提交纪录。 然而，并非如此，你可能听过破窗效应，编程也是如此！ 二、导致问题 1.不利于代码 review 设想一下，你要做 code review ，结果一个很小的功能，提交了 60 多次，会不会有一些崩溃？                    「也可使用 reset  --soft  + commit 」完成合并提交 2.会造成分支污染 你的项目充满了无用的 commit 纪录，如果有一天线上出现了紧急问题，你需要回滚代码，却发现海量的 commit 需要一条条来看。 遵循项目规范才能提高团队协作效率，而不是随心所欲。 三、Rebase 场景一：如何合并多次提交纪录？ 基于上面所说问题，我们不难...

在开发过程中有时候可能在执行完git commit之后发现代码有问题，需要撤除提交，这时候我们可以使用以下git reset命令来实现 比较常见的git reset命令包括 mixed 重置HEAD和index，默认参数，保留工作区 soft 重置 HEAD，保留index区和工作区，让仓库恢复到执行git commit之前的状态 hard 重置HEAD,index和工作区

Git 代码规范 Git 每次提交代码，都是需要写 Commit message（提交说明），否则就不允许提交。 Commit message 的格式 (三部分)： Heaher ----- 必填          type ---必需          scope --- 可选          subject --- 必需 Body ---- 可省略 Footer ---- 可省略 Type说明 用于说明 commit  的类别，仅支持允许以下7个标识。 feat：新功能 (feature) fix: 修补bug docs：文档（documentation） style：格式（不影响代码运行的变动） refactor：重构 (既不是新增功能，也不是修改bug的代码变动) test：增加测试 chore：构建过程和辅助工具的变动注释 如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。 ...

如果在修改时发现修改错误，而要放弃本地修改时， 一， 未使用 git add 缓存代码时。 可以使用 git checkout -- filepathname (比如： git checkout -- readme.md  ，不要忘记中间的 “--” ，不写就成了检出分支了！！)。放弃所有的文件修改可以使用 git checkout .  命令。 此命令用来放弃掉所有还没有加入到缓存区（就是 git add 命令）的修改：内容修改与整个文件删除。但是此命令不会删除掉刚新建的文件。因为刚新建的文件还没已有加入到 git 的管理系统中。所以对于git是未知的。自己手动删除就好了。   二， 已经使用了  git add 缓存了代码。 可以使用  git reset HEAD filepathname （比如： git reset HEAD readme.md）来放弃指定文件的缓存，放弃所以的缓存可以使用 git reset HEAD . 命令。 此命令用来清除 git  对于文件修改的缓存。相当于撤销 git add 命令所在的工作。在使用本命令后，本地的修改并不会消失，...

经常会在GitHub上搜索代码、项目或查找相关主题，最简单常用的方法是在GitHub主页搜索框中直接输入相关信息进行查找，如下图所示，但是这样搜到的结果很多都不是自己希望的，这里总结下搜索技巧及常用操作说明： 1. GitHub的搜素支持各种不同的操作，详细见https://help.github.com/en/articles/about-searching-on-github ，常用操作如下：注意：在搜索前最好已登录，这样才能在所有公共仓库中搜索code。 (1). 基本搜索(Basic search)： A．查找stars数超过100的”cat”仓库：cat stars:>100 B．搜索用户名为fengbingchun的所有仓库：user:fengbingchun 搜索结果如下图所示，左上侧显示fengbingchun有多少个仓库(Repositories)、Issues数等信息，想查看特定信息可以进一步点击；左下侧显示仓库中包含哪些开发语言，如C++、C、Python等，也可点击对应的只查看指定语言的仓库；右上侧显示这些仓库按哪种方式进行排序，包括...

在编译git库拉下来的代码时，往往会产生一些中间文件，这些文件我们根本不需要，尤其是在生产环节做预编译，检查代码提交是否能编译通过这种case时，我们往往需要编译完成后不管正确与否，还原现场，以方便下次sync代码时不受上一次的编译影响。 # 删除 untracked files git clean -f   # 连 untracked 的目录也一起删掉 git clean -fd   # 连 gitignore 的untrack 文件/目录也一起删掉 （慎用，一般这个是用来删掉编译出来的 .o之类的文件用的） git clean -xfd   # 在用上述 git clean 前，强烈建议加上 -n 参数来先看看会删掉哪些文件，防止重要文件被误删 git clean -nxfd git clean -nf git clean -nfd

#安装源 yum install http://opensource.wandisco.com/centos/7/git/x86_64/wandisco-git-release-7-2.noarch.rpm #安装git yum install git #更新git yum update git

如何把最后一次commit撤销回Changes not staged和Untracked files区呢？ 有3种情况： （1）把最后的commit切回 Changes to be committed状态，使用命令 git reset --soft HEAD^ 注意：Windows系统需要在^符号后面两边加上引号，如： git reset --soft HEAD"^" （2）把最后的commit切回Changes not staged for commit状态，使用命令 git reset HEAD^ （3）把Changes to be committed状态切回Changes not staged for commit状态，使用命令 git reset HEAD <file>... # 单个文件 git reset HEAD -- . # 所有Changes to be committed的文件 最后一条命令在git命令行也有提示，不需要记住。 git reset 的HEAD和–hard git reset...

1.以需要替换的分支（master)下，创建orphan分支，命名为 new git checkout --orphan new 注： 如果不提交东西，这个分支实际上没有创建 2.提交 $ git add . $ git commit -m "init" 3.删除原来需要替换的分支（master） $ git branch -d master 4. 将新分支改名为原需替换的分支名（master） $ git branch -m new master 5. 将新分支强制覆盖远程的同名分支(master) $ git push --set-upstream origin master -f 到此已替换结束;多个分支，就重复以上 5 步。 其他协作者需要做的是 1. 切换到刚才替换的分支，执行拉取代码 $ git checkout master $ git pull 注： pull  过程相当于新拉取一个新项目，有点耗时。 2.至当前分支执行 （重置提交信息，与远程分支一致） $ git reset --hard origin...

git cherry-pick 321d76f