re-base

前言 汇总下我在项目种高频使用的 git 命令。 官方文档肯定比我全面，这里是结合实际业务场景输出。 使用的 Git版本：git version 2.24.0 命令 git log 查看日志，常规操作，必备 输出概要日志,这条命令等同于 git log --pretty=oneline --abbrev-commit git log --oneline 指定最近几个提交可以带上 - + 数字 git log --oneline -5 提供类似 GUI 工具的 log 展示 git log --graph --date=relative --pretty=tformat:’%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ad)%Creset’ 复制代码 git status 查看工作区状态的东东，不如GUI直观，但是命令行也有一些用的 等同 git status --long,查看当前工作区暂存区变动 git status 概要信息 (–short) git status -s 查询工作区中是否有stash存在（暂存的东西）,有则提醒该工作区有几个 stash git status --show-stash 复制代码 git checkout 用来切换到对应记录的,可以基于分支,提交,标签。

前言 汇总下我在项目种高频使用的 git 命令。 官方文档肯定比我全面，这里是结合实际业务场景输出。 使用的 Git版本：git version 2.24.0 命令 git log 查看日志，常规操作，必备 输出概要日志,这条命令等同于 git log --pretty=oneline --abbrev-commit git log --oneline 指定最近几个提交可以带上 - + 数字 git log --oneline -5 提供类似 GUI 工具的 log 展示 git log --graph --date=relative --pretty=tformat:’%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ad)%Creset’ 复制代码 git status 查看工作区状态的东东，不如GUI直观，但是命令行也有一些用的 等同 git status --long,查看当前工作区暂存区变动 git status 概要信息 (–short) git status -s 查询工作区中是否有stash存在（暂存的东西）,有则提醒该工作区有几个 stash git status --show-stash 复制代码 git checkout 用来切换到对应记录的,可以基于分支,提交,标签。

前言 汇总下我在项目种高频使用的 git 命令。 官方文档肯定比我全面，这里是结合实际业务场景输出。 使用的 Git版本：git version 2.24.0 命令 git log 查看日志，常规操作，必备 输出概要日志,这条命令等同于 git log --pretty=oneline --abbrev-commit git log --oneline 指定最近几个提交可以带上 - + 数字 git log --oneline -5 提供类似 GUI 工具的 log 展示 git log --graph --date=relative --pretty=tformat:’%Cred%h%Creset -%C(auto)%d%Creset %s %Cgreen(%an %ad)%Creset’ 复制代码 git status 查看工作区状态的东东，不如GUI直观，但是命令行也有一些用的 等同 git status --long,查看当前工作区暂存区变动 git status 概要信息 (–short) git status -s 查询工作区中是否有stash存在（暂存的东西）,有则提醒该工作区有几个 stash git status --show-stash 复制代码 git checkout 用来切换到对应记录的,可以基于分支,提交,标签。

githooks.png Githook 也称 Git 钩子，是在 Git 仓库中特定事件发生时自动运行的脚本。它可以让你自定义 Git 内部的行为，在开发周期中的关键点出发自定义行为。 Git Hook 最常见的使用场景包括推行提交信息规范，根据仓库状态来改变项目环境，和接入持续集成工作流。但是因为脚本可以完全定制，你可以用 Git Hook 来自动化或者优化你开发工作流中任意部分。 Git Hook 是仓库中特定事件发生时 Git 自动运行的普通脚本。因此 Git Hook 安装和配置也非常容易。Hook 在本地或服务端仓库都可以部署，且只会在仓库中事件发生时被执行。 背景：想在每一次代码commit的时候发送一封邮件到相关人员的邮箱 前提：阅读以下文字需要有一定Git基础的朋友，请参见之前的文章：五步法掌握Git基本操作 实验环境： Python3.5 Pycharm(最顺手的IDE而已) Windows系统 Win7 Hook 存在于每个 Git 仓库的 .git/hooks 目录中。当你初始化仓库时，Git 自动生成这个目录和一些示例脚本。你可以在某个 .git/hooks 中，查看这些文件，如下图： Hooks目录.png 注：本地没有git仓库的可以随意git clone一个，但是需要有权限可以做git commit，好做之后的练习。 编写脚本语言 内置的脚本大多是

git pull && git fetch 通过一张图了解下，git fetch和git pull的概念： fetch：将远程主机更新内容拉到本地，用户检查后决定是否合并到工作分支上。 pull：将远程主机更新内容拉到本地直接合并，git pull = git fetch + git merge，这样可能产生冲突。 git pull的问题是把过程中的细节隐藏起来了，一旦代码有问题就很难找到出错的地方。 git stash 当你在一个分支上在进行开发时，临时需要切换到另一个分支解决一些比较紧急的事情，问题是你才工作了一般，你不想回不到这个工作点，这时就需要用git stash命令了。 git stash 是“储藏”的意思，可以获取你工作目录的中间状态，修改过的追踪文件可以放到一个未变更的堆栈中，随时可以重新应用。 git stash（这个） 保存当前的工作进度。会分别对暂存区和工作区的状态进行保存。 git stash save “message…” 这条命令实际上是第一条 git stash 命令的完整版。 git stash list 显示进度列表。此命令显然暗示了git stash 可以多次保存工作进度，并用在恢复时候进行选择。 git stash pop（这个） 如果不使用任何参数，会恢复最新保存的工作进度，并将恢复的工作进度从存储的工作进度列表中清除。 git stash

前言 其实这个问题困扰我有一段时间，相信也有人和我一样有这个困扰，网上已有很多这种解释了，但是要么就是无图，要么就是解释的很乱，没太看懂，经过自己对git的使用，加上向同事请教，算是理解了这个问题，所以写下来分享一下，我尽量详细说明 merge与rebase的区别 假设我们有如下图一所示仓库，该仓库有master和develop两个分支，且develop是在（3.added merge.txt file）commit处从master拉出来的分支。 图一 merge 假设现在HEAD在（6.added hello.txt file）处，也就是在master分支最近的一次提交处，此时执行git merge develop, 结果如下图所示。 图二 工作原理就是：git 会自动根据两个分支的共同祖先即 (3.added merge.txt file)这个 commit 和两个分支的最新提交即 (6.added hello.txt file) 和 (5.added test.txt file) 进行一个三方合并，然后将合并中修改的内容生成一个新的 commit，即图二的(7.Merge branch ‘develop’)。 这是merge的效果，简单来说就合并两个分支并生成一个新的提交。 rebase 那rebase是这么工作的呢？ 假设初始状态也是图一所显示的。两个分支一个master

修改历史提交记录 作用简要概括为：可以对某一段线性提交历史进行编辑、删除、复制、粘贴；因此，合理使用rebase命令可以使我们的提交历史干净、简洁！ 前提：不要通过rebase对任何已经提交到公共仓库中的commit进行修。 1.合并多个commit为一个完整commit 我们在本地仓库中提交了多次，在我们把本地提交push到公共仓库中之前，为了让提交记录更简洁明了，我们希望把如下分支B、C、D三个提交记录合并为一个完整的提交，然后再push到公共仓库。 现在我们在测试分支上添加了四次提交，我们的目标是把最后三个提交合并为一个提交： 这里我们使用命令: git rebase -i [startpoint] [endpoint] 区间指定的是一个前开后闭的区间 其中 -i 的意思是 --interactive ，即弹出交互式的界面让用户编辑完成合并操作， [startpoint] [endpoint] 则指定了一个编辑区间，如果不指定 [endpoint] ，则该区间的终点默认是当前分支HEAD所指向的commit(注：该区间指定的是一个前开后闭的区间)。 在查看到了log日志后，我们运行以下命令： git rebase -i 53d6d02df 或 git rebase -i HEAD~3 然后我们会看到如下界面: 上面未被注释的部分列出的是我们本次rebase操作包含的所有提交

概述 在之前总结分支相关内容时说道，合并两个分支的提交可以使用git merge，然而除了这种方式之外，还有一种方式就是使用git rebase，这两种方式的最终结果都相同，但是合并历史却不同；git merge是将两个分支做一个三方合并(如果不是直接上游分支)，这样一来，查看提交历史记录，可能会显得非常凌乱。git rebase则会将当前分支相对于基低分支的所有提交生成一系列补丁，然后放到基底分支的顶端，从而使得提交记录变称一条直线，非常整洁。 git merge 和 git rebase 区别 假设现在本地仓库中有两个分支:master分支和branch1分支,提交历史用图来表示如下： 现在要合并branch1到master分支，如果使用git merge则执行如下命令： $ git checkout master $ git merge branch1 合并后查看提交历史如下： $ git log --graph --pretty="oneline" * fe8799e0aec30e388306883960b4cf438d3f1ec4 Merge branch 'branch1' |\ | * cf31255da6e84acc6f6840e3ceb0fd3129e2d73e UserA commit 3--branch1 | *

写在前面 如果你不能很好的应用 Git，那么这里为你提供一个非常棒的 Git 在线练习工具 Git Online ，你可以更直观的看到你所使用的命令会产生什么效果 另外，你在使用 Git 合并分支时只会使用 git merge 吗？有时使用 git rebase 可以比 git merge 做出更优雅的操作 Merge 与 Rebase 不知怎么， git rebase 命令被赋予了一个神奇的污毒声誉，初学者应该远离它，但它实际上可以让开发团队在使用时更加轻松。 你可以将它理解成「七伤拳」，「七伤拳」并不是不能练，只是练「七伤拳」有一个先诀条件，那就是内功境界一定要非常高，即你要充分理解 git rebase 命令 在本文中，我们将 git rebase 与 git merge 命令进行比较。在 Git 工作流中，说明所有可以使用 rebase 的场景 概念概述 关于 git rebase ，首先要理解的是它解决了和 git merge 同样的问题。这两个命令都旨在将更改从一个分支合并到另一个分支，但二者的合并方式却有很大的不同。 当你在专用分支上开发新 feature 时，然后另一个团队成员在 master 分支提交了新的 commits，这会发生什么？这会导致分叉的历史记录，对于这个问题，使用 Git 作为协作工具的任何人来说都应该很熟悉。 现在，假设在 master

原项目使用git管理. 因为各种原因需要提交到svn库. 参考资料 创建svn库 svn co http://svn.example.com/foo cd myproj svn mkdir trunk svn commit -m'Created trunk directory' 或者直接在现有的repository上创建目录 svn mkdir --parents http://url/dir_name --message "messages" 设置svn远程库 2.1 clone git项目 git clone ~git/repositories/foo/mainline.git ~git/repositories/svn-mirror/foo cd ~git/repositories/svn-mirror/foo 2.2 在.git/config中添加svn-remote [svn-remote "svn"] url = http://svn.example.com/foo/trunk fetch = :refs/remotes/git-svn 提交项目到svn库 3.1 从空的svn远程库中做初始化fetch,并将其作为一个新分支checkout git svn fetch svn git checkout -b svn git-svn 3.2