git相关命令行总结

git学习神器

授权分享一个git学习playground，谁用谁知道：
Learn Git Branching

还有一个比较有意思的（性感程序员在线吐槽）：
Oh Shit, Git!?!

基本设置

设置用户名

git config --global user.name "xxxx"

设置用户邮箱

git config --global user.email "xxxx"

查看用户名

git config user.name

查看用户邮箱

git config user.email

创建目录

mkdir myown
cd myown

创建新的repository

git init

生成并编辑一个脚本

touch helloworld.c

vim helloworld.c

编译

gcc -o helloworld -Wall helloworld.c

pull/fetch

都是从远程拉取代码，区别在于：

• git fetch 拉取远程更新，但不merge
• git pull 拉取远程更新并merge到本地(相当于git fetch & git merge FETCH_HEAD)

commit操作

Commit this code file into the repository（commit创建/修改）:
先add文件

git add helloworld.c

在commit到repository

git commit -m "New code file"

查看更改记录

git log

查看文件改动

git status

查看代码改动

git diff

撤销改动

git revert hexstring

图形界面

gitk

branch操作

##git checkout
新建一个branch并切换到这个branch

git checkout -b my-new-branch

查看所有branch

git branch

切换到master branch

git checkout master

修改合并new branch到master

##git merge

git merge my-new-branch

git merge

将两个分支合并到一起。就是说我们新建一个分支，在其上开发某个新功能，开发完成后再合并回主线。

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



关于git merge详解

git rebase

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

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

注意一个细节，rebase后，C3的commit还存在，但是处于未加入暂存区状态。

merge和rebase区别

• merge操作会生成一个新的节点，之前的提交分开显示（⾃动创建⼀个新的commit ，如果合并的时候遇到冲突，仅需要修改后重新commit）。
• 而rebase操作不会生成新的节点，是将两个分支融合成一个线性的提交（会合并之前的commit历史）。

用rebase可以线性的看到每一次提交，并且没有增加提交节点。

git pull = git fetch + git merge FETCH_HEAD

git pull --rebase = git fetch + git rebase FETCH_HEAD

merge

• 优点：记录了真实的commit情况，包括每个分⽀的详情
• 缺点：因为每次merge会⾃动产⽣⼀个merge commit，所以在使⽤⼀些git 的GUI tools，特别是commit⽐较频繁时，看到分⽀很杂乱。

rebase

• 优点：得到更简洁的项⽬历史，去掉了merge commit
• 缺点：如果合并出现代码问题不容易定位，因为re-write了history

因此,当需要保留详细的合并信息的时候建议使⽤git merge，特别是需要将分⽀合并进⼊master分⽀时；当发现⾃⼰修改某个功能时，频繁进⾏了git commit提交时，发现其实过多的提交信息没有必要时，可以尝试git rebase.

撤销变更

Git撤销&回滚操作

git reset

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

reset后，c2的commit还存在，但是处于未加入暂存区状态

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

撤销commit

git reset --soft HEAD^

注意，这里仅仅是撤回commit操作，更改和git add .后的代码仍然保留。

HEAD^的意思是上一个版本，也可以写成HEAD~1

如果你进行了2次commit，想都撤回，可以使用HEAD~2

mixex/soft/hard

--mixed
不删除工作空间改动代码，撤销commit，并且撤销git add . 操作
这个为默认参数，git reset --mixed HEAD^ 和 git reset HEAD^ 效果是一样的。

--soft
不删除工作空间改动代码，撤销commit，但不撤销git add .

--hard
删除工作空间改动代码（从上一次commit之后更改的代码都没了），撤销commit，也撤销 git add .
注意完成这个操作后，就恢复到了上一次的commit状态。

修改commit注释

如果commit注释写错了，只是想改一下注释，只需要：

git commit --amend

此时会进入默认vim编辑器，修改注释完毕后保存就好了。

git revert

为了撤销更改并分享给别人，我们需要使用 git revert。

revert会创建一个新的提交记录，这个新的提交记录与需要回滚的commit的上一个提交记录是一样的。

revert和reset区别

这个问题同样也需要先了解 git 仓库的三个组成部分：⼯作区（Working Directory）、暂存区（Stage）和历史记录区 （History）。

• ⼯作区：在 git 管理下的正常⽬录都算是⼯作区，我们平时的编辑⼯作都是在⼯作区完成
• 暂存区：临时区域。⾥⾯存放将要提交⽂件的快照
• 历史记录区：git commit 后的记录区

三个区的转换关系以及转换所使⽤的命令：

revert ：放弃指定提交的修改，但是会生成一次新的提交，需要填写提交注释，以前的历史记录都在；
就是以创建新的 commit 的⽅式来撤销 commit，这样能保留之前的 commit 历史，⽐较安全。另外，同样因为可能会覆盖本地的修改，所以执⾏这个指令之前，你需要stash 或者 commit 暂存区和⼯作区的更改。

reset ：将HEAD指针指到指定提交，历史记录中不会出现放弃的提交记录。
可以将⼀个分⽀的末端指向之前的⼀个 commit。然后再下次 git 执⾏垃圾回收的时候，会把这个 commit之后的 commit 都扔掉。git reset 还⽀持三种标记，⽤来标记 reset 指令影响的范围：

1. –mixed：会影响到暂存区和历史记录区。也是默认选项
2. –soft：只影响历史记录区
3. –hard：影响⼯作区、暂存区和历史记录区

• 注意：因为 git reset 是直接删除 commit 记录，从⽽会影响到其他开发⼈员的分⽀，所以不要在公共分⽀（⽐如develop）做这个操作。

git revert是用一次新的commit来回滚之前的commit，git reset是直接删除指定的commit。
git revert是用一次逆向的commit“中和”之前的提交，因此日后合并老的branch时，导致这部分改变不会再次出现，但是git reset是之间把某些commit在某个branch上删除，因而和老的branch再次merge时，这些被回滚的commit应该还会被引入。
git reset 是把HEAD向后移动了一下，而git revert是HEAD继续前进，只是新的commit的内容和要revert的内容正好相反，能够抵消要被revert的内容。

• git checkout 可以将 HEAD 移到⼀个新的分⽀，并更新⼯作⽬录。因为可能会覆盖本地的修改，所以执⾏这个指令之前，你需要 stash 或者 commit 暂存区和⼯作区的更改。

推送到GitHub

在GitHub上创建一个新 repository
将本地现有的repository上传到GitHub

git remote add origin https://github.com/cubeton/mynewrepository.git

git push -u origin master

将branch上传到GitHub

git push origin my-new-branch

创建pull request

1.先 fork 别人的仓库，相当于拷贝一份，
2.做一些 bug fix发起
3.pull request 给原仓库，让他看到你修改的 bug
4.原仓库 review 这个 bug，如果是正确的话，就会 merge 到他自己的项目中

至此，整个 pull request 的过程就结束了。

关于pull request的理解
作者：beepony
链接：https://www.zhihu.com/question/21682976/answer/79489643
来源：知乎

将GitHub上的更改返回到本地

git pull origin master

git rebase工作流

#克隆/拉取远程master分支
git clone -b master
#在自己本地创建一个本地开发分支
git checkout -b local

#或者是
git checkout master
git pull
git checkout local
#切换到local分支后， 就是修改代码
#修改完了， 就正常提交代码
git commit
#如果有多次local分支的提交，就合并，只有一次可以不合并
git rebase -i HEAD~2  #合并提交 --- 2表示合并两个

#将master内容合并到local
git rebase master
#解决冲突
git rebase --continue

#再切换到master或其他目标分支
git checkout master
#将local合并到master
git merge local
#推送到远程仓库
git push

未完待续