re-base

在使用Git作为项目版本控制工具时，经常会多分支开发。比如下图， 我们一般会有两个分支，dev分支，作为平时开发分支；master分支，作为上线分支。上线前会使用merge或者rebase将开发分支合并至主干分支，而后编译打包部署至回归测试环境或者生产环境。 这在一般情况下是正常的。但是，想象一下，在大型项目中，经常是几十人在同时开发，同时进行的项目需求会有十几个。按照之前所述，每个人都会基于开发分支，检出自己的需求分支，开发完成后，再将需求分支合并至开发分支，而后再合并至主干分支。正常合并时，需求分支上有多个提交，合并至其他分支时也会有相应数量的提交。时间长了以后，分支上会有非常非常多的提交记录。但是，我们在进行开发时，可能会有一些无用的提交，比如，我可能是为了打个日志、暂存一下修改的内容等等。这是就会添加一些无用的提交。 为了解决这种情况， Git在merge命令，给出了--squash选项 ，这个命令的作用是：进行分支合并时，使用单个提交来替代合并。直白点，合并分支后， 多个提交记录合并为单个提交记录 。这样提交数量就少了很多，分支上也干净了许多，一个提交就代表了你做的这个需求。 示例如下： branch1从master检出，从1处开始，有4个提交记录数，合并至master时未加--squash选项，master有同样的提交记录数。 branch2从master检出

一、Git 基础图解 转自：http://www.cnblogs.com/yaozhongxiao/p/3811130.html Git 图解剖析 　　git中文件内容并没有真正存储在索引( .git/index )或者提交对象中，而是以blob的形式分别存储在数据库中( .git/objects )，并用SHA-1值来校验。 索引文件用识别码列出相关的blob文件以及别的数据。对于提交来说，以树( tree )的形式存储，同样用对于的哈希值识别。树对应着工作目录中的文件夹，树中包含的 树或者blob对象对应着相应的子目录和文件。每次提交都存储下它的上一级树的识别码。 　　如果用detached HEAD提交，那么最后一次提交会被the reflog for HEAD引用。但是过一段时间就失效，最终被回收，与 git commit --amend 或者 git rebase 很像。 　　git 模型可以抽象为 远程仓库——remote， 本地三级仓库: level1——working directory level2——stage(index) level3——repository(History) git 各个命令可以理解为在各个仓库间转移数据，各个命令对应对每个仓库输入输出。 　　便于记忆可以简单分为 低level输入和 高level输入，

merge 与 rebase 的区别 merge 现在假设我们有一个主分支 master 及一个开发分支 deve，仓库历史就像这样： 初始仓库历史 现在如果在 master 分支上 git merge deve ：Git 会自动根据两个分支的共同祖先即 e381a81 这个 commit 和两个分支的最新提交即 8ab7cff 和 696398a 进行一个三方合并，然后将 合并中修改的内容生成一个新的 commit ，即下图的 78941cb merge 合并图 rebase rebase 是什么情况呢？还是一个初始的仓库历史图： rebase初始仓库历史 如果是在 master 分支上 git rebase deve ：Git 会从两个分支的共同祖先 3311ba0 开始提取 master 分支（当前所在分支）上的修改，即 85841be 、 a016f64 与 e53ec51 ，再将 master 分支指向 deve 的最新提交（目标分支）即 35b6708 处，然后将刚刚提取的修改依次应用到这个最新提交后面。操作会舍弃 master 分支上提取的 commit，同时 不会像 merge 一样生成一个合并修改内容的 commit，相当于把 master 分支（当前所在分支）上的修改在 deve 分支（目标分支）上原样复制了一遍 ,操作完成后的版本历史就像这样： rebase

作者：枕边书 博客园： cnblogs.com/zhenbianshu/p/12018714.html 前言 从接触编程就开始使用 Git 进行代码管理，先是自己玩 Github，又在工作中使用 Gitlab，虽然使用时间挺长，可是也只进行一些常用操作，如推拉代码、提交、合并等，更复杂的操作没有使用过，看过的教程也逐渐淡忘了，有些对不起 Linus 大神。 出来混总是要还的，前些天就遇到了 Git 里一种十分糟心的场景，并为之前没有深入理解 Git 命令付出了一下午时间的代价。 先介绍一下这种场景，我们一个项目从 N 版本升到 A 版本时引入了另一项目的 jar 包，又陆续发布了 B、C 版本 但在 C 版本后忽然发现了 A 版本引入的 jar 包有极大的性能问题，B、C 版本都是基于 A 版本发布的，要修复 jar 包性能问题，等 jar 包再发版还得几天，可此时线上又有紧急的 Bug 要修，于是就陷入了进退两难的境地。 最后决定先将代码回退到 A 版本之前，再基于旧版本修复 Bug，也就开始了五个小时的受苦之路。 基础试探 revert 首先肯定的是 revert， git revert commit_id 能产生一个 与 commit_id 完全相反的提交，即 commit_id 里是添加， revert 提交里就是删除。 但是使用 git log 查看了提交记录后

上传文件到码云 如果有仓库管理员的用户密码，在网页上就有上传文件的按钮，如果不是管理员或者超过上传文件个数限制（码云限制一个小时内不超过20个），就用到git工具了， 第一步创建仓库 在本地文件夹拉去仓库的数据， 在想要拉取文件的位置，就是文件夹里面，点击鼠标右键，选择git bash here， 3. 然后在窗口输入 git init 这时候文件夹会多出一个.git文件夹，看不到文件夹的，点击鼠标右键选择“显示不显示隐藏的文件”就可以看到这个文件夹了 4. 输入git remote add origin + 加上码云仓库的路径, 再 输入 git pull origin master 命令，将码云上的仓库pull到本地文件夹 码云仓库的路径是这个 下图是已经将码云上的仓库pull到本地文件夹 5. 将自己想要上传的代码或文件放到刚才拉下来的仓库里，之后就可以推上去， 使用git add . （. 表示所有的）或者 git add + 文件名 将文件保存到缓存区 使用git commit -m '新添加的文件内容描述' 使用git push origin master ，将本地仓库推送到远程仓库 上图是成功的结果，如果不成功，会报一个错 failed to push some refs to git 这个错就是本地文件和仓库有冲突， 可以通过如下命令进行代码合并 git pull

上传文件到码云 如果有仓库管理员的用户密码，在网页上就有上传文件的按钮，如果不是管理员或者超过上传文件个数限制（码云限制一个小时内不超过20个），就用到git工具了， 第一步创建仓库 在本地文件夹拉去仓库的数据， 在想要拉取文件的位置，就是文件夹里面，点击鼠标右键，选择git bash here， 3. 然后在窗口输入 git init 这时候文件夹会多出一个.git文件夹，看不到文件夹的，点击鼠标右键选择“显示不显示隐藏的文件”就可以看到这个文件夹了 4. 输入git remote add origin + 加上码云仓库的路径, 再 输入 git pull origin master 命令，将码云上的仓库pull到本地文件夹 码云仓库的路径是这个 下图是已经将码云上的仓库pull到本地文件夹 5. 将自己想要上传的代码或文件放到刚才拉下来的仓库里，之后就可以推上去， 使用git add . （. 表示所有的）或者 git add + 文件名 将文件保存到缓存区 使用git commit -m '新添加的文件内容描述' 使用git push origin master ，将本地仓库推送到远程仓库 上图是成功的结果，如果不成功，会报一个错 failed to push some refs to git 这个错就是本地文件和仓库有冲突， 可以通过如下命令进行代码合并 git pull

中心化的工作流 优势 首先它让每个开发者都有自己的本地的完整项目副本。隔离的环境使得每个开发都的工作独立于项目的其它修改 —— 他们可以在自己的本地仓库中添加提交，完全无视上游的开发，直到需要的时候。 其次，它让你接触到了 Git 分支和合并模型。Git 分支被设计为故障安全的机制，用来在仓库之间整合代码和共享更改。 如何工作 中心化的工作将中央仓库作为项目中所有修改的唯一入口。默认的开发分支叫做 master，所有的更改都被提交到这个分支。这种工作流不需要 master 之外的其它分支。 开发者将中央仓库克隆到本地后开始工作。在他们的本地项目副本中，他们可以像 SVN 一样修改文件和提交更改；不过这些新的提交被保存在本地 —— 它们和中央仓库完全隔离。这使得开发者可以将和上游的同步推迟到他们方便的时候。 为了向官方项目发布修改，开发者将他们本地 master 分支“推送”到中央仓库。这一步等同于 svn commit，除了 Git 添加的是所有不在中央 master 分支上的提交。 管理冲突 中央仓库代码官方项目，因此它的提交历史应该被视为不可更改的。如果开发者的本地提交和中央仓库分叉了，Git 会拒绝将它们的修改推送上去，因为这会覆盖官方提交。 在开发在提交功能之前，需要 fetch 更新中央提交，在它们之上 rebase 自己的更改。 如果本地修改和上游提交的冲突时，Git

理解rebase的过程原理 rebase 是另一种可以用来合并分支的机制，有些人翻译成“变基操作”，它和 merge 合并分支的原理完全不同，对于merge来说除了fast-forward合并，其他合并方式都会生成一次新的提交对象，假如目前的项目状态是： 　　　　　E---F---G　　feature#1 　　　　　/ A---B----C---D　　　　　master(HEAD) 如果现在执行 git merge feature#1 ，git会找到提交对象G和D的共同基点C，然后做三方比较合并，合并之后产生一个新的提交对象H，分支的演变如下： 　　　　　E---F---G　　feature#1 　　　　　/　　　　\ A---B----C---D-----H　　master 但是如果我们采用 git rebase feature#1 则情况完全不同，git也会产生合并，但实际上是git先把master倒回（rewind）到C的提交点，然后把feature#1分支上的所有提交按顺序在master上重新执行一遍，然后把master上的在C之后的提交D进行一次fast-forward合并， 结果项目的分支情况就是下面这样： 　　　　　E---F---G　　　　　　feature#1 　　　　　/ A---B----C---E'---F'---G'---D　　master

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 我有以下存储库布局： 主分支（生产） 积分 工作中 我想要实现的是从工作分支中挑选一系列提交并将其合并到集成分支中。 我对git相当陌生，我不知道如何准确地做到这一点（在一个操作中选择合并范围而不是合并中的提交范围）而不弄乱存储库。 关于此有任何指示或想法吗？ 谢谢！ #1楼 当涉及到一系列提交时，挑选樱桃 是 是 不实际的。 就像 Keith Kim 在 下面提到的那样 ，Git 1.7.2+引入了对一系列提交进行樱桃选择的能力（但是您仍然需要意识到 为未来的合并选择樱桃 的 结果 ） git cherry-pick”学会了选择一系列提交 （例如“ cherry-pick A..B ”和“ cherry-pick --stdin ”），“ git revert ”也是如此； 但是，它们不支持更好的排序控件“ rebase [-i] ”。 达米安 评论 并警告我们： 在“ cherry-pick A..B ”格式中， A 应该早于 B 如果它们的顺序错误，则命令将静默失败 。 如果要选择 范围 B 到 D （含） ，则为 B^..D 请参阅“ Git从先前提交的范围创建分支？ ”作为插图。 正如 Jubobs 在评论中 提到 的 ： 假设 B 不是根提交； 否则，您将收到“ unknown revision

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 有时，我将DVD-rip放入一个网站项目中，然后不小心 git commit -a -m ... ，然后，zap的回购膨胀了2.2个演出。 下次我进行一些编辑，删除视频文件并提交所有内容，但是压缩文件仍在历史记录中。 我知道我可以从这些提交开始分支，并将一个分支重新建立到另一个分支。 但是，我应该怎么做才能将2个提交合并在一起，以便大文件不显示在历史记录中，并在垃圾回收过程中清除？ #1楼 请注意，此命令可能具有很大的破坏性。 如果更多的人在回购上工作，他们都将不得不拉新的树。 如果您的目标不是减小大小，则不需要三个中间命令。 由于filter分支会创建已删除文件的备份，因此可以在其中保留很长时间。 $ git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch YOURFILENAME" HEAD $ rm -rf .git/refs/original/ $ git reflog expire --all $ git gc --aggressive --prune $ git push origin master --force #2楼 git filter-branch --tree-filter 'rm -f path/to