testCommands.txt

注：内容来自廖雪峰老师网站教程


this is a pure test txt with no other use!
maybe i will success this time!

another try without introductions!
just try!

learn structures!

how does checkout works ?

打开本地仓库之前需要先使用cd命令切换到当前的repo文件下

创建一个版本库非常简单，首先，选择一个合适的地方，创建一个空目录：
$ mkdir learngit
$ cd learngit
$ pwd
/Users/michael/learngit
pwd命令用于显示当前目录。在我的Mac上，这个仓库位于/Users/michael/learngit
第二步，通过git init命令把这个目录变成Git可以管理的仓库：
$ git init
Initialized empty Git repository in /Users/michael/learngit/.git/

git init 本地库初始化
git status 查看当前状态

git add filename 添加文件
git log 查看历史记录

git reflog 记录曾使用过的命令  可以用于查看可回退的版本

git reset --hard  哈希索引值/HEAD^2 回退版本
git commit -m "commit message" (filename)   缓存区的文件添加到仓库中


git diff filename 对比文件不同之处

工作区在本地
版本库分为 stage暂存区 和  master分支(自动创建)
master分支有一个指针叫HEAD

add & commit 命令用于提交数据
git管理的是修改而非文件本身

git checkout -- readme.txt  放弃工作区的修改（即将工作区的文件同步到与暂存区或者版本库一致，如果最近一次add了，就用暂存区的去同步，如果commit了就用版本库的去同步）
注意 -- 和  filename 之间必须有空格

git reset HEAD <file>可以把暂存区的修改撤销掉（unstage），重新放回工作区

错误修改三种：
一、只恢复工作区的，使用git checkout -- filename命令
二、错误已经提交到暂存区，可以先使用git reset head filename的命令撤销暂存区修改，再使用checkout命令恢复工作区修改（当然直接使用checkout命令也可以撤销工作区的修改）
三、已经提交到本地版本库，则使用版本回退reset（哈希索引）去回退版本，前提是未提交到远程库,然后执行21命令

rm filename  删除文件
在暂存区删除后，如果想版本库中也删除，则需要commit

创建远程仓库
先cd ~到主目录下
若没有.ssh文件，则执行如下命令$ ssh-keygen -t rsa -C "735591266@qq.com"
若有.ssh文件，再看看这个目录下有没有id_rsa和id_rsa.pub这两个文件，如果已经有了，可直接跳到下一步

如果一切顺利的话，可以在用户主目录里找到.ssh目录，里面有id_rsa和id_rsa.pub两个文件，这两个就是SSH Key的秘钥对，id_rsa是私钥，不能泄露出去，id_rsa.pub是公钥，可以放心地告诉任何人。
登陆GitHub，打开“Account settings”，“SSH Keys”页面：
然后，点“Add SSH Key”，填上任意Title，在Key文本框里粘贴id_rsa.pub文件的内容
点“Add Key”，你就应该看到已经添加的Key

在本地的learngit仓库下运行命令：
$ git remote add origin git://github.com/yourgithubname/localREPO.git

把本地库的所有内容推送到远程库上：
$ git push -u origin master

把本地库的内容推送到远程，用git push命令，实际上是把当前分支master推送到远程。
由于远程库是空的，我们第一次推送master分支时，加上了-u参数，Git不但会把本地的master分支内容推送的远程新的master分支，还会把本地的master分支和远程的master分支关联起来，在以后的推送或者拉取时就可以简化命令。
从现在起，只要本地作了提交，就可以通过命令：
$ git push origin master
把本地master分支的最新修改推送至GitHub，现在，你就拥有了真正的分布式版本库！
第一次出现警告直接输入yes回车即可

回到终端，进行SSH确认连接
输入命令：ssh -T Git@github.com

若出错请按照下面链接解决
https://www.cnblogs.com/gzdaijie/p/5186516.html


首先，我们创建dev分支，然后切换到dev分支：

$ git checkout -b dev
Switched to a new branch 'dev'
git checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev
$ git checkout dev
Switched to branch 'dev'
然后，用git branch命令查看当前分支：
$ git branch
* dev
  master
git branch命令会列出所有分支，当前分支前面会标一个*号。

在分支上修改工作区文件 add和commit
切换至master  $ git checkout master

把dev分支的工作成果合并到master分支上：$ git merge dev
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。

master



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

解决冲突 多个分支修改了统一文件的代码块或者文件名，则必须手动修改一致，否则无法合并。
可以用vim打开文件，删除或修改冲突代码。然后add 和commit 之后才能够合并分支。然后再push。

用git log --graph命令可以看到分支合并图。


$ git merge --no-ff -m "merge with no-ff" dev  不删除分支的合并


Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支
$ git checkout master
$ git checkout -b issue-101

$ git stash list查看工作现场
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了：

Bug分支
阅读: 349093
软件开发中，bug就像家常便饭一样。有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。

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

$ git status
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

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:   readme.txt
并不是你不想提交，而是工作只进行到一半，还没法提交，预计完成还需1天时间。但是，必须在两个小时内修复该bug，怎么办？

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

$ git stash
Saved working directory and index state WIP on dev: f52c633 add merge
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。

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

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git checkout -b issue-101
Switched to a new branch 'issue-101'
现在修复bug，需要把“Git is free software ...”改为“Git is a free software ...”，然后提交：

$ git add readme.txt 
$ git commit -m "fix bug 101"
[issue-101 4c805e2] fix bug 101
 1 file changed, 1 insertion(+), 1 deletion(-)
修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：

$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
  (use "git push" to publish your local commits)

$ git merge --no-ff -m "merged bug fix 101" issue-101
Merge made by the 'recursive' strategy.
 readme.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
太棒了，原计划两个小时的bug修复只花了5分钟！现在，是时候接着回到dev分支干活了！

$ git checkout dev
Switched to branch 'dev'

$ git status
On branch dev
nothing to commit, working tree clean
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：

$ git stash list
stash@{0}: WIP on dev: f52c633 add merge
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：

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

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

$ git stash pop
On branch dev
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   hello.py

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:   readme.txt

Dropped refs/stash@{0} (5d677e2ee266f39ea296182fb2354265b91b3b2a)
再用git stash list查看，就看不到任何stash内容了：

$ git stash list
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0}


<p>
    1. master 上面发布的是A的1.0版本
</p>
<p>
    2、dev 上开发的是A的2.0版本
</p>
<p>
    3、这时，用户反映 1.0版本存在漏洞，有人利用这个漏洞开外挂
</p>
<p>
    4、需要从dev切换到master去填这个漏洞，正常必须先提交dev目前的工作，才能切换（必须提交，否则无法切换，只add也不行，因为之前我们说过，checkout会覆盖本地的更改）
</p>
<p>
    5、而dev的工作还未完成，不想提交，所以先把dev的工作stash一下。然后切换到master
</p>
<p>
    6、在master建立分支issue101并切换.
</p>
<p>
    7、在issue101上修复漏洞。
</p>
<p>
    8、修复后，在master上合并issue101
</p>
<p>
    9、切回dev，恢复原本工作，继续工作。
</p>
<p>
    <br/>
</p>
<p>
    对应的操作：
</p>
<p>
    1.  git stash  ： 保存dev当前的工作现场
</p>
<p>
    2.  git checkout master ： 切换到master
</p>
<p>
    3.  git checkout -b issue-101 ：创建专门用于解决bug的 issue101分支
</p>
<p>
    4.  git add readme.txt ： 解决bug后，添加到暂存区
</p>
<p>
    5.  git commit -m "fix bug 101" ： 提交
</p>
<p>
    6.  git checkout master ：切回到master
</p>
<p>
    7.  git merge --no-ff -m "merged bug fix 101" issue-101 ：合并解决bug的分支
</p>
<p>
    8.  git branch -d issue-101 ： 删除用于解决bug的分支
</p>
<p>
    9.  git checkout dev ：切回到dev分支
</p>
<p>
    10. git stash apply ：恢复工作现场
</p>
<p>
    11. git stash drop    ：删除工作现场内容
</p>
<p>
    12. 10和12两步也可以直接用git stash pop恢复的同时把stash内容也删了
</p>
<p>
    <br/>
</p>

$ git branch -D feature-vulca   删除未合并的分支

git remote (-v)   查看远程库

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：

$ git puc++ 和sh origin master
如果要推送其他分支，比如dev，就改成：
$ git push origin dev
但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？
master分支是主分支，因此要时刻与远程同步；
dev分支是开发分支，团队所有成员都需要在上面工作，所以也需要与远程同步；
bug分支只用于在本地修复bug，就没必要推到远程了，除非老板要看看你每周到底修复了几个bug；
feature分支是否推到远程，取决于你是否和你的小伙伴合作在上面开发



$ git tag v1.0
可以用命令git tag查看所有标签：
$ git tag
历史版本打标签$ git tag v0.9 f52c633   （先$ git log --pretty=oneline --abbrev-commit）
可以用git show <tagname>查看标签信息

还可以创建带有说明的标签，用-a指定标签名，-m指定说明文字：
$ git tag -a v0.1 -m "version 0.1 released" 1094adb


如果要推送某个标签到远程，使用命令git push origin <tagname>：
一次性推送全部尚未推送到远程的本地标签：
$ git push origin --tags

如果标签已经推送到远程，要删除远程标签就麻烦一点，先从本地删除：
$ git tag -d v0.9
然后，从远程删除。删除命令也是push，但是格式如下：
$ git push origin :refs/tags/v0.9