本文转载自:https://www.jianshu.com/p/e5d801b936b6 前提: 生成patch: git format-patch -M master 生成指定patch,0163bed3bf59ae74c36cc5138b4c24f1556d8304是commit id,-1是指从当前id开始,向下提交次数,包含此次且计数从1开始. 也就是说,我想要打出0163bed3bf59ae74c36cc5138b4c24f1556d8304当前的patch,则: git format

git diff 简易操作说明 先git log 查看commit ID, 记录你想要打的补丁的ID 比如说: git log commit 4ff35d800fa62123a28b7bda2a04e749addf1918 Author: chenfulin5 <chenfulin5@gmail.com> Date: Tue Dec 20 17:37:09 2016 +0800 [I2C EEPROM] commit acb8cd154cecf20894ae25fc3787d6b6ba9b32

一. 创建与合并分支 1. 从master分支创建dev分支并切换到dev分支: git checkout master git checkout -b dev 其中,git checkout -b dev 等价于: git branch dev git checkout dev 查看本地当前的分支,分支前面带“*”表示当前分支,剩下的分支表示本地有的分支:  git branch 查看远程全部的分支,白色的表示本地有的,红色的表示本地没有,仅在远程存在: git branch -a 2.修改代

一.打补丁 git format-patch & git apply 最近在工作中遇到打补丁的需求,一来觉得直接传文件有些low(而且我尝试了一下,差点把项目代码毁了) ,二来也是想学习一下,so,format-patch对于我来讲是个新命令,将处理流程与技巧卸备份在这里. 1.从A分支git checkout -b B,新建一个新分支 2.找到打补丁的人相对A分支,开始写补丁的commitid,并git reset --hard 将head指向这一分支,如此一来保证补丁的应用场景是有一样的 3

git diff commit_id 会生成最后一次提交到目前修改过的内容补丁 git diff commit_id1 commit_id2 会生成两次提交之间修改过的内容补丁 git format-patch -1 commit_id -o D:/patch 生成当前提交内容的补丁 git format-patch commit_id1...commit_id2 -o D:/patch 打补丁: git am xxxxxx.patch 有冲突的时候: git apply –reject xxx

1.制作补丁 diff - 逐行比较文件 格式 diff   参数   旧文件/旧文件夹   新文件/新文件夹 -N   将不存在的文件看作是空的 -a   将所有文件都视为文本文件 -u   以合并的方式来显示文件内容的不同 -r   以递归地方式比较所有子目录 // 比较Test2在Test1版本上的更新并输出 diff -Naru Test1 Test2 // 比较Test2在Test1版本上的更新并输出到文件diff.patch diff -Naru Test1 Test2 > diff

git cherry-pick 可以把某个分支的某几次提交合入到当前分支,只是在一台设备上操作. git format-patch 可以把某个分支的n次提交分别打成n个补丁,然后把这些补丁文件(比如0001-.patch)发给其他人,或者发到其他机器,他们在自己的机器上,把这些补丁合入到他们当前的代码中. 比如,分支erebus20180910相比master分支,多了一次提交,打补丁就生成一个补丁文件 参考:https://www.jianshu.com/p/814fb6606734 1.在g

http://stackoverflow.com/questions/1191282/how-to-see-the-changes-between-two-commits-without-commits-in-between you can simply pass the 2 commits to git diff like : -> git diff 0da94be 59ff30c > my.patch -> git apply my.patch

必要的概念 当前编辑界面:工作区(workspace) "git add"命令:将改动加入到缓存区(Index) "git commit"命令:提交代码到本地库(Local Repository) "git push"命令:提交代码到远程库(Remote Repository) 未使用"git add"命令缓存代码时 git checkout git checkout -- <filepathname> # 丢弃工

8.撤销修改 $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. My stupid boss still prefers SVN. #把在工作区readme.txt文件中增加了一行 查看工作区re

工作区内容修改了, 但是并未add到暂存区, 想 回退到上一个版本 在readme.txt中添加了一行: Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. My stupid boss still prefers SVN. 纠正这

转自:http://blog.csdn.net/aaronzzq/article/details/6955893 git version 1.6.0.4 几个新手刚刚开始接触 Git,为了维护核心仓库的“纯洁”,避免太多无关信息被误提交进仓库(再次批评一些图形化工具默认的“Select All”),采用了核心仓库只读,邮件提交 patch,审核后再提交的工作流程. 期间有时会遇到合并冲突,正常的原因一般是未及时下载新版本产生了冲突,特殊一点的原因是手工修改 patch 内容导致的.有时候看注释写

一.撤销指令 git checkout还原工作区的功能 git reset  还原暂存区的功能 git clean  还没有被添加进暂存区的文件也就是git还没有跟踪的文件可以使用这个命令清除他们 git revert 撤销本次提交. 二.指令讲解 Git checkout 首先我们对文件的一个修改,对master.txt进行了修改 修改结果我们利用上面的知识来进行查看. 新增加了Test这么一段话,如果我们想要将工作区的内容添加到暂存区会使用git  add这个命令,如果我们想要还原工作区内容

问题 在使用git时,在未添加.ignore文件前使用 git add . 将所有文件添加到库中,不小心将一些不需要加入版本库的文件加到了版本库中.由于此时还没有提交所以不存在HEAD版本,不能使用 git reset HEAD命令. 解决 使用 git rm -r --cached . 不小心使用git pull合并冲突,如果想把当前的修改都放弃,你可以用下面的命令回到合并之前的状态:git reset --hard HEAD或者如果你已经把合并的代码提交了,这时候的撤销需要下面的命令:git

一.撤销指令 git checkout还原工作区的功能 git reset  还原暂存区的功能 git clean  还没有被添加进暂存区的文件也就是git还没有跟踪的文件可以使用这个命令清除他们 git revert 撤销本次提交. 二.指令讲解 Git checkout 首先我们对文件的一个修改,对master.txt进行了修改 修改结果我们利用上面的知识来进行查看. 新增加了Test这么一段话,如果我们想要将工作区的内容添加到暂存区会使用git  add这个命令,如果我们想要还原工作区内容

1. git cherry-pick 作用:从一个branch上选择一个commit,添加该commit到另一个branch上. 1. 切换到你想添加commit的分支上. git checkout master 2. 执行下面的代码 git cherry-pick <commit-hash> 2. git rebase 作用:git rebase命令是一个自动化的cherry-pick命令, 它会添加一个branch上的所有commit到另一个branch上(找到一个branch上的所有co

自然,你是不会犯错的.你在readme.txt中添加了一行: $ cat readme.txt Git is a distributed version control system. Git is free software distributed under the GPL. Git has a mutable index called stage. Git tracks changes of files. My stupid boss still prefers SVN. 在你准备提交前,

在阅读廖雪峰git教程时,对版本回退和暂存区撤销修改没太看懂,所以自己测试了一下. 版本回退: git reset --hard HEAD 这个命令用于版本回退,就是将已提交的版本覆盖本地工作区的内容.该操作会清空暂存区的内容 撤销修改: git checkout -- file 撤销对工作区的修改,以最新一次的时间节点(add或者commit)为准,这个命令只改变工作区内容 清空暂存区修改: git reset HEAD -- file 清空add命令向暂存区提交的修改,该操作之影响暂存区,对

merge后发现冲突太多,或者合并的分支代码并不是最新,那就直接撤销再合并好了. git reset --hard HEAD 用来撤销还没commit 的merge,其实原理就是放弃index和工作区的改动.

撤销更改 相信你已经了解了 git 的基本概念,也清楚了工作区,暂存区和版本库的关系,现在让我们用所学的知识继解决实际问题吧! 背景 正常看得见的目录是我们最为熟悉的工作区,在工作中不可能总是100%的精力,难免会犯错,尤其是下午犯困,晚上加班更是如此.下面列举了常见的一些场景 场景一: 工作区出现意外更改且尚未添加到暂存区 北京时间现在是晚上10点钟,你正在赶制一份工作报告,尽管心中一万个不愿意,还是不得不做. 开始模拟意外更改前,先查看一下 test.txt 文件相关信息: # 列出当前目录