git and github/gitee

$ git config --global user.name "Your Name"
$ git config --global user.email "email@example.com"

因为Git是分布式版本控制系统，所以，每个机器都必须自报家门：你的名字和Email地址。你也许会担心，如果有人故意冒充别人怎么办？这个不必担心，首先我们相信大家都是善良无知的群众，其次，真的有冒充的也是有办法可查的。

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

 

将该目录创建为一个仓库

git init 

添加到仓库

git add .  / test.txt

提交到仓库

git commit -m "自定义提示语" 

查看状态

git status

Git文件的4种状态

 

• Untracked: 未跟踪, 此文件在文件夹中, 但并没有加入到git库, 不参与版本控制. 通过git add 状态变为Staged

• Unmodify: 文件已经入库, 未修改, 即版本库中的文件快照内容与文件夹中完全一致. 这种类型的文件有两种去处, 如果它被修改, 而变为Modified. 如果使用git rm移出版本库, 则成为Untracked文件

• Modified: 文件已修改, 仅仅是修改, 并没有进行其他的操作. 这个文件也有两个去处, 通过git add可进入暂存staged状态, 使用git checkout 则丢弃修改过, 返回到unmodify状态, 这个git checkout即从库中取出文件, 覆盖当前修改

• Staged: 暂存状态. 执行git commit则将修改同步到库中, 这时库中的文件和本地文件又变为一致, 文件为Unmodify状态. 执行git reset HEAD filename取消暂存, 文件状态为Modified

查看改动的地方

git diff test.txt

查看最近三次提交记录

git log

版本回退（git里的版本回退，编辑器上的内容也要回退）

git reset --hard HEAD^
# HEAD^上一个版本
# HEAD^^上上一个版本
# HEAD~100 100个前版本

其实可以通过固定的commit id回到指定的版本 即回退后还可以后悔回退

git reset --hard 1094a

查看历史命令

git reflog

 

工作区Working Directory、版本区Repository

工作区，即文件目录

工作区有一个隐藏目录.git，这个不算工作区，而是Git的版本库

Git的版本库里存了很多东西，其中最重要的就是称为stage（或者叫index）的暂存区，还有Git为我们自动创建的第一个分支master，以及指向master的一个指针叫HEAD。

前面讲了我们把文件往Git版本库里添加的时候，是分两步执行的：

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

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

假设新建文本文件working.txt 没有git add的话修改并不会显示相关修改信息

commit后暂存区没有内容，但test.txt仍可以通过git status查看是否修改过

working.txt git add后就可以看到修改信息了

丢弃工作区

git checkout -- test.txt

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

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

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

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

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

小结时间

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

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

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

删除文件：

rm test.txt

此时只有工作区的被删除，如果要把库中的文件也删除，则

git rm test.txt
git commit -m 'tip'

另一种情况是删错了，因为版本库里还有呢，所以可以很轻松地把误删的文件恢复到最新版本：

$ git checkout -- test.txt

 

 

GitHub

如何连接github

1 打开Shell（Windows下打开Git Bash），创建SSH Key：

$ ssh-keygen -t rsa -C "youremail@example.com"

这个时候，用户主目录下就会有一个.ssh文件夹，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，id_pub是公钥。

2 登陆GitHub，打开“Account settings”，“SSH Keys”页面：

然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容

3 最后，用户在本地提交到GitHub时就会要私钥解密公钥，然后GitHub就可以识别是否是真正的用户在提交

4GitHub允许提交多个公钥，即你可以用不同的电脑提交

添加远程库

1 现在GitHub上创建一个库，一般其他设置选默认

2 如果本地已有库，即已经git init，直接与GitHub远程库建立关系

git remote add origin https://github.com/testusername/test.git

在码云上添加的命令行则是这样的

git remote add origin https://gitee.com/testusername/test.git

3 然后就可以把本地库添加到远程库了

git push -u origin master #master为默认分支

4 若后续提交到与上次提交相同的分支，直接

git push origin master #master为默认分支

SSH警告

当你第一次使用Git的clone或者push命令连接GitHub时，会得到一个警告：

The authenticity of host 'github.com (xx.xx.xx.xx)' can't be established.
RSA key fingerprint is xx.xx.xx.xx.xx.
Are you sure you want to continue connecting (yes/no)?

这是因为Git使用SSH连接，而SSH连接在第一次验证GitHub服务器的Key时，需要你确认GitHub的Key的指纹信息是否真的来自GitHub的服务器，输入yes回车即可。

Git会输出一个警告，告诉你已经把GitHub的Key添加到本机的一个信任列表里了：

Warning: Permanently added 'github.com' (RSA) to the list of known hosts.

这个警告只会出现一次，后面的操作就不会有任何警告了。

如果你实在担心有人冒充GitHub服务器，输入yes前可以对照GitHub的RSA Key的指纹信息是否与SSH连接给出的一致。

从远程库中克隆库

$ git clone git@github.com:testuser/test.git #这是ssh协议的，也可使用https协议

 

分支管理

假设你准备开发一个新功能，但是需要两周才能完成，第一周你写了50%的代码，如果立刻提交，由于代码还没写完，不完整的代码库会导致别人不能干活了。如果等代码全部写完再一次提交，又存在丢失每天进度的巨大风险。

现在有了分支，就不用怕了。你创建了一个属于你自己的分支，别人看不到，还继续在原来的分支上正常工作，而你在自己的分支上干活，想提交就提交，直到开发完毕后，再一次性合并到原来的分支上，这样，既安全，又不影响别人工作。

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

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

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

你看，Git创建一个分支很快，因为除了增加一个dev指针，改改HEAD的指向，工作区的文件都没有任何变化！

不过，从现在开始，对工作区的修改和提交就是针对dev分支了，比如新提交一次后，dev指针往前移动一步，而master指针不变：

假如我们在dev上的工作完成了，就可以把dev合并到master上。Git怎么合并呢？最简单的方法，就是直接把master指向dev的当前提交，就完成了合并：

所以Git合并分支也很快！就改改指针，工作区内容也不变！

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

创建分支

git checkout -b dev #创建并切换
#相当于： 
git branch dev  #创建
git checkout dev #切换


#使用switch创建并切换
$ git switch -c dev #创建并切换到新的dev分支
$ git switch master #直接切换到已有的master分支


git branch #查看分支，前面加*号的即为当前分支

合并分支

git checkout master #合并前先回到合并到的分支
git merge dev #合并dev分支到当前分支master

删除分支

git branch -d dev #删除dev分支，无论当前分支是什么，都可以直接这样删除

 

解决冲突

假设两个分支都对readme.md修改，合并时可能会出现问题，即产生冲突

 

合并dev分支，请注意--no-ff参数，表示禁用Fast forward：

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

不使用Fast forward模式，merge后就像这样，dev的提交记录还在：

对比没有禁用fast farword，dev的提交记录不在了

 

bug分支

1 当你接到一个修复一个代号101的bug的任务时，很自然地，你想创建一个分支issue-101来修复它，但是，等等，当前正在dev上进行的工作还没有提交 

并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

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

git stash

3 随后在master上修复bug，切换到master修复，修复完后合并到master上，再删除bug分支

4 切换到dev分支，发现这个时候工作区是干净的

$ git switch dev
Switched to branch 'dev'

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

5 查看暂存的工作现场

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge

6 恢复

一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；

另一种方式是用git stash pop，恢复的同时把stash内容也删了：

7 在master分支上修复了bug后，我们要想一想，dev分支是早期从master分支分出来的，所以，这个bug其实在当前dev分支上也存在。

那怎么在dev分支上修复同样的bug？重复操作一次，太麻烦了

8 为了方便操作，Git专门提供了一个cherry-pick命令，让我们能复制一个特定的提交到当前分支：

$ git branch
* dev
  master
$ git cherry-pick 4c805e2
[master 1d4b803] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)

最后 又会产生一个新的提交，虽然与cherry-pick所复制的4c805e2操作相同，但终究是不一样的提交

 

强制删除

开发一个新feature，最好新建一个分支；

如果要丢弃一个没有被合并过的分支，可以通过git branch -D <name>强行删除。

 

多人协作

推送分支

 git push origin master

多人协作的工作模式通常是这样：

1. 首先，可以试图用git push origin <branch-name>推送自己的修改；

2. 如果推送失败，则因为远程分支比你的本地更新，需要先用git pull试图合并；

3. 如果合并有冲突，则解决冲突，并在本地提交；

4. 没有冲突或者解决掉冲突后，再用git push origin <branch-name>推送就能成功！

如果git pull提示no tracking information，则说明本地分支和远程分支的链接关系没有创建，用命令git branch --set-upstream-to <branch-name> origin/<branch-name>。

这就是多人协作的工作模式，一旦熟悉了，就非常简单。

rebase略

 

标签管理

创建标签

#首先切到需要打标签的分支上，然后再打标签
git tag V1.0
#给某一个commit添加标签
git tag v0.9 f52c633

git tag -a <tagname> -m "blablabla..."#可以指定标签信息
git tag                               #可以查看所有标签

标签打错了，也可以删除：

$ git tag -d v0.1

如果要推送某个标签到远程，使用命令git push origin <tagname>：

$ git push origin v1.0
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
 * [new tag]         v1.0 -> v1.0

或者，一次性推送全部尚未推送到远程的本地标签：

$ git push origin --tags
Total 0 (delta 0), reused 0 (delta 0)
To github.com:michaelliao/learngit.git
 * [new tag]         v0.9 -> v0.9

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：

$ git tag -d v0.9
Deleted tag 'v0.9' (was f52c633)

然后，从远程删除。删除命令也是push，但是格式如下：

$ git push origin :refs/tags/v0.9
To github.com:michaelliao/learngit.git
 - [deleted]         v0.9

 

。。。。。待补充。。。。。

 

文章参考，侵权删

https://www.cnblogs.com/utank/p/12180531.html

廖雪峰的网站https://www.liaoxuefeng.com/wiki/896043488029600/896954074659008