re-base

Git应用开发学习 这，仅是我学习过程中记录的笔记。确定了一个待研究的主题，对这个主题进行全方面的剖析。笔记是用来方便我回顾与学习的，欢迎大家与我进行交流沟通，共同成长。不止是技术。 一旦你会使用了Git，就再也不想使用SVN了。永远也回不去了。 Mac上使用Git，肯定离不开对Mac上的操作。就要使用常用的Linux命令来进行操作。通过终端来进行操作。 学习Git一定要使用命令行的方式来学习。不要使用图形界面来操作学习。会大大折扣的哦。 花了时间来学习一门东西。一定要得到自己想要喜欢的东西。 课程的内容 Git官网 常见Linux命令介绍 Git在各平台下的安装与配置 分布式与集中式版本控制系统的差别 缓存区、工作区与Git提交 版本回退 修改与撤销修改、文件的添加与删除 Git对象类型与索引 Git分支branch 如何创建、切换与删除分支 Git分支在项目开发中的作用 Git分支在工程化项目中的最佳实践 分支常见重要命令详解 Git merage Git冲突解决策略 HEAD详解 Git Commit修改详解 远程版本库介绍 如何使用远程版本库 Git puah 、pull、fetch使用与注意事项 Git合并的基本原则 Git别名、config文件详解 Git tag详解 如何创建于推送tag Git feature分支详解 合适应该使用submodule Git

阿里妹导读 ：如何治理测试稳定性问题？很多人会说：环境、流程管控、监控、工具化、加机器、专人负责、等等。这些都是对的。不过这些都是解决方案层面的，而不是方法论和理论体系层面的。今天，阿里研究员郑子颖来说说测试稳定性的三板斧。据说，阿里同学们都非常认同这三板斧，看完文章感觉很多做的事情有了理论基础。 郑子颖：阿里巴巴研究员，2002年上海交通大学计算机系硕士毕业。2018年3月加入阿里，负责质量和技术风险。 1. 测试稳定性问题 理想情况下，我们希望每一个失败的测试用例[1]都是由真正的缺陷引起的。实际情况中，用例失败的原因大多是一些其他的原因： 某个服务的版本部署的不对 测试执行机的硬盘满了，因为上次运行时写的log没清掉 数据库里有脏数据 测试用例写得有问题 测试运行时有人手工执行了一次定时任务，把流水捞走了 消息串了 ... 每次排查都是一堆这种问题，时间久了，开发和测试同学也就疲了。有些同学对失败的用例草草看一眼，就说这是一个“环境问题”，不再排查下去了。如此一来，很多真正的缺陷就被漏过了。 2. 测试稳定性三板斧 如何治理测试稳定性问题？很多人会说：环境、流程管控、监控、工具化、加机器、专人负责、等等。这些都是对的。不过这些都是解决方案层面的，而不是方法论和理论体系层面的。 在方法论和理论体系层面，我们对安全生产有三板斧：可灰度、可监控、可回滚。类似的，对于测试稳定性

本文将介绍如何把本地项目上传到git。 1. 先进入项目文件夹，通过命令 git init 把这个目录变成git可以管理的仓库 git init 2. 把文件添加到版本库中，使用命令 git add .添加到暂存区里面去，不要忘记后面的小数点“.”，意为添加文件夹下的所有文件 git add . 3. 用命令 git commit告诉Git，把文件提交到仓库。引号内为提交说明 git commit -m 'first commit' 4. 关联到远程库 git remote add origin 你的远程库地址。如：git remote add origin https://github.com/cade8800/ionic-demo.git 5. 新建一个本地分支： git checkout -b qunar_yuzhan_star 6. 获取远程库与本地同步合并（如果远程库不为空必须做这一步，否则后面的提交会失败） git pull --rebase origin qunar_yuzhan_star 7. 把本地库的内容推送到远程，使用 git push命令，实际上是把当前分支qunar_yuzhan_star推送到远程。执行此命令后会要求输入用户名、密码，验证通过后即开始上传。 git push -u origin qunar_yuzhan_star 附: 删除远程分支

比如要修改的 commit 是倒数第三条，使用下述命令： git rebase -i HEAD~3 其输出类似： pick commit_id_1 pick commit_id_2 pick commit_id_3 假如修改 commit_id_1 的提交信息，将其前面的 pick 改为 edit，之后 wq 保存。然后执行： git commit --amend 修改提交的信息，并 wq 保存。 执行： git rebase --continue 推送： git push -f 来源： oschina 链接： https://my.oschina.net/u/4406751/blog/3227636

问题： I am trying to merge 2 commits into 1, so I followed “squashing commits with rebase” from git ready . 我正在尝试将2个提交合并为1个，因此我遵循 了git ready中的“使用rebase压缩提交” 。 I ran 我跑了 git rebase --interactive HEAD~2 In the resulting editor, I change pick to squash and then save-quit, but the rebase fails with the error 在结果编辑器中，我将 pick 改为 squash ，然后保存退出，但是rebase失败并显示以下错误 Cannot 'squash' without a previous commit 没有先前的提交就无法“压扁” Now that my work tree has reached this state, I'm having trouble recovering. 现在我的工作树已达到此状态，我无法恢复。 The command git rebase --interactive HEAD~2 fails with git rebase --interactive HEAD~2

今天来介绍下 git 的 rebase 命令。这个命令是我进入新公司之后才了解到的，以前还真的没使用过，尽管我接触 git 已经有 3 年了。 假如现在有个项目，它的 git 状态是这样的： 这是背景，接下来我们正式开始今天的内容。 分支合并 我们先在 master 分支的基础上新建一个 dev 分支, 并做一个 commit： > $(master) git checkout -b dev 这时候另外一个开发人员发现 master 上的代码有一个问题，对 master 的代码做了一个 fix，使得 master 的 head 向前推进了一步: 如果我们想将 master 的 Fix 改动应用到 dev 分支上，要如何做呢？ 可以使用 merge，我们来试下： $(dev) git merge master merge 过后 dev 分支向前推进了一步。我们看下多出来的 commit 信息是怎样的 dev 上 多出来的这个 commit（绿色的那个节点）, 就是我们的 merge 信息。 有时候我们并不想要 git 记录这个 merge 信息，因为让 git 的历史记录变得很繁琐，要如何做呢？可以使用 rebase ！ 我们先回到 master 提交了 fix 之后的 git 状态： 执行 rebase 命令： $ (dev) git rebase master 这时候看下 git

3 月，跳不动了？>>> 感谢参考原文- http://bjbsair.com/2020-03-27/tech-info/7056/ 请注意我有意跳过了 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 "更好的提交日志" #

3 月，跳不动了？>>> 今天早上看到 IDEA 可以升级新版本，想着体验一下新功能，点击升级，然后全部项目工程无法打开。 报错信息如下： Cannot execute command No project found to open file in 在项目窗口选择项目工程也不行，出现 闪退 现象。 网上搜索了一把，没有找到具体的解决办法，没办法只能靠自己。 突然想到可以看一下 IDEA 相关日志，看下是否有什么有用的报错信息。 如果使用 toolbox 可以在 IDEA 设置中，找到如下按钮快速打开。 若没有安装 toolbox，可以在下面路径找到： // macos IDEA-XX 代表你要查找 IDEA 具体版本，例如：~/Library/Logs/IntelliJIdea2019.3 ~/Library/Logs/<product><version> // windows 例如：C:\Users\JohnS\.IntelliJIdea2019.3\system\log %HOMEPATH%\.<product><version>\system\log 打开日志文件，显示一堆错误，最明显错误如下： 看到这里，初步怀疑 FindBugs-IDEA 暂不适配最新版本 IDEA，从而导致项目工程打不开。 另外切回窗口窗口如下位置，也能看到报错信息。 在插件管理处禁用该插件

3 月，跳不动了？>>> 问题描述 在团队迭代开发中，每个开发人员都会在发起线上合并请求时commit多次，即每人每次发起的合并请求存在多次提交记录。在别的开发人员fetch rebase时，会出现同样冲突重复解决多次的问题。 解决方式 通过git rebase方式，合并最近几次的提交记录 如下命令合并最近4次的提交 git rebbase -i HEAD~4 注意 如果本地存在不需要提交的配置文件（远端存在该文件），需要先stash贮藏，不然会提示error 实操 git stash 贮藏不需要提交的文件 git rebase -i HEAD~2 合并最近两次提交记录，此时会弹出文本编辑框 在文本编辑框中修改合并后的提交记录，保存关闭文本编辑框，命令行会提示完成sucessfully rebase 来源： oschina 链接： https://my.oschina.net/sunwenhao/blog/3198266

我有分支冲突，branch2从branch1分支。 让我们说当在当前 branch2 上重新定位 branch2 时，在解决冲突时，我决定按 branch1 使用 一些 （不是全部）“他们的”（即 branch1 ）文件。 我怎么做？ 我试过了： git checkout branch1:foo/bar.java fatal: reference is not a tree: TS-modules-tmp:foo/bar.java git checkout refs/heads/branch1:foo/bar.java fatal: reference is not a tree: refs/heads/TS-modules-tmp:foo/bar.java #1楼 你想用： git checkout --ours foo/bar.java git add foo/bar.java 如果你将一个分支 feature_x 反对 master （即在分支 feature_x 上运行 git rebase master ），在 git rebase master 期间 ours 指的是 master 和 theirs 的 feature_x 。 正如 git-rebase文档中 指出的那样： 请注意，rebase合并的工作原理是从分支顶部的工作分支重放每个提交。 因此，当合并冲突发生时