git的使用介绍

git 的使用

[参考廖雪峰的链接]（https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013743256916071d599b3aed534aaab22a0db6c4e07fd0000）

对github的理解：

GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。

---

创建版本库
git init /Users/michael/learngit

文件添加到仓库
git add readme.txt
git commit -m “wrote a readme file”

---

本文具体讲git操作的命令

---

要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；
origin 默认的远程库的别名

关联后，使用命令git push -u origin master第一次推送master分支的所有内容；

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

---

克隆一份到本地仓库：默认为master分支
git clone git@github.com:michaelliao/gitskills.git

---

分支管理

查看分支：git branch

创建分支：git branch name

切换分支：git checkout name

创建+切换分支：git checkout -b name

合并某分支到当前分支：git merge name

删除分支：git branch -d name

---

解决分支冲突
git status也可以告诉我们冲突的文件
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容
在主分支上提交
git add readme.txt
git commit -m "conflict fixed"

用带参数的git log也可以看到分支的合并情况
git log --graph --pretty=oneline --abbrev-commit

删除feature1分支
git branch -d 分支名

---

分支策略

在实际开发中，我们应该按照几个基本原则进行分支管理：

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
git merge --no-ff -m "merge with no-ff" dev
合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

---

忽略某些文件时，需要编写.gitignore文件；
.gitignore文件本身要放到版本库里，并且可以对.gitignore做版本管理！

---

工作流程：

当你从远程仓库克隆时，实际上Git自动把本地的master分支和远程的master分支对应起来了，并且，远程仓库的默认名称是origin
要查看远程库的信息，用git remote -v
1. git clone git@github.com:michaelliao/learngit.git
2. 现在，你的小伙伴要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：
git checkout -b dev origin/dev
3. 推送分支
git add hello.py
git commit -m "add coding: utf-8"
git push origin dev
4.分支冲突，推送失败
先用git pull把最新的提交从origin/dev抓下来，然后，在本地合并，解决冲突，再推送：
指定本地dev分支与远程origin/dev分支的链接
git branch --set-upstream dev origin/dev
git pull
git add hello.py
git commit -m "add coding: utf-8"
git push origin dev

---

版本回退
(一旦你把文件改乱了，或者误删了文件，还可以从最近的一个commit恢复，然后继续工作)
git log –pretty=oneline命令显示从最近到最远的提交日志
在Git中，用HEAD表示当前版本,上一个版本就是HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100,例如：

git reset --hard HEAD^
 git reset --hard 3628164

Git提供了一个命令git reflog用来记录你的每一次命令

Git是用来管理修改的，每次修改，如果不add到暂存区，那就不会加入到commit中
git checkout – readme.txt用来让这个文件回到最近一次git commit或git add时的状态
git rm用于删除一个文件

Git fetch vs git pull都是从远程拉取代码到本地，git fetch只是拉取到本地，git pull不仅拉取到本地还merge到本地分支中。所以git pull是git fetch与git merge的集合体。

一般我们把别的分支合并到master时用merge，而把master合并到别的分支时会用到rebase的原因，这是因为master分支一般commit会比较频繁。

git rebase是对commit history的改写。当你要改写的commit history还没有被提交到远程repo的时候，也就是说，还没有与他人共享之前，commit history是你私人所有的，那么想怎么改写都可以。
而一旦被提交到远程后，这时如果再改写history，那么势必和他人的history长的就不一样了。git push的时候，git会比较commit history，如果不一致，commit动作会被拒绝，唯一的办法就是带上-f参数，强制要求commit，这时git会以committer的history覆写远程repo，从而完成代码的提交。虽然代码提交上去了，但是这样可能会造成别人工作成果的丢失，所以使用-f参数要慎重。
git merge，它会自动生成一个commit，包含两个分支的提交，这样就把两个分叉的commit重新又合并在一起。但是这个自动生成的commit会有两个parent，review代码的时候必须要比较两次，很不方便。
为了保证commit history的线性，可以采用另外一种方法，就是git rebase。由于该提交这时还没有被提交到远程上去，也就是他完全私有的一个commit，所以使用git rebase改写自己的history完全没有问题
git cherry-pick可以选择某一个分支中的一个或几个commit(s)来进行操作。例如，假设我们有个稳定版本的分支，叫v2.0，另外还有个开发版本的分支v3.0，我们不能直接把两个分支合并，这样会导致稳定版本混乱，但是又想增加一个v3.0中的功能到v2.0中，这里就可以使用cherry-pick了。
就是对已经存在的commit 进行 再次提交；
简单用法：

    git cherry-pick <commit id>

注意：当执行完 cherry-pick 以后，将会 生成一个新的提交；这个新的提交的哈希值和原来的不同，但标识名 一样；