git高级命令个人学习教程

合并多个提交假设要合并最后的2个提交，可以按如下命令进行：1.gitrebase–iHEAD~2运行完该命令，会出现如下所示内容：2.将第二个pick修改为squash或者s，然后输入:wq”退出。3.这时git会自动第二个提交合并到第一个中去。并提示输入新的message（就是我们常说的comments），如下：4.编辑输入新的message，然后输入:wq退出5.此时本地的（HEAD中）最后两次提交已经被合并为一个。gitlog可以查看。6.如果需要提交到远端，运行gitpush--forceoriginmaster即可。修改提交日志gitcommit--amend然后会打开一个编辑器，你可以修改以前的提交日志信息了。修改作者：gitcommit--amend--reset-author但这个只以修改最后一个提交的信息。如何修以前的信息？gitrebase-iHEAD~3会打开一个编辑器，把将要修改日志前面改成edit，然后退出。再运行：gitcommit--amend编辑完后，再恢复：gitcommit--continuegit放弃本地更改然后更新当使用gitpull命令的时候如果提示有本地文件修改了，无法合并的时候，我们可以放弃本地修改，然后再更新；如果不想放弃本地修改，可以先提交，然后再更新：提交gitcommit如果要放弃本地修改后更新：gitreset--hardgitpull制作补丁制作补丁有两种方式：1.gitdiff我们可以首先用gitdiff制作一个patch。本文示例的工作目录里最初有一个文件a，内容是“Thisisthefilea.”，放置在master分支中。为了修改代码，我们一般的做法是建立一个新分支：sweetdum@sweetdum-ASUS:~/GitEx$gitbranchFixsweetdum@sweetdum-ASUS:~/GitEx$gitcheckoutFixSwitchedtobranch'Fix'接下来我们在a文件里面追加一行，然后执行gitdiff。sweetdum@sweetdum-ASUS:~/GitEx$echo'Fix!!!'asweetdum@sweetdum-ASUS:~/GitEx$gitdiffdiff--gita/ab/aindex4add65f..0d295ac100644---a/a+++b/a@@-1+1,2@@Thisisthefilea.+Fix!!!我们看到了Gitdiff的输出，这是一个非常典型的Patch式diff。这样我们可以直接把这个输出变为一个Patch：sweetdum@sweetdum-ASUS:~/GitEx$gitcommit-a-mFix[Fixb88c46b]Fix1fileschanged,1insertions(+),0deletions(-)sweetdum@sweetdum-ASUS:~/GitEx$gitdiffmasterpatchsweetdum@sweetdum-ASUS:~/GitEx$gitcheckoutmasterSwitchedtobranch'master'当然，用这种方法，你不用提交，也可以直接导出patchgitdiffpatch我们现在有一个patch文件，并且签出了master，接下来我们可以使用gitapply来应用这个patch。当然了，实际应用中，我们不会这样在一个分支建patch，到另一个分支去应用，因为只有merge一下就好了。我们现在权当没有这个Fix分支。一般情况下，为了保护master，我们会建立一个专门处理新交来的patch的分支：sweetdum@sweetdum-ASUS:~/GitEx$gitbranchPATCHsweetdum@sweetdum-ASUS:~/GitEx$gitcheckoutPATCHSwitchedtobranch'PATCH'sweetdum@sweetdum-ASUS:~/GitEx$gitapplypatchsweetdum@sweetdum-ASUS:~/GitEx$gitcommit-a-mPatchApply[PATCH9740af8]PatchApply1fileschanged,1insertions(+),0deletions(-)看，现在我们在PATCH分支中应用了这个补丁，我们可以把PATCH分支和Fix比对一下，结果肯定是什么也没有，说明PATCH分支和Fix分支完全一样。patch应用成功。即使有多个文件gitdiff也能生成一个patch。2.gitformat-patch我们同样用上面那个例子的工作目录，这次，我们在Fix分支中的a添加了新行之后，用gitformat-patch生成一个patch。sweetdum@sweetdum-ASUS:~/GitEx$gitcheckoutFixSwitchedtobranch'Fix'sweetdum@sweetdum-ASUS:~/GitEx$echo'Fix!!!'asweetdum@sweetdum-ASUS:~/GitEx$gitcommit-a-mFix1[Fix6991743]Fix11fileschanged,1insertions(+),0deletions(-)sweetdum@sweetdum-ASUS:~/GitEx$gitformat-patch-Mmaster0001-Fix1.patchgitformat-patch的-M选项表示这个patch要和那个分支比对。现在它生成了一个patch文件，我们看看那是什么：sweetdum@sweetdum-ASUS:~/GitEx$cat0001-Fix1.patchFrom6991743354857c9a6909a253e859e886165b0d90MonSep1700:00:002001From:[e-mail]:Mon,29Aug201114:06:12+0800Subject:[PATCH]Fix1---a|1+1fileschanged,1insertions(+),0deletions(-)diff--gita/ab/aindex4add65f..0d295ac100644---a/a+++b/a@@-1+1,2@@Thisisthefilea.+Fix!!!--1.7.4.1看，这次多了好多东西，不仅有diff的信息，还有提交者，时间等等，仔细一看你会发现，这是个E-mail的文件，你可以直接用gitsend-email发送它！gitsend-email用法：中文：这种patch，我们要用gitam来应用。sweetdum@sweetdum-ASUS:~/GitEx$gitcheckoutmasterSwitchedtobranch'master'sweetdum@sweetdum-ASUS:~/GitEx$gitbranchPATCHsweetdum@sweetdum-ASUS:~/GitEx$gitcheckoutPATCHsweetdum@sweetdum-ASUS:~/GitEx$gitam0001-Fix1.patchApplying:Fix1sweetdum@sweetdum-ASUS:~/GitEx$gitcommit-a-mPATCHapply在提交了补丁之后，我们可以再看看目前文件a的情况：sweetdum@sweetdum-ASUS:~/GitEx$cataThisisthefilea.Fix!!!果然，多了一个Fix!!!不过要注意的是，如果master与Fix分支中间有多次提交，它会针对每次提交生成一个patch。1使用gitformat-patch生成所需要的patch:当前分支所有超前master的提交：gitformat-patch-Mmaster某次提交以后的所有patch:gitformat-patch4e16--4e16指的是commit名从根到指定提交的所有patch:gitformat-patch--root4e16某两次提交之间的所有patch:gitformat-patch365a..4e16--365a和4e16分别对应两次提交的名称某次提交（含）之前的几次提交：gitformat-patch–n07fe--n指patch数，07fe对应提交的名称故，单次提交即为：gitformat-patch-107fegitformat-patch生成的补丁文件默认从1开始顺序编号，并使用对应提交信息中的第一行作为文件名。如果使用了--numbered-files选项，则文件名只有编号，不包含提交信息；如果指定了--stdout选项，可指定输出位置，如当所有patch输出到一个文件；可指定-odir指定patch的存放目录；2应用patch：先检查patch文件：gitapply--statnewpatch.patch检查能否应用成功：gitapply--checknewpatch.patch打补丁：gitam--signoffnewpatch.patch(使用-s或--signoff选项，可以commit信息中加入Signed-off-by信息)如果应用patch出现问题：参考gitamPATCH失败的处理方法参考资料：git-format-patch(1)-Linuxmanpage://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git在日常使用GIT过程中，经常会出错，比如无意间丢失了未提交的数据，回退版本时丢失了工作目录，等等。经过思考发现，所有这些错误都是因为对GIT中一些基本的概念模糊而导致，因为对一些基本概念不清晰，导致对GIT每一条命令将会产生的结果不符合预期。下面我就梳理以下我经常碰到的问题相关的基本概念。1.WorkingDirectory（工作目录）Git的工作目录是保存当前正在工作的文件所在的目录，和workingtree是相同的意思。在这个目录中的文件可能会在切换branch时被GIT删除或者替换。这个目录是个临时目录，临时存储你从GIT库中取出的文件，这些文件一直会被保存，直到下次提交。2.GITDirectory（GIT库目录）项目的所有历史提交都被保存在了GIT库目录中，只要你不作回滚操作，它应该不会丢失。3.GITIndex（Git索引）Gitindex可以看作是工作目录和Git库目录之间的暂存区，和stagingarea是相同的意思。可以使用Gitindex构建一组你准备一起提交的改变。GitIndex和GitStagingarea是同一个意思，都是指已经被add的但尚未commit的那些内容所在的区域。最简单的查看目前什么内容在index中的方法是使用gitstatus命令。o命令中”Changestobecommitted“中所列的内容是在Index中的内容，commit之后进入GitDirectory。o命令中“Changedbutnotupdated”中所列的内容是在WorkingDirectory中的内容，add之后将进入Index。o命令中“Untrackedfiles”中所列的内容是尚未被Git跟踪的内容，add之后进入I