一直在用git版本控制，一直没时间总结，今天终于忙中偷闲总结一下git命令：

git config --global user.email “邮箱名”：绑定GitHub邮箱

git config --global user.name “Github名”：绑定GitHub

git init：初始化一个空的git仓库

git status：检查仓库中的文件状态

git add：添加文件到暂存区

git commit -m “备注信息”：提交到版本库并记录提交信息

git log：查看git日志

git log --pretty=oneline：简化日志信息

git log --graph --pretty=oneline --abbrev-commit 查看日志信息（暂时不知跟上面有什么区别）

git checkout – 文件名：撤销对本地文件的更改（未add时）

git reset HEAD 文件名：撤销对暂存区的修改（add后）（相当于撤销add操作）

git reset --hard HEAD^：回退版本信息

（HEAD^：一个版本 HEAD~50 五十个版本）

git reset --hard 标识符：恢复到标识符版本

git rm 文件名：删除仓库中的文件

git clone GitHub仓库地址：将远程的仓库下载到本地

git push origin master：将本地仓库的内容与远程仓库同步 推过去

git pull origin master：拉取远程仓库的代码到本地，使本地与远程仓库的代码同步 拉过来

git remote add origin 仓库地址：将本地仓库同步（连接）到远程仓库

git push -u origin master：将本地仓库的内容推送到远程仓库中

（-u参数，Git会把本地的master分支与远程的master分支关联起来）

git  branch 分支名：创建新分支

git checkout 分支名：切换到分支

git checkout -b 分支名：创建并切换分支

git branch：查看分支

git branch -D(d高版本小写也可以) 分支名：删除分支

git push origin本地分支名:远程分支名：将分支推送到远程仓库

（如果没有冒号那么本地分支名将会与远程分支名相同）

 

2015年02月26日 13:59:11

阅读数：81047

转：http://blog.csdn.net/wangjia55/article/details/8818845

 

在使用git来进行版本控制时，为了得一个项目的拷贝(copy),我们需要知道这个项目仓库的地址(Git URL). Git能在许多协议下使用，所以Git URL可能以ssh://, http(s)://, git://,或是只是以一个用户名（git 会认为这是一个ssh 地址）为前辍. 

有些仓库可以通过不只一种协议来访问，例如，Git本身的源代码你既可以用 git:// 协议来访问：

git clone git://git.kernel.org/pub/scm/git/git.git

也可以通过http 协议来访问:

git clone http://www.kernel.org/pub/scm/git/git.git

git://协议较为快速和有效,但是有时必须使用http协议,比如你公司的防火墙阻止了你的非http访问请求.如果你执行了上面两行命令中的任意一个,你会看到一个新目录: 'git',它包含有所的Git源代码和历史记录.

   在默认情况下，Git会把"Git URL"里最后一级目录名的'.git'的后辍去掉,做为新克隆(clone)项目的目录名: (例如. git clone http://git.kernel.org/linux/kernel/git/torvalds/linux-2.6.git 会建立一个目录叫'linux-2.6')

  另外，如果访问一个Git URL需要用法名和密码，可以在Git URL前加上用户名，并在它们之间加上@符合以表示分割，然后执行git clone命令，git会提示你输入密码。

示例

git clone robin.hu@http://www.kernel.org/pub/scm/git/git.git

这样将以作为robin.hu用户名访问http://www.kernel.org/pub/scm/git/git.git，然后按回车键执行git clone命令，git会提示你输入密码。

另外，我们可以通过-b <name>来指定要克隆的分支名，比如

$ git clone -b master2 ../server .

表示克隆名为master2的这个分支，如果省略-b <name>表示克隆master分支。

 

GIT URLS

In general, URLs contain information about the transport protocol, the address of the remote server, and the path to the repository. Depending on the transport protocol, some of this information may be absent.

Git natively supports ssh, git, http, https, ftp, ftps, and rsync protocols. The following syntaxes may be used with them:


	
ssh://[user@]host.xz[:port]/path/to/repo.git/
	
	

	
git://host.xz[:port]/path/to/repo.git/
	
	

	
http[s]://host.xz[:port]/path/to/repo.git/
	
	

	
ftp[s]://host.xz[:port]/path/to/repo.git/
	
	

	
rsync://host.xz/path/to/repo.git/
	
An alternative scp-like syntax may also be used with the ssh protocol:


	
[user@]host.xz:path/to/repo.git/
	
The ssh and git protocols additionally support ~username expansion:


	
ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
	
	

	
git://host.xz[:port]/~[user]/path/to/repo.git/
	
	

	
[user@]host.xz:/~[user]/path/to/repo.git/
	
For local repositories, also supported by git natively, the following syntaxes may be used:


	
/path/to/repo.git/
	
	

	
file:///path/to/repo.git/

	
 

	
Examples

	

		
Clone from upstream:

		
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 $ make
		
		

		
Make a local clone that borrows from the current directory, without checking things out:

		
$ git clone -l -s -n . ../copy $ cd ../copy $ git show-branch
		
		

		
Clone from upstream while borrowing from an existing local directory:

		
$ git clone --reference my2.6 \         git://git.kernel.org/pub/scm/.../linux-2.7 \         my2.7 $ cd my2.7
		
		

		
Create a bare repository to publish your changes to the public:

		
$ git clone --bare -l /home/proj/.git /pub/scm/proj.git
		
		

		
Create a repository on the kernel.org machine that borrows from Linus:

		
$ git clone --bare -l -s /pub/scm/.../torvalds/linux-2.6.git \     /pub/scm/.../me/subsys-2.6.git

		
	
 

在公司项目实际开发过程中，大多数情况是先创建远程库，将项目一些内容在远程库中建立，之后员工们将远程库中内容clone到各自的本地GIT仓库中通过协同努力共同开发项目！所以这篇博客就简单介绍了一下如何将GIT远程库clone一份到本地!

    首先我们登录到自己的github网站，如下图创建一个新的GIT仓库repository起名为CloneRapTest，在创建时勾选Initialize this repository with a README，这样创建此仓库后会默认创建一个README.md文件在仓库中。

         

    然后打开Git-Bash工具，进入到某个cd目录下，想要将远程库clone到哪就进入到哪个cd目录下，这里我们进入到/e/gittest目录下，（/e/gittest目录本身是一个本地仓库的工作目录，这里是为了测试可不可以clone一个远程库到一个本地仓库目录下）接着使用命令git clone 后面跟相应远程库地址即可，如下图。

 

                

 

    需要说明的是远程库地址不必自己编辑也最好不要自己编辑，容易输入错误，只需要在github中找到相应远程库点击后在右上角如下图部分找到Clone or download,点击下拉按钮就可以显示此远程库的地址了

 

         

 

    点击Use HTTPs，就可以显示此远程库对应的支持http协议的地址，但我们默认使用ssh支持的git原生协议，速度较快，且不必每次推送都使用命令！

 

                

    回到Git-Bash，当我们输入git clone命令点击回车之后，就开始从远程库clone到本地库了，这期间有时会提示你The authenticity of host 'github.com (192.30.253.113)' can't be established，即github.com存在可靠性问题，然后提示你输入yes继续。这里我们直接输入yes，之后clone工作就完成了，去到/e/gittest目录下会发现多出了一个CloneRepTest文件夹，且文件夹中有一个REAEME.md文件，表名远程库已经成功clone了一份到本地！

            

原文链接：http://www.yyztech.com/archives/45/

首先来回顾一下，在上一篇git系列文章中，我们讲了如何创建本地git仓库并把文件push到远程仓库，也就是先有本地仓库，后有远程仓库。那么，这次我们来讲一个新的玩法，就是先有远程仓库，后有本地仓库，即把远程仓库“克隆（clone）”到本地。

假设现在你的团队其他成员已经在git上建好了仓库，并且也push过代码,这个远程git仓库还叫“StudyGit”，有两个文件:a.txt和README.md,现在，您也要开始贡献代码了，那么，您首先需要把团队其他成员提交的所有东西都拉取到你的本地目录，这个时候就会用到“clone”命令了：

git clone git@github.com:onlyanyz/StudyGit.git


只要执行这句指令，就可以把远程仓库的所有东西都拉取到本地工作目录了，当然生成的本地目录名和远程仓库名字是一样的。

如果您现在查看下当前本地git仓库的状态，如下：


 


	
yanyaozhen@macbookpro:~/Coding/StudyGit$ git status
	
	

	
On branch master
	
	

	
Your branch is up-to-date with 'origin/master'.
	
	

	
nothing to commit, working directory clean
	
命令回显表示，我的本地分支已经更新为最新的远程master分支了。此后，我们就可以按照“git快速入门之一”这篇文章所述进行添加代码并提交了。

现在，让我们再看下刚才clone到本地的git项目，现在有两个文件，如下：


 


	
yanyaozhen@macbookpro:~/Coding/StudyGit$ ll
	
	

	
total 16
	
	

	
-rw-r--r-- 1 yanyaozhen staff 21B 11 19 00:04 README.md
	
	

	
-rw-r--r-- 1 yanyaozhen staff 4B 11 19 00:04 a.txt
	
接下来，假如A同学在github上的这个仓库中又新增了一个文件b.txt,那现在github远程仓库中就有三个文件（注意，现在本地仓库中的文件就已经与远程仓库不同了）。

接下来，我们在本地继续我们的开发工作，假如新建了一个文件“c.txt”，现在，让我们来把"c.txt"文件加入暂存区，然后commit到本地仓库，这时，我们想把刚才的工作成果再push到远程，执行如下：


 


	
yanyaozhen@macbookpro:~/Coding/StudyGit$ git push origin master
	
	

	
To git@github.com:onlyanyz/StudyGit.git
	
	

	
! [rejected] master -> master (fetch first)
	
	

	
error: failed to push some refs to 'git@github.com:onlyanyz/StudyGit.git'
	
	

	
hint: Updates were rejected because the remote contains work that you do
	
	

	
hint: not have locally. This is usually caused by another repository pushing
	
	

	
hint: to the same ref. You may want to first integrate the remote changes
	
	

	
hint: (e.g., 'git pull ...') before pushing again.
	
	

	
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
	
阿欧，报错了，懂点英文的同学可以从提示信息看出问题所在，因为我们的远程已经有更新了，我们在push到远程的时候，必须先把远程的改动拉到本地合并起来，才能再次提交我的修改。所以，以下的命令就出场了：

$ git fetch origin master


该指令意思是从远程origin仓库的master主分支更新最新的版本到origin/master分支上。

然后我们比对下当前本地master分支和origin/master分支的区别：

$ git log -p master..origin/master


执行的回显结果会详细列出这两个分支的差异。

然后，我们需要把origin/master分支上的内容合并到本地master分支：

git merge origin/master


执行该指令后，可能会要求输入合并的理由，填写后，我们就合并成功了。这个时候，我们就可以再次push了：


 


	
yanyaozhen@macbookpro:~/Coding/StudyGit$ git push origin master
	
	

	
Counting objects: 5, done.
	
	

	
Delta compression using up to 4 threads.
	
	

	
Compressing objects: 100% (4/4), done.
	
	

	
Writing objects: 100% (5/5), 543 bytes | 0 bytes/s, done.
	
	

	
Total 5 (delta 2), reused 0 (delta 0)
	
	

	
To git@github.com:onlyanyz/StudyGit.git
	
	

	
6b3662f..6036a05 master -> master
	
	
 
表示push成功，现在你可以去github上看到我们在本地新建的b.txt文件啦！

后记：有同学可能查了网上的资料，说“git fetch”和“git merge”指令可以合二为一，叫“git pull”，在此强烈建议大家使用分开的指令，因为“git pull”会直接合并，而不会等你确认，如果一旦合并错了，还是比较麻烦的。宁可慢一点，也别重头再来。

 

 

配置部分：

启动入口：
启动目录需要设置bin目录下的git.exe为启动程序，不是gitcmd.exe
为了能够在任何目录使用git命令，需要在环境变量里面设置git.exe的路径。
配置完使用cmd窗口可以任何目录使用git命令，如果在Android stduio的terminal使用却无法识别，此时重启电脑一下就好了

用于提供自己的名字和email地址
git config --global user.name [name]
git config --global user.email []

保存登陆的用户密码，避免每次都要重新输入
git config --gloable credential.helper store

查看配置信息列表
git config --list

克隆项目
git clone URL

拉取项目变动
git pull res_name

上传更改
git commit -m "上传说明"
git push

撤销上传（版本回退）
git reset --hard HEAD~N (到退N次提交前)
git commit
git push -f （强制传送到远程respostiries）

注意：-f 是一个强制推送的操作，是危险操作！设置倒退N个版本之前，那么在N个版本之前到最新版本的内容会全部消失，若是同时有人想该respostories上传了文件，也会一并消失


直接由本地，上传文件到指定respostories
git init
git remote add res_name URL
git add .
git commit -m "上传说明"
git pull res_name master
git push res_name master

添加文件的追踪
git add file_name
git status (可以看见文件追踪的变动情况)
git commit -m "提交说明" (这一步特别注意，不知道为什么，使用 git commit 是无法生效的，必须按照左边的格式提交)
git push res_name branch_name

Git的学习总结

学习Git的网站为： https://learngitbranching.js.org  闯关形式的学习方法，试用与电脑操作，手机端体验可能不佳

学习过程中会不断的进行提示，演示，然后自己手动实操…很好的学习网站

但是缺点也是有的，所有的一切都是闯关模式，对于想快速学习来说还是不太有好的，所以总结出里面的命令以供学习参考


 网站中Git命令分为 主要 和 远程 两类

主要包括：基础篇、高级篇、移动提交篇、杂项、高级话题 其中又包含若干命令

远程包括： Push & Pull —— Git 远程仓库、 关于 origin 和它的周边 —— Git 远程仓库高级操作

 

基础篇


Git Commit 提交修改

Git 仓库中的提交记录保存的是你的目录下所有文件的快照，就像是把整个目录复制，然后再粘贴一样，但比复制粘贴优雅许多！

Git 希望提交记录尽可能地轻量，因此在你每次进行提交时，它并不会盲目地复制整个目录。条件允许的情况下，它会将当前版本与仓库中的上一个版本进行对比，并把所有的差异打包到一起作为一个提交记录。

Git 还保存了提交的历史记录。这也是为什么大多数提交记录的上面都有父节点的原因 —— 我们会在图示中用箭头来表示这种关系。对于项目组的成员来说，维护提交历史对大家都有好处。

关于提交记录太深入的东西咱们就不再继续探讨了，现在你可以把提交记录看作是项目的快照。提交记录非常轻量，可以快速地在这些提交记录之间切换！



Git Branch 新建分支

Git 的分支也非常轻量。它们只是简单地指向某个提交纪录 —— 仅此而已。所以许多 Git 爱好者传颂：早建分支！多用分支！

这是因为即使创建再多的分支也不会造成储存或内存上的开销，并且按逻辑分解工作到不同的分支要比维护那些特别臃肿的分支简单多了。

在将分支和提交记录结合起来后，我们会看到两者如何协作。现在只要记住使用分支其实就相当于在说：“我想基于这个提交以及它所有的父提交进行新的工作。”



git checkout 切换分支

下面的命令会让我们在提交修改之前先切换到新的分支上

git checkout newImage;



git merge 分支与合并

git merge。在 Git 中合并两个分支时会产生一个特殊的提交记录，它有两个父节点。翻译成自然语言相当于：“我要把这两个父节点本身及它们所有的祖先都包含进来。”



Git Rebase 分支与合并

第二种合并分支的方法是 git rebase。Rebase 实际上就是取出一系列的提交记录，“复制”它们，然后在另外一个地方逐个的放下去。

Rebase 的优势就是可以创造更线性的提交历史，这听上去有些难以理解。如果只允许使用 Rebase 的话，代码库的提交历史将会变得异常清晰。


高级篇


HEAD

示例：

#假设c2是一个节点，切换到c2的时候，HEAD指向也会更改为c2
git checkout c2


我们首先看一下 “HEAD”。 HEAD 是一个对当前检出记录的符号引用 —— 也就是指向你正在其基础上进行工作的提交记录。

HEAD 总是指向当前分支上最近一次提交记录。大多数修改提交树的 Git 命令都是从改变 HEAD 的指向开始的。

HEAD 通常情况下是指向分支名的（如 bugFix）。在你提交时，改变了 bugFix 的状态，这一变化通过 HEAD 变得可见。

如果想看 HEAD 指向，可以通过 cat .git/HEAD 查看， 如果 HEAD 指向的是一个引用，还可以用 git symbolic-ref HEAD 查看它的指向。



相对引用

示例：

#万能语句了，操作的是HEAD,我们可以一直使用 HEAD^ 向上移动【注意：HEAD一定要大写】
git checkout HEAD^
git checkout HEAD~3
#针对知道名称的
git checkout main^
git checkout main~3

通过指定提交记录哈希值的方式在 Git 中移动不太方便。在实际应用时，并没有漂亮的可视化提交树供你参考，所以你就不得不用 git log 来查查看提交记录的哈希值。

并且哈希值在真实的 Git 世界中也会更长（译者注：基于 SHA-1，共 40 位）。例如介绍中的提交记录的哈希值可能是 fed2da64c0efc5293610bdd892f82a58e8cbc5d8。舌头都快打结了吧...

比较令人欣慰的是，Git 对哈希的处理很智能。你只需要提供能够唯一标识提交记录的前几个字符即可。因此我可以仅输入fed2 而不是上面的一长串字符。

使用相对引用的话，你就可以从一个易于记忆的地方（比如 bugFix 分支或 HEAD）开始计算。

相对引用非常给力，这里我介绍两个简单的用法：

使用 ^ 向上移动 1 个提交记录
	
使用 ~<num> 向上移动多个提交记录，如 ~3



强制修改分支位置

你现在是相对引用的专家了，现在用它来做点实际事情。

我使用相对引用最多的就是移动分支。可以直接使用 -f 选项让分支指向另一个提交。例如:

git branch -f main HEAD~3

上面的命令会将 main 分支强制指向 HEAD 的第 3 级父提交。相对引用为我们提供了一种简洁的引用提交记录方式， 而 -f 则容许我们将分支强制移动到那个位置。



撤销变更

在 Git 里撤销变更的方法很多。和提交一样，撤销变更由底层部分（暂存区的独立文件或者片段）和上层部分（变更到底是通过哪种方式被撤销的）组成。我们这个应用主要关注的是后者。

主要有两种方法用来撤销变更 —— 一是 git reset，还有就是 git revert。接下来咱们逐个进行讲解。

Git Reset

git reset 通过把分支记录回退几个提交记录来实现撤销改动。你可以将这想象成“改写历史”。git reset 向上移动分支，原来指向的提交记录就跟从来没有提交过一样。

Git Revert

虽然在你的本地分支中使用 git reset 很方便，但是这种“改写历史”的方法对大家一起使用的远程分支是无效的哦！

为了撤销更改并分享给别人，我们需要使用 git revert。revert 之后就可以把你的更改推送到远程仓库


移动提交记录


Git Cherry-pick

本系列的第一个命令是 git cherry-pick, 命令形式为:

git cherry-pick <提交号>...
如果你想将一些提交复制到当前所在的位置（HEAD）下面的话， Cherry-pick 是最直接的方式了。我个人非常喜欢 cherry-pick，因为它特别简单。

答案：    git cherry-pick c3 c4 c7



交互式的 rebase

当你知道你所需要的提交记录（并且还知道这些提交记录的哈希值）时, 用 cherry-pick 再好不过了 —— 没有比这更简单的方式了。

但是如果你不清楚你想要的提交记录的哈希值呢? 幸好 Git 帮你想到了这一点, 我们可以利用交互式的 rebase —— 如果你想从一系列的提交记录中找到想要的记录, 这就是最好的方法了

交互式 rebase 指的是使用带参数 --interactive 的 rebase 命令, 简写为 -i

如果你在命令后增加了这个选项, Git 会打开一个 UI 界面并列出将要被复制到目标分支的备选提交记录，它还会显示每个提交记录的哈希值和提交说明，提交说明有助于你理解这个提交进行了哪些更改。

在实际使用时，所谓的 UI 窗口一般会在文本编辑器 —— 如 Vim —— 中打开一个文件

当 rebase UI界面打开时, 你能做3件事:

调整提交记录的顺序（通过鼠标拖放来完成）
	
删除你不想要的提交（通过切换 pick 的状态来完成，关闭就意味着你不想要这个提交记录）
	
合并提交。简而言之，它允许你把多个提交记录合并成一个。
答案：    git rebase -i HEAD~4


杂项 


本地栈式提交

来看一个在开发中经常会遇到的情况：我正在解决某个特别棘手的 Bug，为了便于调试而在代码中添加了一些调试命令并向控制台打印了一些信息。

这些调试和打印语句都在它们各自的提交记录里。最后我终于找到了造成这个 Bug 的根本原因，解决掉以后觉得沾沾自喜！

最后就差把 bugFix 分支里的工作合并回 main 分支了。你可以选择通过 fast-forward 快速合并到 main 分支上，但这样的话 main 分支就会包含我这些调试语句了。你肯定不想这样，应该还有更好的方式……

实际我们只要让 Git 复制解决问题的那一个提交记录就可以了。跟之前我们在“整理提交记录”中学到的一样，我们可以使用

git rebase -i
	
git cherry-pick
来达到目的。

答案：    git rebase -i HEAD~3
         ##删除两次打印日志的提交
          git branch -f main bugFix