常用 Git 指令

 

初始化 git 项目 （生成.git文件）

git init

从远程服务端克隆仓库（如github）

git clone 'github仓库地址'

提交改动

git add 文件名 （添加文件到暂存区）

git add . (.表示全部文件)

git rm 文件名 （删除文件）

git  status （查看暂存区文件，有刚才添加的改动文件）

git commit -m '提交信息' (提交到本地仓库，此时git status查看缓存区为空)

git push (推送到远程仓库，已有远程关联分支)

git push origin/远程分支名称 （推送到远程的指定分支）

分支相关

git checkout 分支名称 （切换当前工作分支）

git branch 新分支名称（创建新的分支）

git checkout -b 新分支名称（创建新分支，并且切换当前工作分支到新分支）

git fetch （从远程抓取，更新当前分支）

git pull （从远程拉取，更新当前分支，相当于git fetch后再做一个git merge）

git pull 远程分支（从远程指定分支拉取，将本地分支与远程分支关联起来）

git merge 分支名称 （合并指定分支到当前分支）

git branch -d 分支名称（删除此分支）

git push orgin --delete 分支名称 （删除远程分支）

其它操作

git branch （列出所有本地分支）

git branch -r （列出所有远程分支）

git branch -a（列表本地和远程的所有分支）

 

git reset HEAD~ （在本地commit之后，Git push到远端分支之前，如果不想推送到远端，撤销本地的commit操作）

git reset --hard HEAD^（本地仓库回滚到上一个版本） （慎用hard，hard会同时回滚暂存区本地仓库以及当前工作台，如果没有贮藏变更，回滚前的代码则会丢失了）

git reset --hard sha码 （本地仓库回滚到指定commit的sha码）

git push origin HEAD --force（本地仓库回滚后不能普通的commit和push，否则报错Updates were rejected because the tip of your current branch is behind，需要先将此次回滚强推到远程）

 

git 准备commit，发现修改的分支不对。比如本来应该在dev改，结果在pbs分支改

# 现在在pbs分支，把改动推入栈

git stash

# 切换到dev分支

git checkout dev

# 把改动从栈中弹出, 覆盖到dev分支

git stash pop

# 这样改动就从pbs分支换到dev分支了

# 继续提交代码

git commit -m "change list..."

git push

 

在sourceTree的对应操作：

将某个文件保存到暂存区，选择贮藏

然后切换分支，在另一个分支处点击列表的贮藏，选择刚才贮藏的文件，右键应用贮藏，即可进行后续在此分支应用变更操作

 

 

单个文件回滚到指定版本

1.进入到文件所在文件目录，或者能找到文件的路径

　　查看文件的修改记录拿到connimt sha：git log fileName

2.回退到指定版本

　　git reset 版本号sha  fileName

3.提交到本地参考

　　git commit -m “提交的描述信息”

4.更新到工作目录

　　git checkout fileName

5.提交到远程仓库

　　git push origin master

 

对应sourceTree的操作：

查看需要回滚的大版本，找到需要回滚的文件，右键重置到本次提交

然后会确认重置提交的文件信息

此时单个文件已经回滚到需要的版本，其余文件不受影响，按步骤提交即可。

 

 

git  pull 和 git fetch的区别

都可以更新当前分支，从流程图来看，git fetch只是将远程仓库的更新获取到本地仓库，不影响其他区域。而git pull则是一次性将远程仓库的代码更新到工作区（同时也会更新本地仓库），相当于git fetch后再做一个git merge。

git pull 使用不当导致代码丢失

首先，第1步和第2步，user1和user2分别在本地做修改，共同修改了file1，只有user2对file2也做了修改，所以如果这两人的代码合并，可以预计合并的时file1会冲突，file2不会。user2修改完成以后做了一次git push，这时候git远端库的head应该是指向user2的最后一次提交的。接着user1做git pull，因为file1被两个用户修改了，所以需要合并，接着user1处理完冲突以后只提交了file1，没有提交file2（用命令行需要手动reset，但是用有些GUI工具是可以选择只提交file1的）。此时的库已经丢失了user2:file2:add line的那次改动。

核心的问题就是不要在git merge的时候只提交部分代码，特别是好多人刚刚用git的时候，运行完成一次git merge，发现自己修改了1个文件，结果git提示要提交100个，这时候小心谨慎的新同学就会选择只提交自己的变动吧，殊不知这是在犯大错啊。除了这种情况，之前还遇到有的新同学会修改git默认生成的merge信息，这也是非常不好的习惯，改了以后在查问题的时候没办法很容易的看到哪些是merge。实际使用中  使用git fetch 更安全 ， 在merge之前可以看清楚 更新情况  再决定是否合并，git pull会自动合并，但有冲突并不会覆盖而是让你进行手动merge。博主指的弊端应该是本地目录会在未经确认下更新，如果使用fetch，可以先git diff [fetch来的分支名]查看下更改，确认后再merge。 不过正常情况直接git pull比较方便而且也没什么问题。所以请注意：

• git merge以后不要部分提交！！

• git merge的信息不要手动改！！

git merge使用不当引发的代码丢失血案