关于git:Git-相关常用命令

pwb，命令是用于显示以后的目录。
mkdir fileName 用于创立文件。
ls 用于显示以后文件列表。
cd filename 用于进入到指定文件按 tab 键可补全输出。
../ 命令用于返回上一级目录。
删除空目录 rmdir 目录 。
删除文件夹，无论文件是否为空，应用 -rf 即可，即 rm -rf 目录（删除就没法回收了，谨用！）；-r: 向下递归，不论有多少目录，一并删除。-f: 强制删除，不做任何提醒。
强制删除文件 rm -f 目录名。
cd ~ 返回根目录
cat 查看

vim ~/.bash_profile
笼罩
brew link –overwrite cocoapods

a. mkdir filename;
b. $ git init 创立一个新的仓库，在新建的文件夹下回创立一个.git 的目录。该目录用来跟踪治理版本库，如果没看到应用 ls -ah 就能够看到暗藏的文件;
c. $ git add . 把文件增加到仓库；
d. $ git commit -m "本次提交的阐明"，把文件提交到仓库；胜利会提醒 1. n file changed (- 文件被改变)；n insertions（- 文件被插入）;

git checkout -t origin/master -b feat-trusteeship // feat-trusteeship 为你本人起的分支名字

git push origin feature-branch:feature-branch // 推送本地的 feature-branch(冒号后面的)分支到近程 origin 的 feature-branch(冒号前面的)分支 (没有会主动创立)
为推送以后分支并建设与近程上游的跟踪，git push --set-upstream origin feature-branch

就是你在笔记本上看到的目录文件。

工作区暗藏一个目录.git, 这个不算工作区，而是Git 版本治理库。

Git 版本治理库里存了好多货色，其中最重要的就是被称之为 stage（或者叫 index） 的暂存区 。还有一个 git 给我主动创立的master, 以及指向master 的一个指针叫HEAD。

后面咱们把文件往 git 版本库里增加的时候，分两步执行。

第一步是用 git add 把文件增加进去，实际上就是 把文件批改增加到暂存区 ；
第二步是用 git commit 提交更改，实际上就是 把暂存区的所有内容提交到以后分支。

你能够简略了解为，须要提交的文件批改统统放到暂存区 ，而后， 一次性提交暂存区的所有批改。

像这样，你一直对文件进行批改，而后一直 提交批改到版本库里，每当你感觉文件批改到肯定水平的时候，就能够“保留一个快照”，这个快照在 Git 中被称为commit。一旦你把文件改乱了，或者误删了文件，还能够从最近的一个commit 复原，而后持续工作，而不是把几个月的工作成绩全副失落。

应用 git log 命令查看版本控制系统中文件从最近到最远的提交日志。

git log --pertty=online命令查看提交的精简日志。

$ git log --pretty=oneline
1094adb7b9b3807259d8cb349e7df1d4d6477073 (HEAD -> master) append GPL
e475afc93c209a690c39c13a46716e8fa000c366 add distributed
eaadf4e385e865d25c48e7ca9c8395c3f7dfaef0 wrote a readme file

须要情谊提醒的是，你看到的一大串相似 1094adb... 的是commit id（版本号），

首先，Git必须晓得以后版本是哪个版本，在 Git 中，用 HEAD 示意 以后版本，也就是最新的提交1094adb...，

上一个版本就是HEAD^，

上上一个版本就是HEAD^^，

当然往上 100 个版本写 100 个 ^ 比拟容易数不过去，所以写成HEAD~100。

应用 $ git reset --hard HEAD^ 命令

$ git reset --hard 1094a(commit id); 版本号没必要写全，前几位就能够了，Git 会主动去找。

Git 的版本回退速度十分快，因为 Git 在外部有个指向以后版本的 HEAD 指针，当你回退版本的时候，Git 仅仅是把 HEAD 从指向 append GPL：

┌────┐
│HEAD│
└────┘
│
└──> ○ append GPL

    │
    ○ add distributed
    │
    ○ wrote a readme file

改为指向 add distributed：

┌────┐
│HEAD│
└────┘
│
│ ○ append GPL
│ │
└──> ○ add distributed

    │
    ○ wrote a readme file

如果有抵触，合作开发保留本地分支，暂存

当你用 $ git reset --hard HEAD^ 回退到 add distributed 版本时，再想复原到 append GPL，就必须找到append GPL 的commit id。

应用命令 git reflog 用来记录你的每一次命令;

HEAD 指向的版本就是以后版本，因而，Git 容许咱们在版本的历史之间穿梭，应用命令 git reset –hard commit_id。
穿梭前，用 git log 能够查看提交历史，以便确定要回退到哪个版本。
要重返将来，用 git reflog 查看命令历史，以便确定要回到未来的哪个版本。

用 git diff HEAD -- filename 命令能够查看工作区和版本库外面最新版本的区别：

git checkout -- filename命令的意思就是把文件 filename 在工作区批改的全副撤销。这有两种状况：

一种是 filename 自批改后 还没有被放到暂存区 ，当初， 撤销批改就回到和版本库截然不同的状态；

一种是 filename 曾经增加到暂存区后 ， 又作了批改 ，当初， 撤销批改就回到增加到暂存区后的状态。

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

用命令 git reset HEAD <file> 能够把暂存区的批改撤销掉（unstage），从新放回工作区：

git reset 命令既能够回退版本，也能够把暂存区的批改回退到工作区。当咱们用 HEAD 时，示意最新的版本。

场景 1 ：当你改乱了工作区某个文件的内容，想间接抛弃工作区的批改时，用命令 git checkout — file。

场景 2 ：当你岂但改乱了工作区某个文件的内容，还增加到了暂存区时，想抛弃批改，分两步，第一步用命令git reset HEAD filename，就回到了场景 1，第二步按场景 1 操作。

场景 3 ：曾经提交了不适合的批改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到近程库。

git rm filename 删除文件件，而后 git status 查看文件状态，确定之后 git commit -m '阐明文案'；

若是删错文件能够应用，git checkout --filename , 一件还原文件，无论是批改的还是删除的。

git checkout其实是用版本库里的版本替换工作区的版本，无论工作区是批改还是删除，都能够“一键还原”。

当初的情景是，你曾经在本地创立了一个 Git 仓库后，又想在 GitHub 创立一个 Git 仓库，并且让这两个仓库进行近程同步，这样，GitHub 上的仓库既能够作为备份，又能够让其他人通过该仓库来合作，真是一举多得。

git init
git add README.md
git commit -m "first commit"
git remote add origin https://github.com/menyongkang/learnvue.git
git push -u origin master

git remote -v

关联一个近程库，应用命令git remote add origin 近程地址 URL, 比方 git remote add origin https://github.com/menyongkang/learnvue.git,

关联后, 应用命令 git push -u origin master 第一次把本地库的所有内容推送到近程库;

尔后，每次本地提交后，只有有必要，就能够应用命令 git push origin master 推送最新批改；

把 本地库 的内容 推送到近程 ，用git push 命令，实际上是把以后分支 master 推送到近程。

因为近程库是空的，咱们 第一次推送 master 分支时 ，加上了-u 参数，Git 岂但会把本地的 master 分支内容推送的近程新的 master 分支，还 会把本地的 master 分支和近程的 master 分支关联 起来;

git remote set-url origin 近程地址 URL

或者更改 config 文件中的 url。更换 url 后，git push。

假如咱们从零开发，那么最好的形式是先创立近程库，而后，从近程库克隆。

勾选 Initialize this repository with a README，这样GitHub 会主动为咱们创立一个 README.md 文件。创立结束后，能够看到 README.md 文件：

当初，近程库曾经筹备好了，下一步是用命令 git clone 克隆一个本地库：

$ git clone https://github.com/menyongkang/XXXX.git
Cloning into 'gitskills'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 3
Receiving objects: 100% (3/3), done.

HEAD指向的就是以后分支;

当咱们 创立新的分支 ，例如 dev 时，Git 新建了一个 指针叫 dev，指向 master 雷同的提交，再把 HEAD 指向 dev，就 示意以后分支在 dev 上。

不过，从当初开始，对工作区的批改和提交就是针对 dev 分支了，比方新提交一次后，dev 指针往前挪动一步，而 master 指针不变。

如果咱们在 dev 上的工作实现了，就能够把 dev 合并到 master 上。Git 怎么合并呢？最简略的办法，就是间接把 master 指向 dev 的以后提交，就实现了合并：

创立dev 分支，而后切换到 dev 分支; (基于稳固分支 master 创立分支)

$ git checkout -t origin/master -b feat-trusteeship // feat-trusteeship 为你本人起的分支名字

git checkout命令加上 -b 参数示意 创立并切换，相当于以下两条命令：

$ git branch dev
$ git checkout dev
Switched to branch 'dev'

用 git branch 命令查看以后分支。

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

应用 git checkout master命令示意切换到 master 分支。

最新版本的 Git 提供了新的 git switch 命令来切换分支

创立并切换到新的 dev 分支，能够应用：

$ git switch -c dev

间接切换到 已有的 master 分支，能够应用：

$ git switch master

应用 git merge 合并的指标分支 命令。例如
把dev 分支 的工作成绩 合并 到master 分支：git merge dev。


$ git merge dev
Updating d46f35e..b17d20e
Fast-forward
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

git merge命令用于合并 指定分支 到以后分支 。
留神到下面的 Fast-forward 信息，Git 通知咱们，这次合并是 “快进模式”，也就是 间接把 master 指向 dev 的以后提交，所以合并速度十分快。

应用 git cherry-pick commit-id 命令。例如
把dev 分支 的工作成绩 推送到 到master 分支。

 git log
 git chckout master
 git pull
 git cherry-pick commit-id1, commit -id2
 git push

应用 git branch -d 指标分支；

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

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

$ git branch
* master

$ git log --graph --pretty=oneline --abbrev-commit

应用 git log --graph 分支合并图.

Git 会用 Fast forward 模式，但这种模式下， 删除分支后，会丢掉分支信息。

$ git merge --no-ff -m "merge with no-ff" dev;

请留神 --no-ff 参数，示意 禁用 Fast forward。

因为本次合并要 创立一个新的 commit，所以加上 -m 参数，把commit 形容写进去。

合并分支时，加上 –no-ff 参数就能够用一般模式合并，合并后的历史有分支，能看进去已经做过合并，而 fast forward 合并就看不出来已经做过合并。

把当前工作现场“储备”起来，等当前复原现场后持续工作：

应用 $ git stash 命令。

用 git status 查看工作区，就是洁净的（除非有没有被 Git 治理的文件），因而能够释怀地创立分支来修复 bug。

把当前工作现场“储备”起来，等当前复原现场后持续工作：

应用 $ git stash 命令。

用 git status 查看工作区，就是洁净的（除非有没有被 Git 治理的文件），因而能够释怀地创立分支来修复 bug。

git rm -r filename
git add .
git commit -m “rm filename”
git push

.gitignore 只能疏忽原来没有被跟踪的文件，因而跟踪过的文件是无奈被疏忽的。因而在网页上能够看到 target 等目录的存在。
解决办法就是先把本地缓存删除（扭转成未 track 状态），而后再提交:

git rm -r –cached .
git add .
git commit -m‘update .gitignore’

当近程的稳固分支有更新时，基于近程稳固分支创立的，以后分支想同步稳固分支的代码，则执行

办法一：merge

git fetch origin

git merge origin/master

办法二：是执行 rebase 来同步变动

git pull –rebase，他相当执行:

git fetch origin

git rebase origin/master

根底命令

配置环境变量

GIT

GIT init

创立分支

本地分支推送到近程

工作区和暂存区

工作区（worker directory)

版本库(repository)

GIT 时光穿梭

版本回退 Git reset

Git 查看提交日志 git log

Git 精简查看提交日志

Git 版本号

Git 版本回退

Git 回退到指定版本

查找 commit id（版本号）

总结

Git 治理批改

Git 撤销批改

办法一

办法二

Git 删除文件

Git 近程仓库

增加近程仓库

初始创立仓库

查看近程库

增加近程库

更改近程地址

从近程库克隆

Git 创立与合并分支

Git 创立分支

Git 查看分支

Git 切换分支

Git 合并分支

Git 本次提交推送到指定分支

Git 删除分支

Git 查看合并抵触状况

分支管理策略

合并

储备

弹出暂存

git 删除近程分支

.gitignore 文件不失效

rebase 的应用