Git未整理，做不动了告辞

在项目根目录下运行gitk，可打开图形化控制界面。
每次都百度，还是先记录一下正常操作流程
git config --global user.name “xxx”
git config --global user.email “xxx”
注意事项
首先，操作之前一定要看清分支！！

其次，提交代码之前一定要先更新代码！！

git branch -----查看当前分支

git pull -----更新代码到本地
先切换到想保存仓库的位置
git init or
git clone https://xxxx
修改之后要上传了
git status
git add .
git commit -m “本次更新的说明”
git pull 拉取当前分支最新代码
git push origin master # 将本地主分支推到远程主分支
这次要用的时候才发现和我上次推送的方式不太一样。我记得是建议在本地新建一个分支再改代码，但是这次忘记了，直接在master分支上修改了orz
从远程仓库获取最新代码合并到本地分支
下次记得先看这个

git add -A 提交所有变化
git add -u 提交被修改(modified)和被删除(deleted)文件，不包括新文件(new)
git add . 提交新文件(new)和被修改(modified)文件，不包括被删除(deleted)文件
安全一点的方式：在分支上进行代码的操作

找到了，上次用的是这个方法
Git拉取最新项目，修改更新并上传到github上面
1.创建一个新的分支test,并切换至该分支：

$git checkout -b test

2.在该分支可以对代码进行修改，删除，增加等。

3.提交sixi这个分支修改，删除、增加的代码：

$ git commit -a -m 'commit all files'

4.切换至master分支，把分支sixi合并到本地master中。

$git checkout master

$git merge sixi

6.上传至远程仓库：

git push origin master

Git管理的文件分为：工作区，版本库，版本库又分为暂存区stage和暂存区分支master(仓库)

工作区>>>>暂存区>>>>仓库

git add把文件从工作区>>>>暂存区，git commit把文件从暂存区>>>>仓库，

git diff查看工作区和暂存区差异，

git diff --cached查看暂存区和仓库差异，

git diff HEAD 查看工作区和仓库的差异，

git add的反向命令git checkout，撤销工作区修改，即把暂存区最新版本转移到工作区，git checkout – 就是在工作区恢复暂存区版本而已

git commit的反向命令git reset HEAD，就是把仓库最新版本转移到暂存区。
摘自评论区，仍待商榷




git-cheatsheet

Git鼓励大量使用分支：

查看分支：git branch

创建分支：git branch

切换分支：git checkout 或者git switch

创建+切换分支：git checkout -b 或者git switch -c

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

删除分支：git branch -d

合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。

修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；

当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场；

在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick 命令，把bug提交的修改“复制”到当前分支，避免重复劳动。

查看远程库信息，使用git remote -v；

本地新建的分支如果不推送到远程，对其他人就是不可见的；

从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；

在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name，本地和远程分支的名称最好一致；

建立本地分支和远程分支的关联，使用git branch --set-upstream branch-name origin/branch-name；

从远程抓取分支，使用git pull，如果有冲突，要先处理冲突

git config --global user.name "iroy33"
git config --global user.email "xxx@xx.com"

注意git config命令的–global参数，用了这个参数，表示你这台机器上所有的Git仓库都会使用这个配置，当然也可以对某个仓库指定不同的用户名和Email地址。

创建版本库

创建空目录
git init 把该目录编程Git可以管理的仓库

$ mkdir learngit
$ cd learngit
$ pwd
xxx
Git init

把文件添加到版本库

Notes：

• Microsoft的Word格式是二进制格式，因此，版本控制系统是没法跟踪Word文件的改动的
• 强烈建议使用标准的UTF-8编码，所有语言使用同一种编码，既没有冲突，又被所有平台所支持
• 千万不要使用Windows自带的记事本编辑任何文本文件。原因是Microsoft开发记事本的团队使用了一个非常弱智的行为来保存UTF-8编码的文件，他们自作聪明地在每个文件开头添加了0xefbbbf（十六进制）的字符，你会遇到很多不可思议的问题，比如，网页第一行可能会显示一个“?”，明明正确的程序一编译就报语法错误，等等，都是由记事本的弱智行为带来的。
• UTF-8 without BOM

使用命令git add <file>，注意，可反复多次使用，添加多个文件；
使用命令git commit -m <message>，完成。
2 insertions 说明插入了两行

时光穿梭机

查看状态git status

修改后未保存

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   readme.txt

no changes added to commit (use "git add" and/or "git commit -a")

git status命令可以让我们时刻掌握仓库当前的状态，上面的命令输出告诉我们，readme.txt被修改过了，但还没有准备提交的修改。

查看具体修改 git diff fimename

$ git diff readme.txt
diff --git a/readme.txt b/readme.txt
index d8036c1..013b5bc 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,2 +1,2 @@
-Git is a version control system.
+Git is a distributed version control system.
 Git is free software.
\ No newline at end of file

要在没提交之前

再次提交

先git add, 不commit，查看状态

$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   readme.txt

git status告诉我们，将要被提交的修改包括readme.txt，下一步，就可以放心地提交了：
commit

$ git commit -m "add dis"
[master 3503de0] add dis
 1 file changed, 1 insertion(+), 1 deletion(-)

再次查询状态

$ git status
On branch master
nothing to commit, working tree clean

版本回退

查看所有版本 git log

git log命令显示从最近到最远的提交日志，我们可以看到3次提交，最近的一次是append GPL，上一次是add distributed，最早的一次是wrote a readme file。

$ git log --pretty=oneline
7b892ab47e7f17a5324bf8339587d88ea93c4a50 (HEAD -> master) add GPL
3503de03b8e6e72598a23f6765da91824ff4a565 add dis
1424c2669419ed9d0d7f35047742f9d880db1efc wrote a readme file

首先，Git必须知道当前版本是哪个版本，在Git中，用HEAD表示当前版本，也就是最新的提交7b892ab…（注意我的提交ID和你的肯定不一样），上一个版本就是HEAD^ ，上上一个版本就是HEAD^^ ，当然往上100个版本写100个^ 比较容易数不过来，所以写成HEAD~100。

$ git reset --hard HEAD^
HEAD is now at 3503de0 add dis

那个版本不见叻

$ git log --pretty=oneline
3503de03b8e6e72598a23f6765da91824ff4a565 (HEAD -> master) add dis
1424c2669419ed9d0d7f35047742f9d880db1efc wrote a readme file

1、上面命令行窗口未关闭
只要上面的命令行窗口还没有被关掉，你就可以顺着往上找啊找啊，找到那个append GPL的commit id是1094adb…，于是就可以指定回到未来的某个版本

$ git reset --hard 7b892a
HEAD is now at 7b892ab add GPL

版本号没必要写全，前几位就可以了，Git会自动去找。当然也不能只写前一两位，因为Git可能会找到多个版本号，就无法确定是哪一个了。
2、关闭了用git reflog 找
git reflog查看历史命令，可回到未来版本

7b892ab (HEAD -> master) HEAD@{0}: reset: moving to 7b892a
3503de0 HEAD@{1}: reset: moving to HEAD^
7b892ab (HEAD -> master) HEAD@{2}: commit: add GPL
3503de0 HEAD@{3}: commit: add dis
1424c26 HEAD@{4}: commit (initial): wrote a readme file

版本库

工作区

就是你在电脑里能看到的目录，比如我的learngit文件夹就是一个工作区：

第一步是用git add把文件添加进去，实际上就是把文件修改添加到暂存区stage；

第二步是用git commit提交更改，实际上就是把暂存区的所有内容提交到当前分支。

因为我们创建Git版本库时，Git自动为我们创建了唯一一个master分支，所以，现在，git commit就是往master分支上提交更改。

所以，git add命令实际上就是把要提交的所有修改放到暂存区（Stage），然后，执行git commit就可以一次性把暂存区的所有修改提交到分支。
一旦提交后，如果你又没有对工作区做任何修改，那么工作区就是“干净”的：

$ git status
On branch master
nothing to commit, working tree clean

管理修改

第一次修改 -> git add -> 第二次修改 -> git commit

你看，我们前面讲了，Git管理的是修改，当你用git add命令后，在工作区的第一次修改被放入暂存区，准备提交，但是，在工作区的第二次修改并没有放入暂存区，所以，git commit只负责把暂存区的修改提交了，也就是第一次的修改被提交了，第二次的修改不会被提交。
提交后，用提交后，用git diff HEAD -- readme.txt命令可以查看工作区和版本库里面最新版本的区别：

$ git diff HEAD -- readme.txt
diff --git a/readme.txt b/readme.txt
index db28b2c..9a8b341 100644
--- a/readme.txt
+++ b/readme.txt
@@ -1,4 +1,4 @@
 Git is a distributed version control system.
 Git is free software distributed under the GPL.
 Git has a mutable index called stage.
-Git tracks changes.
\ No newline at end of file
+Git tracks changes of files.
\ No newline at end of file

工作区和版本库不一致，版本库里没有更新上。
那怎么提交第二次修改呢？你可以继续git add再git commit，也可以别着急提交第一次修改，先git add第二次修改，再git commit，就相当于把两次修改合并后一块提交了：

第一次修改 -> git add -> 第二次修改 -> git add -> git commit

撤销修改 git checkout – file

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

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

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

总之，就是让这个文件回到最近一次git commit或git add时的状态。
git checkout -- file命令中的--很重要，没有--，就变成了“切换到另一个分支”的命令，我们在后面的分支管理中会再次遇到git checkout命令

git reset命令既可以回退版本，也可以把暂存区的修改回退到工作区。当我们用HEAD时，表示最新的版本。

小结
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。

场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，第一步用命令git reset HEAD <file>，就回到了场景1，第二步按场景1操作。

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

删除文件

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

注意：从来没有被添加到版本库就被删除的文件，是无法恢复的！命令git rm用于删除一个文件。如果一个文件已经被提交到版本库，那么你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。
git rm file 删除工作区和暂存区的文件，需要从版本库reset下来，直接checkout是无法还原的，暂存区被删了，

rm 只删除工作区的文件，直接checkout是可以还原的
test.txt（2行文字） ——add——commit——rm——checkout——这样删除了你会获得test.txt（2行文字）

test.txt （2行文字）——add——commit——修改增加test.txt的内容（3行文字）——rm——checkout——这样删除了你会获得test.txt（2行文字）

于是，你永远不用担心误删，但是要小心，你只能恢复文件到最新版本，你会丢失最近一次提交后你修改的内容。理解了吗？

添加到远程库

由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令
要关联一个远程库，使用命令git remote add origin git@server-name:path/repo-name.git；

git remote add origin https://github.com/Roy4699/learngit.git

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

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

从远程库克隆

要克隆一个仓库，首先必须知道仓库的地址，然后使用git clone命令克隆。

Git支持多种协议，包括https，但通过ssh支持的原生git协议速度最快。

分支管理

在版本回退里，你已经知道，每次提交，Git都把它们串成一条时间线，这条时间线就是一个分支。截止到目前，只有一条时间线，在Git里，这个分支叫主分支，即master分支。HEAD严格来说不是指向提交，而是指向master，master才是指向提交的，所以，HEAD指向的就是当前分支。

一开始的时候，master分支是一条线，Git用master指向最新的提交，再用HEAD指向master，就能确定当前分支，以及当前分支的提交点：

每次提交，master分支都会向前移动一步，这样，随着你不断提交，master分支的线也越来越长。

当我们创建新的分支，例如dev时，Git新建了一个指针叫dev，指向master相同的提交，再把HEAD指向dev，就表示当前分支在dev上

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：
假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

合并完分支后，甚至可以删除dev分支。删除dev分支就是把dev指针给删掉，删掉后，我们就剩下了一条master分支：

切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变

对应到readme.txt里居然真的没有
看来不同分支工作区还不一样

分支管理策略

首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；

那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；

你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。

所以，团队合作的分支看起来就像这样：

bug分支

，Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge

首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：

feature分支

如果后来又不要了，可以用stash隐藏

多人协作

$ git remote -v
origin https://github.com/xx/learngit.git (fetch)
origin https://github.com/xx/learngit.git (push)
如果没有推送权限，就看不到push的地址。

master分支是主分支，因此要时刻与远程同步；

dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；

bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；

feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发。

配置Git的时候，加上–global是针对当前用户起作用的，如果不加，那只针对当前的仓库起作用。