git常用操作汇总结

仓库的创建    在新建的文件夹里面执行 git init命令
 
文件的添加      在新建的文件夹下新建文件,然后执行git add readme.txt
 
仓库的提交   在仓库文件夹下执行 git commit (-m “注释内容”);    
 
显示当前文件夹下的隐藏文件使用。 Ls -ah 
 
查看状态    git status (只能看到那个文件被修改,无法看到具体的修改内容)
 
查看具体都修改了什么  (可以看到详细的修改行数和内容)  git diff
 
修改过文件之后。需要先执行 git add. 然后执行git commmit
 
 
在Git中,用HEAD表示当前版本,也就是最新的提交3628164...882e1e0(注意我的提交ID和你的肯定不一样),上一个版本就是HEAD^,上上一个版本就是HEAD^^,当然往上100个版本写100个^比较容易数不过来,所以写成HEAD~100
 
在回退之前需要知道当前的版本号(很长的一串字符) 使用指令 git log. 显示历史信息
版本回退指令。git reset --hard HEAD^( head^这个是回退到的位置 ,这个位置也可以填写版本号)
git reflog 来显示历史命令
 
 
当你对自己电脑上的文件进行修改,执行git add操作时
当执行git commit操作时
变成了
注:如果每一次的操作只有执行了add操作,commit操作才有效 
 
 
 
 
 

场景1:当你改乱了工作区某个文件的内容,想直接丢弃工作区的修改时,用命令git checkout -- file。(就是把工作区替换成版本库里面的内容,修改,删除,添加都可以恢复)

场景2:当你不但改乱了工作区某个文件的内容,还添加到了暂存区时,想丢弃修改,分两步,第一步用命令git reset HEAD file,就回到了场景1,第二步按场景1操作。

场景3:已经提交了不合适的修改到版本库时,想要撤销本次提交,参考版本回退一节,不过前提是没有推送到远程库。

 
 
 
如果在git commit 或者git add之后又做了修改,那么可以把本机的内容回退到最后一次
Git commit或者git add时的样子
使用git checkout --filename(注意—)
 
git checkout 是切换分至的命令。
用命令git reset HEAD file可以把暂存区的修改撤销掉(unstage),重新放回工作区,
然后再撤销工作区内容,就全部撤销了。
 
 
 
 
 
删除自己工作区的文件,就是Linux自带的.   rm  filename
这个时候的工作区和缓存区(或者版本库)都不一样了
这个时候使用git checkout— filename(他的作用就是让工作区内容变成和最后一次提交的内容一致)  
 
删除版本库中的文件  Git rm —filename
 
如果想删除暂存区的内容,那么可以把它commit提交到版本库再删除
 
 
 
 
git连接GitHub过程 :

第1步:创建SSH Key。在用户主目录下,看看有没有.ssh目录,如果有,再看看这个目录下有没有id_rsaid_rsa.pub这两个文件,如果已经有了,可直接跳到下一步。如果没有,打开Shell(Windows下打开Git Bash),创建SSH Key:

$ ssh-keygen -t rsa -C "youremail@example.com"
 

你需要把邮件地址换成你自己的邮件地址,然后一路回车,使用默认值即可,由于这个Key也不是用于军事目的,所以也无需设置密码。

如果一切顺利的话,可以在用户主目录里找到.ssh目录,里面有id_rsaid_rsa.pub两个文件,这两个就是SSH Key的秘钥对,id_rsa是私钥,不能泄露出去,id_rsa.pub是公钥,可以放心地告诉任何人。

第2步:登陆GitHub,打开“Account settings”,“SSH Keys”页面:

然后,点“Add SSH Key”,填上任意Title,在Key文本框里粘贴id_rsa.pub文件的内容:

点“Add Key”,你就应该看到已经添加的Key:

为什么GitHub需要SSH Key呢?因为GitHub需要识别出你推送的提交确实是你推送的,而不是别人冒充的,而Git支持SSH协议,所以,GitHub只要知道了你的公钥,就可以确认只有你自己才能推送。

在本地的learngit仓库下运行命令:

$ git remote add origin git@github.com:michaelliao/learngit.git
后面的是git仓库的地址。
 
 
本地库推送到远程库指令
$ git push -u origin master

把本地库的内容推送到远程,用git push命令,实际上是把当前分支master推送到远程。

由于远程库是空的,我们第一次推送master分支时,加上了-u参数,Git不但会把本地的master分支内容推送的远程新的master分支,还会把本地的master分支和远程的master分支关联起来,在以后的推送或者拉取时就可以简化命令。

此后,每次本地提交后,只要有必要,就可以使用命令git push origin master推送最新修改;


从远程库克隆。 git clone gitaddress
git支持ssh协议,也支持https协议,不过ssh协议更快 
 
 
 
这种情况时快速合并。
 
 
 
 
 
 
 
 
 
 
 
 
 
这种情况就是存在冲突的情况。
 
这个时候执行git merge dev的时候,相当于把dev合并到master上,这个时候冲突的提示只会在master上,修改然后提交,dev是不会变的。以为已经合并,并且解决冲突了,所以就可以删除dev了。
git log --graph命令可以看到分支合并图。
 
 
 
 
 
 
 
 
合并分支时,加上--no-ff参数就可以用普通模式合并,合并后的历史有分支,能看出来曾经做过合并,而fast forward合并就看不出来曾经做过合并。
fast forward模式的话就是这样
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 当你当前的工作区正在完成一项工作,可是工作只进行了一半,暂时还没法提交到服务器端,可是你现在急需使用你的工作区来干别的事情,这个时候 stash就发挥了作用
 
 
$ git stash
用来保存现场,就是把正在工作的分枝对应的工作区清零。执行完该命令之后,工作区就干净了。这个时候想切换其他分枝都可以。
其他忙完了,又切回刚刚的分枝,可是工作区还是空的,这个时候要恢复现场。

一是用git stash apply恢复,但是恢复后,stash内容并不删除,你需要用git stash drop来删除;

另一种方式是用git stash pop,恢复的同时把stash内容也删了:

 
 
 
 
 
 
 
 
 
推送:
 
 
从远程clone的代码,只克隆了master分枝,  要克隆其他分枝,需要另行克隆
 克隆非主分枝:
$ git checkout -b dev origin/dev
Dev表示的是分枝名,远程服务器和本地服务器的分枝名必须一样
 
推送分枝的时候git push origin(远程服务器名) dev(本地需要提交熬的分枝) 
 
 
 
 
 
 
 
 
 
当push的时候发现你当初修改的文件已经被修改了,那么这个时候push就会冲突,
只能先git pull命令,把服务器上的版本拉下来,和本地的冲突修改之后再commit
 
可是git pull会出错,因为没有设置从哪pull到哪
这个命令说明了从哪到哪pull,这时再pull,就可以了
 
 
 
 
 
 
 
 
 
 

首先,我们创建dev分支,然后切换到dev分支:

$ git checkout -b dev
Switched to a new branch 'dev'

git checkout命令加上-b参数表示创建并切换,相当于以下两条命令:

$ git branch dev//新建分枝
$ git checkout dev//切换分枝
Switched to branch dev'
git checkout -b local-branchname origin/remote_branchname  就可以将远程分支映射到本地命名为local-branchname  的一分支。

然后,用git branch命令查看当前分支:

$ git branch
* dev
  master

git branch命令会列出所有分支,当前分支前面会标一个*号。

git merge命令用于合并指定分支到当前分支。
 
 

查看分支:git branch

创建分支:git branch <name>

切换分支:git checkout <name>

创建+切换分支:git checkout -b <name>

合并某分支到当前分支:git merge <name>

删除分支:git branch -d <name>

如果该分枝还未被合并,要想删除它那么就要使用指令 git branch -D <name>
 
 
 
 
 
 
 

#删除本地的某个分支

git branch -D hongchangfirst

全部清除本地修改 git checkout .

全部add 。    git add -A

原文地址:https://www.cnblogs.com/tobemaster/p/6551618.html