git使用杂记

前言

作为一个开发者，如果现在还不知道git或者还不会使用git，那么你应该好好的反省。自己去好好看一遍的入门介绍吧。今天只是对自己在日常中使用git的一些常用命令的介绍与自己认为不错且能提高我们办公效率的命令。内容可能会有点杂乱，但绝对都是经典的命令，在此记下笔记，也希望能帮助来赏脸关顾的你们。

区域

在这之前，来介绍一下git的三个区域

  • 工作区(working directory)
  • 暂存区(stage index)
  • 本地历史区(history)

通过一张图就能简洁易懂的明白它们之间的转化。

clone

先从clone命令来介绍，使用过git的都知道它。git colne命令拉取远程仓库到本地。但当我们要拉取到指定的文件夹下时，你可能会直接mkdir，其实无需如此，一条命令就能搞定git clone 远程仓库 文件名，就是如此简单。

rm

我们在工作中可能会遇到这么一种情况，使用git add .直接将工作区的所有修改的文件加入到暂存区了，但是后面发现有一个文件先不要加进去，此时我们就可以使用如下命令就可以将该文件退回到工作区中。



    

  1. git rm --cached <file> 
    2. 



stash


有这么一种情况，当你正在开发中时，有一个线上的紧急bug需要修复，此时开发中的功能又没有完成你不想提交，此时你可以使用git stash将工作区的文件都存放起来。这时你就可以放心的去切分支修复bug，修复完之后执行git stash pop可以将先前存放的取出，当然也有一些其他的相关命令例如：git stash list查看存放的记录,git stash drop丢弃存放的记录。


tag


可能在开发中我们要打标签git tag tagName，并且要将相应的标签推送到远程仓库中，此时可以使用如下命令进行推送。




    

  1. git push --tags tagName 
    2. 



amend


当你commit以后，发现有一个文件没有加进上次的commit中，或者又修改了一些文件。此时你并不想增加新的commit信息，只是想将其加入到上次的commit中。这时你就可以使用




    

  1. git commit --amend <file> 
    2. 



将暂存区的文件加入其中,并且你也可以修改此时的commit信息。


reset


reset也能实现前面的rm的效果，可以使用如下命令来替代前面的git rm --cached <file>命令




    

  1. git reset HEAD <file> 
    2. 



但reset用途更广，结合soft参数可以回撤到任意的commit节点进行操作




    

  1. git reset --soft index 
    2. 



执行该命令之后，就回到index处，工作区不变、暂存区回到当时的index处。另外还有一个hard参数。




    

  1. git reset --hard index 
    2. 



与soft可以说对立，它的效果就在于工作区与暂存区的不同，它会清空这两个区。


rebase


对于rebase是重定向的意思，如果你当前的分支与远程的分支commit信息存在差异时，会提醒你此时不能进行push，必须先将远程的commit信息拉去到本地来，才能进行提交。对于这种情况就可以使用rebase命令了。如下当前处在develop分支




此时应该先执行rebase命令




    

  1. git fetch 
    2. 

  2. git rebase origin/master  
    3. 



执行完之后，最后再push到远程master




    

  1. git push origin master 
    2. 



最终各个分支的情况就是上图的效果了。如果觉得命令多难记，这里也可用一条命令来完成上面的效果




    

  1. git pull --rebase origin master 
    2. 



这是rebase的简单运用，也是常见的命令了。下面介绍rebase的一个可选参数--onto。


--onto


使用场景：开发过程中我们都会创建不同的分支进行开发不同的功能，当你在分支A上创建了新分支B进行开发功能并且也提交了一些commit时，此时你发现原来A分支上有错误的commit，如果要rebase到master上时，不能将这个错误的commit也附带上。这个时候就该--onto大显神通了。




当前处在B分支，要得到上面的结果，只需执行如下命令




    

  1. git rebase --onto master <b的commit hash code> B 
    2. 



这个不仅可以针对不同的分支，也能作用于同一个分支上。所以针对上面的情况可以只对分支B进行操作，等价命令如下：




    

  1. git rebase --onto <a的commit hash code> <b的commit hash code> B 
    2. 



--interactive


当我们要修改commit信息的名称时，如果要修改的commit处在第一个时，可以使用




    

  1. git commit --amend 
    2. 



如果不是第一个时，我们就要使用到rebase的--interactive可选参数了，可以简写为-i。




    

  1. git rebase -i <commit hash code> 
    2. 



参数后面的commit hash code为需要修改的commit的前一个。执行之后就会出现如下类似的信息：




    

  1. pick 137cf0a First coommit 
    2. 

  2. pick 163dc38 Second commit 
    3. 

  3.  
    4. 

  4. # Rebase f9aee6e..163dc38 onto f9aee6e (2 command(s)) 
    5. 

  5. # 
    6. 

  6. # Commands: 
    7. 

  7. # p, pick = use commit 
    8. 

  8. # r, reword = use commit, but edit the commit message 
    9. 

  9. # e, edit = use commit, but stop for amending 
    10. 

  10. # s, squash = use commit, but meld into previous commit 
    11. 

  11. # f, fixup = like "squash", but discard this commit's log message 
    12. 

  12. # x, exec = run command (the rest of the line) using shell 
    13. 

  13. # 
    14. 

  14. # These lines can be re-ordered; they are executed from top to bottom. 
    15. 

  15. # 
    16. 

  16. # If you remove a line here THAT COMMIT WILL BE LOST. 
    17. 

  17. # 
    18. 

  18. # However, if you remove everything, the rebase will be aborted. 
    19. 

  19. # 
    20. 

  20. # Note that empty commits are commented out  
    21. 



根据提示我们可以有6个可选择的操作。相信提示已经说的很明显了，对于我们这种要修改First coommit的情况，需要使用r。




    

  1. r 137cf0a First commit 
    2. 

  2. pick 163dc38 Second commit  
    3. 



执行之后会跳到修该First coomit的界面，进行修改即可。




    

  1. First commit 
    2. 

  2.  
    3. 

  3. # Please enter the commit message for your changes. Lines starting 
    4. 

  4. # with '#' will be ignored, and an empty message aborts the commit. 
    5. 

  5. # 
    6. 

  6. # Date:      Thu Jan 26 23:07:10 2017 +0800 
    7. 

  7. # 
    8. 

  8. # rebase in progress; onto f9aee6e 
    9. 

  9. # You are currently editing a commit while rebasing branch 'master' on 'f9aee6e'. 
    10. 

  10. # 
    11. 

  11. # Changes to be committed: 
    12. 

  12. #       new file:   file1  
    13. 



至于其他的操作项，有兴趣的可以自己去尝试一下。例如s操作就可以用来合并commit。


branch


相信branch都很熟悉，我这里要说的是他的另一种可能会用到的情况。场景是这样的：如果在你进行创建新的分支时，并不想从当前的commit信息节点进行创建分支。




要实现如上效果只需在创建分支时在后面再添加额外的参数，该参数就是你所需调到的commit节点的hash code




    

  1. git branch new_branch <commit hash code> 
    2. 



push


这里提一下push的--set-upstream,它的效果是设置上游分支，当我们将远程不存在的本地分支推送到远程时，如果不在推送的分支上，我们一般会使用如下命令进行推送。




    

  1. git checkout push_branch 
    2. 

  2. git push origin push_branch  
    3. 



下面是简洁的方法，使用该参数无需切换分支，可以直接使用如下命令进行推送。




    

  1. git push --set-upstream origin push_branch 
    2. 



cherry-pick


这个命令的场景是：当你所在的分支没用，你要删除它，但其中的一个commit你还是想推送到远程master上。




将分支切换到master，执行以下命令：




    

  1. git cherry-pick <b的 commit hash code> 
    2. 



merge


我们所熟知的是使用merge来进行分支的合并，每次使用merge时都会自动将副分支合并成一个commit进行推送到主分支上，那么如果我不想它自动推送到主分支上时(可能我还需要进行修改)，这时就可以使用--squash操作




    

  1. git merge --squash dev_branch 
    2. 



执行完以上命令后，我们就可以在暂存区看到一个还未提交的文件状态。


reflog


当我们切分支太频繁了之后，可能会忘了一些分支是从哪个分支切过来的，此时可以使用如下命令查看：




    

  1. git reflog  
    2. 





    

  1. 894a16d HEAD@{0}: commit: commit another todo 
    2. 

  2. 6876e5b HEAD@{1}: checkout: moving from solve_world_hunger to kill_the_batman 
    3. 

  3. 324336a HEAD@{2}: commit: commit todo 
    4. 

  4. 6876e5b HEAD@{3}: checkout: moving from blowup_sun_for_ransom to solve_world_hunger 
    5. 

  5. 6876e5b HEAD@{4}: checkout: moving from kill_the_batman to blowup_sun_for_ransom 
    6. 

  6. 6876e5b HEAD@{5}: checkout: moving from cure_common_cold to kill_the_batman 
    7. 

  7. 6876e5b HEAD@{6}: commit (initial): initial commit  
    8. 



这样我们就可以看到所用的操作历史了。这样如果我们使用git reset命令不小心删除了需要的东西。可以通过此来查找到删除操作的hash code，之后就可以通过如下命令进行恢复。




    

  1. git checkout <hash code> 
    2. 



目前想到的就这些了，希望能有所帮助


作者：idisfkj


来源：51CTO
				


				
时间： 2024-07-29 20:09:58

		
		


		


	

	
	

		


		
git使用杂记的相关文章


								

		

			

                debian安装git服务器——gitosis(sina博客移入)
			

		

		

									

				前段时间一直在用google code,大概了解了svn的使用方法(其实也没有怎么了解,因为使用了eclipse的svn插件,没有手动使用svn命令过).想在家里的龙芯上也弄个版本管理软件,这样既可以控制平时写的软件的版本,同时也实现了对这些程序的备份. 以前在自己的电脑上搭建过svn服务器,所以这次想尝试一下搭建git的服务器.git是分布式的版本控制软件,因此本身没有很强的服务器概念.因此选择了gitosis这个软件. 安装这个软件非常方便,直接用apt-get就可以了,很久没有刷新软件源了			

		

	

				

		

			

                【转载】Jenkins + Git + Maven + tomcat集成环境搭建
			

		

		

									

				本文转载自http://shift-alt-ctrl.iteye.com/blog/2208786   折腾了好几天,终于吧Jenkins + Git + Maven + tomcat集成环境搭建起来了,最终主要实现"自动构建.部署"web应用.   1.安装环境     操作系统:Centos 6.5     JDK:1.7.x     Maven:3.1.x     Git: 1.7.1,自建GitLab平台     tomcat:7.x       上述宿主机器2台:192.16			

		

	

				

		

			

                Git GUI 中文乱码问题
			

		

		

									

				使用 Git GUI 时,中文显示乱码 鼠标右键内容显示区, 在菜单中选择 Encoding -> UTF-8 问题解决			

		

	

				

		

			

                CentOS下Git的服务器版安装和使用
			

		

		

									

				Git分布式版本控制系统: Git的使用体验,早已习惯了svn [集中式] 代码管理的吾,第一次接触分布式的git的时候,感觉很难使用,煎熬了一段时间,整个项目组,也是花费了很大的代价,就是出现代码被覆盖很多次,代码都不敢提交了! 记得在中国民航的时候,由于服务器硬件搬家过程中损坏,导致整个系统和代码全部丢失,不是很重要所以没有去做数据恢复,svn就挂了. 记得在金葵花的时候,由于svn服务器端口被抢占,导致没有启动,早上经理不在,没权限,所有,大家闲置了一早上. 使用了一段时间的git,使用过			

		

	

				

		

			

                git教程（二）--安装和配置git
			

		

		

									

				转载:http://blog.csdn.net/gatieme/article/details/50586476 前言 GIT跟SVN一样有自己的集中式版本库或服务器.但,GIT更倾向于被使用于分布式模式,也就是每个开发人员从中心版本库/服务器上chect out代码后会在自己的机器上克隆一个自己的版本库.可以这样说,如果你被困在一个不能连接网络的地方时,就像在飞机上,地下室,电梯里等,你仍然能够提交文件,查看历史版本记录,创建项目分支等.对一些人来说,这好像没多大用处,但当你突然遇到没有网络的			

		

	

				

		

			

                git分支原理命令图文解析
			

		

		

									

				本地分支解析 git 通过可变指针来实现对提交数据的历史版本的控制,每当我们提交新的更新,当前分支(设为master)则指向最后一个提交更新A,而最后一个提交对象则存在一个指针指向前一次的提交更新Q.如果我们创建一个新的分支,child,它和master共同指向A,这时,如果我们向child分支提交更新B,我们会发现child指向B,而master依然指向A.无论我们在child分支进行了任何开发,只要回到master分支,就能恢复到更新A的数据状态了. 在图片里,我们还注意到有一个head指针			

		

	

				

		

			

                git笔记：通过给grunt-inline打tag看tag操作
			

		

		

									

				晚上review了下grunt-inline的issues,看到有个兄弟pull request,修正了0.3.0版本的一个bug.于是就merge了下,然后发布了0.3.1版本(这里). npm publish后,突然想到一个问题,发布了这么多个版本了,但好像都没有打过tag,这个不利于版本回溯以及bug trace.svn版本管理里有tag的概念,git里八九不离十也有,虽然还没用过.就简单百度了下,打完tag后顺便做下笔记: 查看tag git tag 比如我在grunt-inline的项			

		

	

				

		

			

                Git学习备忘
			

		

		

									

				    本文参考廖雪峰写的精彩的git学习文档,大家可以直接去官网看原版,我这里只是便于自己记录梳理 原版地址:http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000     ubuntu下可以直接sudo apt-get install git来安装git.如果是mac,Xcode自带git,但是版本可能比较低.你可以到git官网下载最新的git src或较旧的dmg文件到本地安装.安			

		

	

				

		

			

                vs2013 git 没有冲突也提示冲突预防 导致无法同步
			

		

		

									

				问题描述 vs2013 git 没有冲突也提示冲突预防 导致无法同步 我在使用git同步代码的时候,提示了如图的错误 但是我确定没有做过任何修改 而且git也没有提示任何冲突需要解决,这个问题最近在多台机器上发生,实在不知道是什么原因 解决方案 提示冲突肯定是有冲突的,你需要手动解决一下冲突然后同步. 解决方案二: 看看是否提交的分支与远程分支有冲突,因为你并不一定就是提交的你本地所看到的分支 解决方案三: 先git checkout master到主分支,然后git pull等看是否有merg