git简单操作
git init
git remote add origin git@github.com:BrouceLee/aaa.git
删除key: git remote rm origin
git status
git add .
git commit -m " "
git push origin master git push --set-upstream origin hbl
git log 提交的日志
git reset [id] 回退版本到暂存区(结合log)
创建分支命令：
git branch (branchname)
git checkout -b (branchname) 命令来创建新分支
切换分支命令:
git checkout (branchname)
合并分支：
git merge [branch2] 最后还要git push
切换并创建分支branch2
git checkout -b branch2
git pull 从远程仓库把文件抓下来
git push 把本地文件推上远程仓库
git pull old-origin master 把上上个版本的master pull到本地。
修改远程仓库地址
git remote set-url origin https://github.com/qyf404/box.git
发现可以在pull命令后紧接着使用--allow-unrelated-history选项来解决问题（该选项可以合并两个独立启动仓库的历史）。
git pull origin master --allow-unrelated-histories
配置多个 ssh key
ssh-keygen -t rsa -C "你的邮箱账号" -f id_rsa_company
一台电脑上配置多个git的ssh key
前几天公司的代码库全部迁移到了阿里云上，在配置git的ssh key的时候遇到了一个问题，那就是自己的密钥在添加时提示已经存在，原来是自己的个人账号上已经添加过这个密钥了，公司分配的账号就不能再添加这个了。
于是只能在电脑上再配置一个ssh key; 即在一台电脑上配置多个git的ssh key。
一、生成ssh key
ssh-keygen -t rsa -C "你的邮箱账号" -f id_rsa_company
-f后面跟的就是生成的密钥的名称
会提示输入密码，直接回车不设置密码（设置后每次和git交互时都需要输入密码）；成功后会在当前文件夹下生成2个文件，其中 .pub文件就是待会放置到阿里云的公钥。然后将生成的2个文件放到.ssh目录下。
二、配置密钥位置
在 .ssh 目录中创建一个名为config文件，在里面添加相关配置；下面这个是我的配置：
# github
Host github.com
HostName github.com
RSAAuthentication yes
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_github
# 阿里云-个人账号
Host code.aliyun.com
HostName code.aliyun.com
RSAAuthentication yes
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_aliyun
# 阿里云-公司账号
Host company
HostName code.aliyun.com
RSAAuthentication yes
PreferredAuthentications publickey
IdentityFile ~/.ssh/id_rsa_company配置说明：
Host 映射名称（在下载代码时需要将实际的）
HostName git服务器的实际域名
RSAAuthentication yes
PreferredAuthentications publickey
IdentityFile 私钥文件地址Host 映射名称说明：在下载代码时需要将git服务器的实际域名改为这个映射名称。
比如代码仓库地址为：
git@code.aliyun.com:demo/demo.git；在我们克隆代码时需要将地址改为git@company:demo/demo.git才可以正常获取代码。
解决方案 git@github.com出现Permission denied (publickey)
ubentu 13.10 git version 1.8.3.2 解决方案：ssh -T git@github.com出现Permission denied (publickey).的问题
今天的任务是把项目通过git上传的github内，于是就出现了Permission denied (publickey)这个问题，现在我把自己的解决方案分享给大家。
一般来说，大家在给文件起名的时候，总会起一些自己喜欢的名字，楼主也不例外在使用命令：
ssh-keygen生成ssh 密钥的时候，会在
Enter file in which to save the key ("当前所在路径"): “给文件起个名字”这里随便起一个名字，这样问题就出来了，你起的这个名字没有和ssh内设定的名字保持一致，所以使用命令
ssh -T git@github.com的时候报出Permission denied (publickey).这个错误
当出现这个问题时，有两个比较简单的解决办法：
1) 给文件起名字的时候使用 ‘ id_rsa ’ 这个名字
2) 如果亲非要自己取名子，那就使用
ssh-add ~/.ssh/你的名字将自己起的名字加入到ssh中
这样再使用
ssh -T git@github.com就会看到你想要的效果了。
注：在生成密钥的时候，请在 “ ~/.ssh/ ”目录下操作。或者生成后把文件移动到“ ~/.ssh/ ”目录下。
也可以用：
ssh-add -l 查看加入的密钥列表
ssh -v git@github.com 查看调试信息
如果有问题或不准确的地方，请大家及时批评指教，谢谢！
打开这个～/.ssh/id_rsa.pub文件，把里面的所有的内容都拷贝到你的github网站的ssh key里
在github的右上角edit your profile 里找到ssh key，然后add ssh key，把东西拷贝到key就可以了，title随便填。
执行ssh-add时出现Could not open a connection to your authentication agent
若执行ssh-add /path/to/xxx.pem是出现这个错误:Could not open a connection to your authentication agent，则先执行如下命令即可：
ssh-agent bash
hexo clean
hexo d -g
https://blog.csdn.net/pzm1993/article/details/79980258
给git 打标签 https://git-scm.com/book/zh/v2/Git-%E5%9F%BA%E7%A1%80-%E6%89%93%E6%A0%87%E7%AD%BE
2.6 Git 基础 - 打标签
打标签
像其他版本控制系统（VCS）一样，Git 可以给仓库历史中的某一个提交打上标签，以示重要。 比较有代表性的是人们会使用这个功能来标记发布结点（ v1.0 、 v2.0 等等）。 在本节中，你将会学习如何列出已有的标签、如何创建和删除新的标签、以及不同类型的标签分别是什么。
列出标签
在 Git 中列出已有的标签非常简单，只需要输入 git tag （可带上可选的 -l 选项 --list）：
$ git tag
v1.0
v2.0这个命令以字母顺序列出标签，但是它们显示的顺序并不重要。
你也可以按照特定的模式查找标签。 例如，Git 自身的源代码仓库包含标签的数量超过 500 个。 如果只对 1.8.5 系列感兴趣，可以运行：
$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5|
Note
|
按照通配符列出标签需要
-l 或 --list 选项如果你只想要完整的标签列表，那么运行 然而，如果你提供了一个匹配标签名的通配模式，那么 |
创建标签
Git 支持两种标签：轻量标签（lightweight）与附注标签（annotated）。
轻量标签很像一个不会改变的分支——它只是某个特定提交的引用。
而附注标签是存储在 Git 数据库中的一个完整对象， 它们是可以被校验的，其中包含打标签者的名字、电子邮件地址、日期时间， 此外还有一个标签信息，并且可以使用 GNU Privacy Guard （GPG）签名并验证。 通常会建议创建附注标签，这样你可以拥有以上所有信息。但是如果你只是想用一个临时的标签， 或者因为某些原因不想要保存这些信息，那么也可以用轻量标签。
附注标签
在 Git 中创建附注标签十分简单。 最简单的方式是当你在运行 tag 命令时指定 -a 选项：
$ git tag -a v1.4 -m "my version 1.4"
$ git tag
v0.1
v1.3
v1.4-m 选项指定了一条将会存储在标签中的信息。 如果没有为附注标签指定一条信息，Git 会启动编辑器要求你输入信息。
通过使用 git show 命令可以看到标签信息和与之对应的提交信息：
$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Date: Sat May 3 20:19:12 2014 -0700
my version 1.4
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number输出显示了打标签者的信息、打标签的日期时间、附注信息，然后显示具体的提交信息。
轻量标签
另一种给提交打标签的方式是使用轻量标签。 轻量标签本质上是将提交校验和存储到一个文件中——没有保存任何其他信息。 创建轻量标签，不需要使用 -a、-s 或 -m 选项，只需要提供标签名字：
$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5这时，如果在标签上运行 git show，你不会看到额外的标签信息。 命令只会显示出提交信息：
$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Author: Scott Chacon <schacon@gee-mail.com>
Date: Mon Mar 17 21:52:11 2008 -0700
changed the version number后期打标签
你也可以对过去的提交打标签。 假设提交历史是这样的：
$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiment'
a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support
0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc added a commit function
4682c3261057305bdd616e23b64b0857d832627b added a todo file
166ae0c4d3f420721acbb115cc33848dfcc2121a started write support
9fceb02d0ae598e95dc970b74767f19372d61af8 updated rakefile
964f16d36dfccde844893cac5b347e7b3d44abbc commit the todo
8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 提交。 你可以在之后补上标签。 要在那个提交上打标签，你需要在命令的末尾指定提交的校验和（或部分校验和）：
$ git tag -a v1.2 9fceb02可以看到你已经在那次提交上打上标签了：
$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5
$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Date: Mon Feb 9 15:32:16 2009 -0800
version 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Author: Magnus Chacon <mchacon@gee-mail.com>
Date: Sun Apr 27 20:43:35 2008 -0700
updated rakefile
...共享标签
默认情况下，git push 命令并不会传送标签到远程仓库服务器上。 在创建完标签后你必须显式地推送标签到共享服务器上。 这个过程就像共享远程分支一样——你可以运行 git push origin <tagname>。
$ git push origin v1.5
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
Total 14 (delta 3), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.5 -> v1.5如果想要一次性推送很多标签，也可以使用带有 --tags 选项的 git push 命令。 这将会把所有不在远程仓库服务器上的标签全部传送到那里。
$ git push origin --tags
Counting objects: 1, done.
Writing objects: 100% (1/1), 160 bytes | 0 bytes/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To git@github.com:schacon/simplegit.git
* [new tag] v1.4 -> v1.4
* [new tag] v1.4-lw -> v1.4-lw现在，当其他人从仓库中克隆或拉取，他们也能得到你的那些标签。
|
Note
|
git push 推送两种标签使用 |
删除标签
要删除掉你本地仓库上的标签，可以使用命令 git tag -d <tagname>。 例如，可以使用以下命令删除一个轻量标签：
$ git tag -d v1.4-lw
Deleted tag 'v1.4-lw' (was e7d5add)注意上述命令并不会从任何远程仓库中移除这个标签，你必须用 git push <remote> :refs/tags/<tagname> 来更新你的远程仓库：
第一种变体是 git push <remote> :refs/tags/<tagname> ：
$ git push origin :refs/tags/v1.4-lw
To /git@github.com:schacon/simplegit.git
- [deleted] v1.4-lw上面这种操作的含义是，将冒号前面的空值推送到远程标签名，从而高效地删除它。
第二种更直观的删除远程标签的方式是：
$ git push origin --delete <tagname>检出标签
如果你想查看某个标签所指向的文件版本，可以使用 git checkout 命令， 虽然这会使你的仓库处于“分离头指针（detached HEAD）”的状态——这个状态有些不好的副作用：
$ git checkout 2.0.0
Note: checking out '2.0.0'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch>
HEAD is now at 99ada87... Merge pull request #89 from schacon/appendix-final
$ git checkout 2.0-beta-0.1
Previous HEAD position was 99ada87... Merge pull request #89 from schacon/appendix-final
HEAD is now at df3f601... add atlas.json and cover image在“分离头指针”状态下，如果你做了某些更改然后提交它们，标签不会发生变化， 但你的新提交将不属于任何分支，并且将无法访问，除非通过确切的提交哈希才能访问。 因此，如果你需要进行更改，比如你要修复旧版本中的错误，那么通常需要创建一个新分支：
$ git checkout -b version2 v2.0.0
Switched to a new branch 'version2'如果在这之后又进行了一次提交，version2 分支就会因为这个改动向前移动， 此时它就会和 v2.0.0 标签稍微有些不同，这时就要当心了。
git rebase
rebase命令在git中是一个非常有魅力的命令，使用得当会极大提高自己的工作效率；相反，如果乱用，会给团队中的其他人带来麻烦。它的作用简要概括为：可以对某一段线性提交历史进行编辑、删除、复制、粘贴；因此，合理使用rebase命令可以使我们的提交历史干净、简洁！
rebase基础
当你想起rebase命令时，你的脑海里是不是浮现出如下的画面：
https://zhuanlan.zhihu.com/p/387438871
Git Stash命令的使用
1、使用场景
在远程仓库拉取代码之后，需要修改仓库中的某些配置文件才能够正常将工程运行起来。但是，改动后的文件会影响Git正常的拉取操作(Git会提示先处理本地的改动才可以拉取)。
这时候，比较方便的做法是将本地的修改用stash命令保存。之后，工作区就成了一个“干净”的状态，可以进行正常的拉取操作。
拉取完成之后，可以再通过stash命令将之前stash的内容再“取出”到工作区，这样就可以重新运行工程。
由于stash保存的内容，可以跨分支进行“取出”。在上面的场景中，功能算是比较强大了。
2、git stash介绍
运行git help stash命令，可以看到这个命令的帮助：
NAME
git-stash - Stash the changes in a dirty working directory away
DESCRIPTION
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
The modifications stashed away by this command can be listed with git stash list, inspected with git stash show, and restored (potentially on top of a different commit) with git stash apply. Calling git stash without any arguments is equivalent to git stash push. A stash is by default listed as "WIP on branchname ...", but you can give a more descriptive message on the command line when you create one.
The latest stash you created is stored in refs/stash; older stashes are found in the reflog of this reference and can be named using the usual reflog syntax (e.g. stash@{0} is the most recently created stash, stash@{1} is the one before it, stash@{2.hours.ago} is also possible). Stashes may also be referenced by specifying just the stash index (e.g. the integer n is equivalent to stash@{n}).
意思就是说：
git-stash - 将一个修改后的工作区中的改动保存起来，将工作区恢复到改动前的状态。
具体描述：
当你想要保存工作区的当前状态，并想要回到一个干净的工作目录时，可以使用git stash命令。该命令保存本地修改，并将工作区恢复到HEAD指向的commit状态。
git stash保存的内容可以通过命令“git stash list”列出，可以通过“git stash show”命令查看，可以通过“git stash apply”命令恢复(可以恢复到不同的commit/分支上)。不加任何参数调用“git stash”命令等同于“git stash push”。Stash信息默认展示为"WIP on branchname ..."，但是你可以在stash命令执行的时候，添加相关描述性的信息。
创建的最新的stash信息保存在"refs/stash"，稍微早一点的stash可以通过这个引用的reflog查看，也可以通过通常的reflog语法命名规则指代。比如“stash@{0}”表示最新创建的stash，“stash@{1}”是更早些的stash。stash也可以只通过序号指代，比如"n"代表"stash@{n}"。
3、例子
3.1 下面是一个连续的stash保存并取出的例子
查看最近一次提交：
$ git log -1
commit 1eff7133816e9e77d34c25dd63e017ab899bf490 (HEAD -> master, origin/master)
Author: XiaCheng <xxxxxxx@icloud.com>
Date: Fri Mar 8 18:57:40 2019 +0800
add doing mark
改动一个工作区中的文件：
$ echo "asdf" >> style.css
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
将对工作区的修改用stash命令保存：
$ git stash
Saved working directory and index state WIP on master: 1eff713 add doing mark
$ git status
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
再次修改工作区中的一个文件：
$ echo "qwer" >> style.css
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
用stash命令保存，并添加描述信息：
$ git stash save "add qwer to style.css"
Saved working directory and index state On master: add qwer to style.css
查看stash列表：
$ git stash list
stash@{0}: On master: add qwer to style.css
stash@{1}: WIP on master: 1eff713 add doing mark
恢复最近一次stash的保存内容：
$ git stash apply stash@{0}
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
$ git status
On branch master
Your branch is up to date with 'origin/master'.
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
3.2 git stash跨分支
由于git stash保存的内容还没有提交，所以，这些内容不是基于分支的(和具体分支没有关系)，而是基于工作区的。下面是一个例子。
接着前面的例子，我们首先将之前的修改复位，然后新建一个分支testBra，并修改style.css：
$ git checkout -- style.css
$ git checkout -b testBra
Switched to a new branch 'testBra'
localhost:todo_man chengxia$ echo "test branch" >> style.css
localhost:todo_man chengxia$ git status
On branch testBra
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -am "add test content on testBra"
[testBra d9b757d] add test content on testBra
1 file changed, 1 insertion(+), 1 deletion(-)
接下来，我们取出之前通过stash命令保存的内容：
$ git stash list
stash@{0}: On master: add qwer to style.css
stash@{1}: WIP on master: 1eff713 add doing mark
$ git stash apply stash@{0}
Auto-merging style.css
CONFLICT (content): Merge conflict in style.css
$ git status
On branch testBra
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
$ vim style.css
这时，提示冲突如下：
3.2.1 git add标识冲突解决
这时候，我们可以采用通常的git add命令标识冲突已经解决，如下：
$ git add style.css
$ git status
On branch testBra
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
modified: style.css
$
但是，这样有时候，并不是我们想要的，因为我们后续可能并不想将这个文件的修改提交，这时可以通过git reset命令标识冲突解决。
3.2.2 git reset标识冲突解决
首先，我们需要先将工作区复位。
unstage：
$ git reset HEAD style.css
Unstaged changes after reset:
M style.css
$ git status
On branch testBra
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
复位修改：
$ git checkout -- style.css
localhost:todo_man chengxia$ git status
On branch testBra
nothing to commit, working tree clean
$ git status
On branch testBra
nothing to commit, working tree clean
重新将stash@{0}恢复：
Auto-merging style.css
CONFLICT (content): Merge conflict in style.css
$ git status
On branch testBra
Unmerged paths:
(use "git reset HEAD <file>..." to unstage)
(use "git add <file>..." to mark resolution)
both modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
再次提示冲突，这次，改用git reset命令标识冲突已经解决。
$ git reset
Unstaged changes after reset:
M style.css
$ git status
On branch testBra
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: style.css
no changes added to commit (use "git add" and/or "git commit -a")
注：这里在解决文件冲突的时候，没有修改文件内容，一般来说，我们需要将文件内容修改为我们想要的之后(去掉标识冲突的<<<<<<、>>>>>>和======等标记)，再标识冲突已经解决。
4、git stash命令参考
- （1）
git stash save "save message": 执行存储时，添加备注说明。 - （2）
git stash list：查看stash列表。 - （3）
git stash show：显示具体做了哪些改动，默认显示第一个stash存储，如果要显示其他存储，后面加stash@{$num}，比如第二个git stash show stash@{1}。 - （4）
git stash apply：应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即stash@{0}，如果要使用其他个，添加git stash apply stash@{$num}，比如第二个git stash apply stash@{1}。 - （5）
git stash pop：命令恢复之前缓存的工作目录，将缓存堆栈中的对应stash删除，并将对应修改应用到当前的工作目录下，默认为第一个stash,即stash@{0}，如果要应用并删除其他stash存储，命令：git stash pop stash@{$num}。 - （6）
git stash drop stash@{$num}：删除stash@{$num}存储。 - （7）
git stash clear：删除所有缓存的stash存储。
新增的文件，直接执行stash是不会被存储的。需要先用git add命令将其添加到git暂存区，才可以被git stash保存。
怎么修改git merge的默认信息
Git merge 默认的提交信息是合并时自动生成的。如果你想要修改这个默认信息，可以在执行 merge 命令时使用 -m 选项来提供自定义的提交信息。
例如，如果你想要合并一个分支并提供自定义的提交信息，你可以这样做：
git merge -m "自定义的合并提交信息" 分支名
如果你已经进行了 merge 操作，并且想要修改之前生成的自动提交信息，你可以使用 git commit --amend 命令来修改最近的提交信息。
例如：
git commit --amend -m "新的提交信息"
