re-base

如果你觉得 git 很迷惑人，那么这份小抄正是为你准备的！ 请注意我有意跳过了 git commit 、 git pull/push 之类的基本命令，这份小抄的主题是 git 的一些「高级」用法。 导航 —— 跳到之前的分支 git checkout - 查看历史 # 每个提交在一行内显示 git log --oneline # 在所有提交日志中搜索包含「homepage」的提交 git log --all --grep='homepage' # 获取某人的提交日志 git log --author="Maxence" **哎呀：** 之前重置了一个不想保留的提交，但是现在又想要回滚？ # 获取所有操作历史 git reflog # 重置到相应提交 git reset HEAD@{4} # ……或者…… git reset --hard <提交的哈希值> **哎哟：** 我把本地仓库搞得一团糟，应该怎么清理？ git fetch origin git checkout master git reset --hard origin/master 查看我的分支和 master 的不同 git diff master..my-branch 定制提交 # 编辑上次提交 git commit --amend -m "更好的提交日志" # 在上次提交中附加一些内容，保持提交日志不变git

闲谈 git merge 与 git rebase 的区别 前言 相信大部分使用 Git 的朋友都会遇见相同的疑问，并且也从网上搜索了不少资料。那么，为什么我还要写这篇文章呢？因为我想尝试从自己的角度解释这个问题，如果能给到大家灵光一闪的感悟，便善莫大焉啦。估计点进来的朋友也对 merge 和 rebase 有了一定了解，所以我也就不浪费篇幅再去详细介绍 merge 和 rebase，让我们直入主题吧。 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

经常被问到如何从一个分支合并特定的commits到另一个分支。有时候你需要这样做，只合并你需要的那些commits，不需要的commits就不合并进去了。 合并某个分支上的单个commit 首先，用git log或GitX工具查看一下你想选择哪些commits进行合并，例如： dd2e86 - 946992 -9143a9 - a6fd86 - 5a6057 [master] \ 76cada - 62ecb3 - b886a0 [feature] 比如，feature 分支上的commit 62ecb3 非常重要，它含有一个bug的修改，或其他人想访问的内容。无论什么原因，你现在只需要将 62ecb3 合并到master，而不合并feature上的其他commits，所以我们用 git cherry-pick 命令来做： git checkout master git cherry-pick 62ecb3 这样就好啦。现在 62ecb3 就被合并到master分支，并在master中添加了commit（作为一个新的commit）。 cherry-pick 和 merge 比较类似，如果git不能合并代码改动（比如遇到合并冲突），git需要你自己来解决冲突并手动添加commit。 合并某个分支上的一系列commits 在一些特性情况下，合并单个commit并不够

作者：你喜欢吃青椒么 juejin.im/post/5d157bf3f265da1bcc1954e6 前言 本文是参考廖雪峰老师的Git资料再加上我自己对Git的理解，记录我的Git学习历程，作下此文是为以后学习，工作，开发中如果遇到问题可以回过头来参考参考。因为水平有限，难免会有出错的地方，欢迎指正。 Git是什么 官方话：Git是一个免费的开源分布式版本控制系统，旨在快速高效地处理从小型到大型项目的所有事务。 引用廖雪峰老师的话，它能自动帮我记录每次文件的改动，还可以让同事协作编辑，这样就不用自己管理一堆类似的文件了，也不需要把文件传来传去。如果想查看某次改动，只需要在软件里瞄一眼就可以。 为什么要学习Git 面试要被问。可以应付面试。 很多公司开发都用Git来处理项目。现在不学，以后肯定还要学。 在我看来Git是现如今所有程序员都要掌握的，以后与同事共同开发项目必定要用到的，熟练掌握Git命令，可以提高开发的效率。 安装Git Windows 直接在官网上去下载。下载完成后，随便在某个文件下右键如果有Git Bash Here就安装成功。安装后，还要在命令行输入 $git config --global user.name "你的名字" $git config --global user.email "你的邮箱" global表示全局，这台机器所有的Git仓库都会使用这个配置

8 月初，当 Linux 5.8 RC 版本开放测试时，大多数的新闻都聚焦于它的 大小 ，称其为“史上最大的内核版本”。正如 Linus Torvalds 本人 指出的那样 ，“尽管没有任何一件事情能脱颖而出……但 5.8 似乎是我们有史以来最大的发行版之一。” 确实，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，约 80 万行新代码以及大约 100 名新贡献者。要知道，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间。Linux 内核维护者 Steven Rostedt 认为，5.8 之所以变得如此之大，很有可能是因为 COVID-19 疫情让很多人难以出门旅行，所有人都因此能够在这期间完成比平时更多的工作。 Rostedt 表示，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，5.8 RC 发行版特别令人震惊的并不是它的大小， 而是它的空前规模对于那些正在维护它的人来说却没有造成困扰 ，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程。” 拥有最佳的工作流程意味着什么？对 Rostedt 而言，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，以使他们能够持续不断地大规模、可靠地发展 Linux 内核项目。Rostedt 站在一个 Linux 内核资深维护者的角度

8 月初，当 Linux 5.8 RC 版本开放测试时，大多数的新闻都聚焦于它的大小，称其为“史上最大的内核版本”。正如 Linus Torvalds 本人指出的那样，“尽管没有任何一件事情能脱颖而出……但 5.8 似乎是我们有史以来最大的发行版之一。” 确实，刚刚发布的 Linux 内核 5.8 RC 具有超过 14,000 个 commit，约 80 万行新代码以及大约 100 名新贡献者。要知道，距离 5.7 正式版发布才仅仅过去了约 2 个月的时间。Linux 内核维护者 Steven Rostedt 认为，5.8 之所以变得如此之大，很有可能是因为 COVID-19 疫情让很多人难以出门旅行，所有人都因此能够在这期间完成比平时更多的工作。 Rostedt 表示，从一个经验丰富的 Linux 内核贡献者和维护者的角度来看，5.8 RC 发行版特别令人震惊的并不是它的大小，而是它的空前规模对于那些正在维护它的人来说却没有造成困扰，“我认为这是因为 Linux 具有比世界上任何软件项目都好的工作流程。” 拥有最佳的工作流程意味着什么？对 Rostedt 而言，这归结为 Linux 内核开发人员随着时间的推移建立的一系列基本规则，以使他们能够持续不断地大规模、可靠地发展 Linux 内核项目。Rostedt 站在一个 Linux 内核资深维护者的角度，为我们分享了庞大的

问题： During git rebase origin/development the following error message is shown from Git: 在 git rebase origin/development 过程中，Git显示以下错误消息： fatal: refusing to merge unrelated histories Error redoing merge 1234deadbeef1234deadbeef My Git version is 2.9.0. 我的Git版本是2.9.0。 It used to work fine in the previous version. 以前在以前的版本中可以正常工作。 How can I continue this rebase allowing unrelated histories with the forced flag introduced in the new release? 如何在新版本中引入强制标记的情况下继续进行此基础更改，以允许不相关的历史记录？ 解决方案： 参考一： https://stackoom.com/question/2ZBOy/Git拒绝合并基础上无关的历史记录 参考二： https://oldbug.net/q/2ZBOy/Git-refusing-to-merge

1.git简介 Git是目前最先进的分布式版本控制系统 版本控制系统：能够记录每次文件的改动 2.安装git 终端下输入： 代码块 brew install git 检查git是否安装成功，输入 代码块 git 出现以下界面，则表明安装成功 3.创建版本库 安装成功之后下来就是创建版本库： 初始化一个仓库： 1）在合适的地方创建一个空目录 2）切换到当前目录下 3）初始化仓库 代码块 mkdir learngit cd learngit git init 在仓库下创建新文件： 1）创建空文件夹 2）向文件夹中写入内容 代码块 touch readme.txt echo "readme">readme.txt 将文件放入Git仓库中： 1）将文件提交到暂存区 2）将文件提交到仓库 代码块 git add readme.txt git commit -m "commit file" 4.常用命令 1）查看日志： 如果觉得输出太多，可以加上 --pretty=oneline 代码块 git log 2）回退版本：git reset --hard xxx 代码块 git reset --hard HEAD^ //回退到上一个版本 git reset --hard xxx //xxx指commit id，输入git log进行查找 //如果是回退到某个版本，关掉了电脑，但是之后又后悔了

解决git init 方法下push失败报错的方法 * 平时拉取远程仓库我们大多数情况下会使用git clone，这样远程仓库会自动在你的目录下生成文件夹，接下来的步骤也就简单的多了，只需要add ./;git comiit -m"##"/git push即可将本地仓库的数据上传至远程主机。 在我们使用git init方法的时候，是将本地的文件夹和gitee远程主机建立关联，代码是git remote add origin 仓库地址。判断是否成功关联可输入remote -v。 当我们使用这种办法准备将本地文件push到远程主机时经常会出现报错，一般分为2种情况。 1.用户名或者密码错误。（此错误提示明显） 2.由于之前使用过别的办法建立本地和线上连接，因此需要将控制面板内的凭据删除。如果依然不能解决可以试试git pull --rebase origin master （一般来说第一次是不需要拉取远程仓库的）。最后还有一种暴力的办法，前提是确保远程仓库是新建的没有重要文件，git push -f origin ”##“（强制推送，会覆盖仓库原有内容）。 来源： oschina 链接： https://my.oschina.net/u/4392911/blog/4513758

查看提交历史 使用 git log 命令查看提交历史： 使用rebase命令 想要合并前三个 commit ，使用下面的命令： git rebase -i HEAD~3 进入编辑界面，把要保留的 commit 使用pick，其他的使用squash命令，或者根据命令提示选择自己想用的命令。 保存退出，git会压缩提交历史，如果有冲突，需要修改，修改的时候要注意，保留最新的历史，不然我们的修改就丢弃了。修改以后要记得敲下面的命令： git add . git rebase --continue 如果你想放弃这次压缩的话，执行以下命令： git rebase --abort 如果没有冲突，或者冲突已经解决，则会出现如下的编辑窗口，此时就可以写合并之后commit的信息了。 将信息修改后保存退出，可以看到成功的命令。 通过 git log 命令，可以看到 commit 已经成功合并成了一个。 来源： oschina 链接： https://my.oschina.net/u/4323755/blog/4511437