git

在mac的终端中我的名字是 chendeMacBook-Pro:~ chen$

公司的Android项目是在我的目录下的aimovie文件夹，这个aimovie文件夹是一个git仓库（也就是这个文件夹下的所有东西会被git系统管理）。

在linux操作中，如果有错误就会提示，如果没有错误或者异常就不会提示任何东西，linux的哲学就是no news is good news。

然后ls返回当然是当前目录下的东西，如果没转入到某个当前目录，那么就是我的（即/uers/chen）目录，也就是说没转入某个目录的时候，默认转入的是我的目录，而不是根目录/ ✨，这个很重要！！！（以前一直以为默认的是根目录） ls / 是看看根目录下有什么。（在mac中没有c盘等这些概念，也可以说只有一个盘，那就是 / 根目录）注意命令符与后面的命令参数中间要有一个空格，没有的话会出错✨ 

ls是列出目录( ls -ah 会显示隐藏文件) cd是转换目录  cd转换目录的时候，如果直接cd 文件夹名 那么这是转入当前目录下的文件夹下。需要注意的是没cd转入某个文件夹下（目录下）的时候，那么直接ls或者cd一个文件夹名， 那么列出的或转入的是我的目录下的那个文件夹名下的目录，而不是根目录！！！✨

chendeMacBook-Pro:~ chen$ cd aimovie/       就是接下来转入到aimovie这个目录下： chendeMacBook-Pro:aimovie chen$ 后面输入ls就会显示aimovie目录下的东西，如：

这里面如果没有.xxx后缀的，说明这是一个文件夹名，里面还有子目录。

输入git branch就会得到我的git分支下的一些东西。如：

chendeMacBook-Pro:aimovie chen$ git branch
  develop

* develop_test

 

这里是users不是user，大小写没关系，desktop大小写也没有关系。

如：

mkdir 是创建一个文件或文件夹，比如 chendeMacBook-Pro:~ chen$ mkdir learngit因为这里没有在某个特定目录下，并且这里也没写在什么目录下创建，那么就是默认在自己的目录下（/users/chen/），这个一定要注意，因为自己以前一直以为没写默认的是根目录！✨。这里创建的learngit没有后缀名，那创建的就是一个文件夹。

如果你现在在某个目录下： chendeMacBook-Pro:aimovie chen$ 那么你写个cd，那么就转到了自己的目录下，因为不写就是默认自己的目录下。其实就该这样，所有创造都是在自己的那个目录下，而不是根目录下，因为一个电脑是可以有很大users的。

需要其他的命令的话以后再看。

下面看下git常用的命令：

创建一个代码仓库：

 

总结： 1：创建文件目录 mkdir learngit 

2：进入目录 cd learngit （虽然第一步创建了，但是我们目前还没有在那个目录下，如果想在那个目录下生产文本或者粘贴复制什么的还得加上路径，所以我们这一步先转移到那个目录下，这样我们在那个目录下操作就不用加路径了（加路径的话，看一下两行：

chendeMacBook-Pro:~ chen$ mkdir Pictures/learngit

chendeMacBook-Pro:~ chen$ mkdir /users/chen/Pictures/learngit1）

直接Pictures/learngit 和 /users/chen/Pictures/learngit1是一样的（最后learngit和learngit1后面加不加/是一样的），都是在我的目录的learngit目录下创建了文件夹。因为如果你不写就是默认的是我的目录下。），

3：初始化 git init  （将这个空的learngit文件夹变成一个git仓库，这样git系统就会管理跟踪这个learngit文件夹（目录下）的所有文件的变化。当我们git init以后，就会在learngit这个文件夹下生产一个.git文件,这个文件就是管理跟踪这个文件夹下所有文件的git系统，一般不要去改变里面的东西，这时候这个learngit文件夹还是空的，我们想让git管理某个文件，我们先要将我们的想要管理的文件放入learngit这个文件夹下（这个一定要放入，不放入不行）或者在这个文件夹下直接创建文件，然而再执行git add “xxx”和git commit -m “说明”就可以了，这样learngit文件夹对应的git系统（git仓库）就会管理这个文件了。以后如果我们想改动被git管理的文件，我们直接改动后，这时候还要再执行git add “xxx”和git commit -m “说明”才可以被git系统管理。也就是说文件光在git仓库中还不行，每次（不止第一次）改动后都要将改动后的文件（改动的所有文件）再提交给git系统，通知它更改了，这样才行，每次提交到哪里了，我认为应该是git把commit的内容放到网络上的一个地方，git管理系统会实时监视commit保持的内容与你本地的内容（你电脑上的）有什么不同（其实commit就相当于打游戏时候在某一个时间保存游戏历史记录，git会把所有commit的版本都保存下来，我们用git log 就可以看到我们在什么时候commit过，commit时携带的信息都是什么（commit -m“说明”的那个“说明”））。不过在改动后但是没提交前我们git status 会显示哪些文件做了修改（当前的本地代码相比与上一次(最后一次)提交后git系统管理的内容相比较），如果想看具体某个文件做了什么修改，使用

git diff 加上某个被修改的文件名字。如果add和commit以后再git  status 就不会显示什么修改的内容了，因为你刚提交给git管理修改后的文件，git管理的就是最新的，那么git上保持的与本地的

代码相比就没有变化，所以并没有什么信息。）

4：git config user.name“chenwenchao" 5：git config user.email “chenwenchao@163.com” commit之前要登陆

6：将文件加入到库中让git管理：首先保证文件夹下原来存在此文件或者自己在这个文件夹下创建一个文件，

然后执行git add “xxx” （如果把所有改动都提交，xxx就是一个点）

7： git commit -m “说明”

 

注意：

 

1:执行git add readme.txt 指令时要保证在learngit库中存在此文件（自己在库中建一个）否则出现 fatal: pathspec 'readme.txt' did not match any files

 

2:执行git commit -m指令时前提要登陆，执行git config user.name "name" git config user.email "name@xxx.com"然后再执行git commit -m指令

 

我们还可以利用git管理系统将我们commit的任何一个版本还原到本地的代码上。git系统的网上保存的（最新）commit的版本是head（当我们在本地改动了，但还没提交时，我们git reset --hard HEAD就会退回到上一次提交的那个版本，也就是说会把我们目前在本地修改的清除），上一个叫HEAD^，上上一个版本就是HEAD^^，当然往上100个版本写100个^比较容易数不过来，所以写成HEAD~100。即使用

git reset --hard HEAD^ 就是退回上一个版本。  我们退回了上一个版本后，那么我们还能再退回来吗，能，具体看http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013744142037508cf42e51debf49668810645e02887691000

其实版本选择第几个只是指针的移动。git系统是把所有commit的版本都保存在了它的网上，并且每个版本的差别都记录下来了。并且git还会实时监督我们当地的版本和git保存的版本之间有什么区别。

注意这里的退回还原等指的是把git系统保存在网上的某个版本覆盖到本地电脑上的那个learngit 文件夹里。

总结：

• HEAD指向的版本就是当前版本，因此，Git允许我们在版本的历史之间穿梭，使用命令git reset --hard commit_id。

• 穿梭前，用git log可以查看提交历史，以便确定要回退到哪个版本。

• 要重返未来，用git reflog查看命令历史，以便确定要回到未来的哪个版本。

 

前面说了让git保存你的某个版本，要分两步，一个是add，然后再 commit ，其中add是将修改的文件保存到.git里面的暂存区（暂存区叫stage），然后commit是将暂存区的东西存到git系统的网上来保存.注意每次commit只保存暂存区的东西，如果你的工作区（就是learngit文件夹非.git文件的文件，英文为working directory）中还有些文件进行了修改，但没add到.git文件夹里面的暂存区，那么对于未add的这些修改，commit是不能保存到git系统的网上的。（git系统还是能够监督到你的的local本地代码版本和git系统最新一次保存的代码版本之间有什么区别，比如modified:   readme.txt）

 

如果你对learngit文件夹非.git文件的那些代码文件做了修改，然后想撤销，回复到上一次提交（或上一次add）的版本状态，那么使用：

命令git checkout -- readme.txt意思就是，把readme.txt文件在工作区的修改全部撤销，这里有两种情况：

一种是readme.txt自修改后还没有被放到暂存区，现在，撤销修改就回到和版本库（就是最近一次commit的版本）一模一样的状态；

一种是readme.txt已经添加到暂存区后，又作了修改，现在，撤销修改就回到添加到暂存区后的状态。

总之，就是让这个文件回到最近一次git commit或git add时的状态。

git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令。

 

如果你已经把修改add到缓存区了，你想撤销缓存区中的修改，那么怎么办呢，也是有办法的，我觉得用的应该不多，想看的时候看http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001374831943254ee90db11b13d4ba9a73b9047f4fb968d000

 

 

删除文件用rm test.txt（不用git这个前缀），你在工作区的一举一动，git都会监督的到，Git知道你删除了文件，因此，工作区和版本库就不一致了，git status命令会立刻告诉你和上一次commit的版本相比，哪些文件被删除了。

1，这时候如果你想跟新git中的版本库，要保存你的最新的修改（删除文件）到git系统的网上，那么那就用命令git rm 文件名删掉（或者用add也可以吧，这里的rm前面有git），并且git commit -m“说明”：

即$ git rm test.txt 回车 然后git commit -m "remove test.txt”回车。

2，另一种情况是删错了，那么还是用git checkout — test.txt 来回复git系统保存的最新的那个版本中text.text文件的状态。

 

上面说的把版本放到git系统的网上是不对的，不是放到远程的git的系统中保存，而还是保存在本地的.git文件夹里面，保存了你commit的各个版本，用一个指针来指向最新的版本。

那么远程的库（远程库叫origin，需要远程库来多人协作）在什么地方呢，是在github上，github上也需要建一个库（组里已经创建好了）来同步我本地库中commit的最新版的代码。用的是push命令，提交到远程库的是最新版的commit代码：

如果是第一次push：

git push -u origin master

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支（什么是master 呢？是这样的，刚才不是说了吗，我们把我们每次commit的版本是存在.git文件夹的一个“链”上，用一个指针来指向最新commit的版本。我们在创建我们本地这个git仓库的时候，就创建了一个master分支，那么目前为止我们所有commit操作和git保存的那个版本链等都是都是在master分支上），还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。

 

不是第一次的话：

git push origin maste

注意这里的操作都都需要将目录切到learngit那个git仓库目录下。

 

刚才你的本地仓库中只有一个master分支，所以我们提交commit的版本自然都是在这个分支上（master分支管理的版本链增加一个版本节点，并且使master对应的指针（可以叫master指针，其实一个分支就是一个指针来指向一个版本结点，如果新建了一个分支dev，那么就是新建了一个指针，然后使这个指针指向某一个版本结点。我们如果想在dev分支上提交一个新版本，那么么就是在这个dev分支对应的dev指针指向的结点后增加一个版本结点，然后让dev指针指向刚在dev上提交的新版本。注意我们想在某个分支上提交新版本的时候，我们要实现挑战到那个分支 比如git checkout dev  这样我们就得到了head指针，head指针就是用于延长所在的分支对应的链的，也就是说我们commit都是提交给head ，然后head 再提交给所在分支的指针，所以在某个分支提交时，先要讲head 指针指向我们的那个分支，也就是git checkout dev  ）指向最新增加的版本结点，），这样如果我们在不同的分支上进行不同的commit的时候，那么这个总的链就有可能分叉了：

 

 

 

一些命令：

 

我们创建dev分支（创建时的版本和master 指向的版本是一样的），然后切换到dev分支（将head指针指向dev，因为commit总是会提交给head，那么head指针指向dev之后，相当于commit提交的版本提交给dev 了）：

$ git checkout -b dev

Switched to a new branch 'dev'

 

上面的这一条相当于：

$ git branch dev    创建dev分支

$ git checkout dev  切换到dev分支

 

git branch命令查看当前分支：

$ git branch
* dev
  master

 

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

 

分支只是指向从前以后这些不同的版本的指针。所以并不需要复制代码的，恢复跳转到某个版本不会花很多时间，很方便，并且每个分支都是一个完整的代码版本。

 

我们要把dev分支的工作成果合并到master分支上，也就是说我们要使master分支对应的链发生变化（对应的指针也变化），那么首先我们得先把head指向master指针，也就是切换到master分支$ git checkout master，然后$ git merge dev ，因为这里合并不会产生冲突，所以可以合并，合并以后，master 分支中就有了dev分支中做的修改。这样很好，我们可以先建一个分支（分支也是 一个完整的版本），然后在这个分支上做develop，做好了，测试好了，我们再将我们的发布版本的主分支与我们的该分支合并，这样我们的主分支就有了我们开发后的内容，而不是一开始就在主分支master上改动，如果改动不好就毁了。如果我们再开分支的话，开发不好直接弃用就还了，很方便。这里因为在dev分支改动的时候，master分支没有改变什么，所以这里合并是Fast-forward 合并“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。

当然，也不是每次合并都能Fast-forward，我们后面会将其他方式的合并。

合并完成后，就可以放心地删除dev分支了：

$ git branch -d dev
Deleted branch dev (was fec145a).

删除后，查看branch，就只剩下master分支了：

$ git branch * master

 

查看分支：git branch

创建分支：git branch <name>

切换分支：git checkout <name>

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

合并某分支到当前分支（事先切换到当前分支）：git merge <name>

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

 

当我们把远程的仓库克隆到本地时，Git自动把本地的master分支和远程的master分支对应起来了（注意克隆的时候只是克隆了master这一个分支，如果想将本地的dev分支提交到远程的dev分支，那么首先还要先从远程下在下来远程仓库中的dev分支，即要在dev分支上开发，就必须创建远程origin的dev分支到本地，于是他用这个命令创建本地dev分支：git checkout -b dev origin/dev 注意dev分支不是master 分支的一部分，他们都是完整的代码版本，只是不是版本不一样，dev版本会develop，开发好了，再合并给master 版本用于发布，所以我们这里都是在本地的dev版本改动，然后再push给远程仓库的dev中（git push origin dev），最后这个开放版本完全好了，再把dev合并到master 中），并且，远程仓库的默认名称是origin。也就是说我们的本地仓库与远程仓库建立了一对一的关系：

如果要查看对应的远程库的信息，用git remote：

$ git remote
origin

或者，用git remote -v显示更详细的信息：

$ git remote -v
origin  git@github.com:michaelliao/learngit.git (fetch)
origin  git@github.com:michaelliao/learngit.git (push)

 

上面显示了可以抓取和推送的origin的地址。如果没有推送权限，就看不到push的地址。

如果我们push的时候，已经有人在上面改动了，那么我们要先把远程dev分支对应的最新版本拉下来，然后在push，拉之前要讲先将本地dev分支与远程origin/dev分支的链接，设置dev和origin/dev的链接，输入

$ git branch --set-upstream dev origin/dev

然后回车。

再pull： $ git pull

如果合并有冲突，需要手动解决，解决的方法和分支管理中的解决冲突完全一样。解决后，提交，再push，例如：

$ git commit -m "merge & fix hello.py" [dev adca45d] merge & fix hello.py $ git push origin dev Counting objects: 10, done. Delta compression using up to 4 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (6/6), 747 bytes, done. Total 6 (delta 0), reused 0 (delta 0) To git@github.com:michaelliao/learngit.git    291bea8..adca45d  dev -> dev

 

先写到这把。

---------------------------------------------------------------------------------

上午师兄的pull和push代码的演示总结：

将路径cd切换到我的目录下的aimovie文件夹下（也就是公司Android项目的git仓库下）。

输入 git branch 就到了本地git仓库的所有分支列表，

chendeMacBook-Pro:aimovie chen$ git branch
  develop

* develop_test

这时候看到绿色字体说明我现在是在develop_test这个分支下，我要切换到develop这个分支里面，

即输入git checkout develop，✨返回如下：

chendeMacBook-Pro:aimovie chen$ git checkout develop
Switched to branch 'develop'
Your branch is behind 'origin/develop' by 116 commits, and can be fast-forwarded.

  (use "git pull" to update your local branch)

然后在输入git pull  ，即 chendeMacBook-Pro:aimovie chen$ git pull 回车就会从远程把代码拉下来来更新本地代码，出来很多代码。

然后在输入git pull origin stage，即 chendeMacBook-Pro:aimovie chen$ git pull origin stage，回车，出来很多代码。

之后可能刚才那个分支不好，师兄又给我新建了一个分支，即输入git checkout -b stage_bug（因为我们之前在develop分支上把最新的东西下拉下来了，我们这时候创建的stage_bug指针指向就是目前的develop指针，所以这个stage_bug分支就是远程代码的最新的commit的版本，所以目前就不用stage_bug再pull更新了）回车得到：

chendeMacBook-Pro:aimovie chen$ git checkout -b stage_bug （已经建好了以后就是将上面✨的地方改成git checkout stage_bug就行了）

Switched to a new branch 'stage_bug'
chendeMacBook-Pro:aimovie chen$ git branch
  develop
  develop_test

* stage_bug

我就是在这个stage_bug分支中将自己已经改的代码提交上去（提交前自己要测试一下，看对不对）。如下（注意空格，add后面的. 表示add所有的改动）：

chendeMacBook-Pro:aimovie chen$ git add .

chendeMacBook-Pro:aimovie chen$ git commit -m "预告片崩溃问题修复"

 

然后修改了自己在git上的用户名chenwenchao和邮箱 chenwenchao@meituan.com

然后输入 git push origin stage_bug，即chendeMacBook-Pro:aimovie chen$ git push origin stage_bug 回车就可以了（这个stage_bug是我在本地仓库中新建的分支，现在远程仓库中应该还没有这个分支啊，那么我们这里向远程push的话，是不是在远程会创造一个stage_bug分支啊，但是远程的stage_bug 是会自动更新吗，不是自动更新的话，因为除了我没人提交到远程的stage_bug分支上啊，我在我的本地stage_bug 分支进行git pull（一开始可能需要$ git branch --set-upstream stage_bug origin/stage_bug建立联系吧）的时候，就没有拉下来新东西了，所以应该是远程的stage_bug自动更新把。。。。？）

 

问问师兄，我自己的分支develop，那么我提交到的远程的develop是我自己的，还是大家都会把代码提交到这个上面，如果只是我自己用，那怎么保证我从本地的develop分支push到远程的develop的那些改动怎么合并到大家公用的分支里面（会有人做这个事，我不用管吗），还有就是如果是我自己的远程develop分支，那么我每次pull的时候，从远程的develop分支pull到我本地的develop分支时，怎么保证远程的develop分支是更新的（包含了别人commit后的协作内容），这个也是自动更新远程的我的develop分支吗，不用我管？