git book

官方中文文档--https://git-scm.com/book/zh/v2

 

git branch -help (显示命令行说明)

git branch --help (打开网页版说明)

git在线游戏 https://learngitbranching.js.org/

 

 文件目录: D:\Forever\www.draw.io\git\git命令流程图.xml

 

上图源自: 我痛恨 Git 的 10 个理由==>https://www.oschina.net/news/26598/10-things-i-hate-about-git

远程仓库repository

 

本地添加远程仓库(低频)
步骤1: git remote add origin git@gitee.com:KingBoBo/testgit.git
(和远程仓库建立关联,但不能正常push pull)

(https模式免输帐号密码模式直接在添加远程仓库 git remote add origin https://username:password@kingtool.top/KingBoBo/testgit.git）

 

步骤2.1:git pull origin master
(不管git远程仓库是否为空,都会报错)

步骤2.2:git push origin master
(

如果git远程仓库是空的,那就不用步骤3了,不会报错,成功开启远程push pull关联 , 
如果git远程仓库是空的,但又是刚 init 初始化的仓库,从来没有add并commit过,是不能push的,会报错error: src refspec master does not match any .
如果git远程仓库是非空的,那就会报错,还是得从步骤3开始

)

 

步骤3:git pull origin master --allow-unrelated-histories
(关联后拉取远程仓库的master分支,第一次的时候需要开启 允许不相关历史参数 --allow-unrelated-histories,自测之后感觉远程仓库非空时,还是加该参数最保险)
(可以不用步骤2,直接使用步骤3,让远程和本地不同的历史可以合并)

步骤4:此时可以正常push 和 pull了

如果push还是有问题, 那就使用 git push --set-upstream origin master 命令push,应该就可以了

 

(以上模式可以让本地文件夹和仓库名保持互不干扰,允许不一致)

 

 

本地克隆远程仓库(高频)
git clone git@gitee.com:KingBoBo/testgit.git

如果不小心关联了错误的远程库

git remote -v #查看远程库信息

git remote rm origin #删除远程仓库

git remote add origin remoteGitAddress #最后重新使用关联git远程库

 

如何关联多个远程库
先关联github的远程库：
git remote add github git@github.com:michaelliao/learngit.git
接着，再关联码云的远程库：
git remote add gitee git@gitee.com:liaoxuefeng/learngit.git
推送到github:
git push github master
推送到gitee:
git push gitee master

 

git服务器和客户端配置ssh key

第一步:

 可以在Linux上执行, 也可以在gitbash命令工具中执行ssh-keygen命令

生成之后在User/.ssh/目录下会看到 id_rsa 和 id_rsa.pub 

ssh-keygen -t  rsa -C "xxxxx@qq.com" 

id_rsa.pub内容如下

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCqXZ/gMCN.......................................................................................................................................................................................................................................................................................................................................................................

第二步:

将其复制到Setting | SSH Keys | Key 中

 

 

第三步:

 

 

进入项目目录,复制项目 SSH地址 

 

 

第四步:

 在gitbash 中执行 git clone git@gitlab.kingtool.top:admin-public/xxxyyyzzz.git 下载项目到本地电脑

 

 

 

 

 git for windows配置SSH key==>https://www.cnblogs.com/zjfjava/p/10080569.html

 

head

head

HEAD可以指向分支，也可以指向提交。

orig_head

查看内容，其实存放的也是commit。当进行一些有风险的操作的时候，如reset、merge或者rebase，Git会将HEAD原来所指向commit对象的sha-1值存放于ORIG_HEAD文件中

fetch_head

FETCH_HEAD表示某个branch在服务器上的最新状态。
每一个执行过fetch操作的项目都会存在一个FETCH_HEAD列表，其中每一行对应于远程服务器的一个分支。
当前分支指向的FETCH_HEAD, 就是这个文件第一行对应的那个分支。存在两种情况：如果没有显式的指定远程分支, 则远程分支的master将作为默认的FETCH_HEAD；如果指定了远程分支, 就将这个远程分支作为FETCH_HEAD.

detached_head

如果没有fetch的话, 本地仓库的master对比远程仓库origin/master还是一致的.

当执行 git checkout commit的时候，也就是指向提交，会变成detached HEAD的状态。

此时如果不留心，继续进行修改提交，可能会被git回收，从而丢失代码。最好的做法是新建一个分支，再进行代码相关操作。

 

本小节参考自: Git学习系列15 HEAD ORIG_HEAD FETCH_HEAD detached HEAD==>https://blog.csdn.net/luoshabugui/article/details/85256509

 

.gitignore文件配置

打开C:/Users/YourUserName/.gitconfig添加excludesfile参数并指定其值为Java.gitignore完整路径, 其中 name和email 可以指定提交时的用户信息, 使用git log可以看到.

[user]
    name = Jinjb
    email = 123456@qq.com
[http]
    sslVerify = false
[gui]
    encoding = utf-8
[alias]
    dog = log --all --decorate --oneline --graph -18  
    cam = commit -a -m  
    mt = mergetool  
    cp = cherry-pick  
[i18n]
    commitencoding = utf-8
    logoutputencoding = utf-8
[core]
    excludesfile = C:/Users/King/Java.gitignore
    autocrlf = true

autocrlf解释: https://blog.csdn.net/chaiyu2002/article/details/81261432

 

新建一个文件C:/Users/YourUserName/Java.gitignore 

打开https://github.com/github/gitignore 查看Java.gitignore 复制其内容粘贴到新建文件中,并在尾部追加

.classpath
.project
.settings
target

取消已关联的文件

 

在文件被add或commit关联前,可以提前加.gitignore来配置.
在文件被add或commit关联后,只能使用下面的命令来取消本地追踪.
git update-index --assume-unchanged filepath   (忽略filepath文件)
git update-index --no-assume-unchanged filepath  (取消忽略filepath文件)

filepath样例：

*.a # 忽略所有 .a 结尾的文件
!lib.a # 但 lib.a 除外
/TODO # 仅仅忽略项目根目录下的 TODO 文件，不包括 subdir/TODO
build/ # 忽略 build/ 目录下的所有文件
doc/*.txt # 会忽略 doc/notes.txt 但不包括 doc/server/arch.txt

.idea/ # 无效,原因未知, 需要写成.idea/*.xml才可以把.idea文件夹下的xml文件无视掉

 

git update-index --assume-unchanged 找出所有被忽略的文件的办法==>https://blog.csdn.net/DaSunWarman/article/details/79384307
但是忽略的文件多了，想找出所有被忽略的文件，暂时找到下面的办法:
git ls-files -v | grep \'^h\ \'1
提取文件路径，方法如下
git ls-files -v | grep \'^h\ \' | awk \'{print $2}\'1
所有被忽略的文件，取消忽略的方法，如下
git ls-files -v | grep \'^h\' | awk \'{print $2}\' |xargs git update-index --no-assume-unchanged

---------------------

本文来自 DaSunWarman 的CSDN 博客 ，全文地址请点击：https://blog.csdn.net/DaSunWarman/article/details/79384307?utm_source=copy

另外在使用--assume-unchanged时如果file指定的文件目前本来就没被追踪过, 那么会报fatal: Unable to mark file XXX 错, 这是正常的。

在eclipse中取消已关联的文件

 

删除已关联的.idea文件夹

在初始化git仓库的时候没有创建.gitignore文件来过滤不必要提交的文件, 后来却发现某些文件不需要提交, 但是这些文件已经被提交了, 这时候创建.gitignore文件忽略这些文件时, 发现ignore的规则对那些已经被track的文件无效.

其实.gitignore文件只会忽略那些没有被跟踪的文件, 也就是说ignore规则只对那些在规则建立之后被新创建的新文件生效. 因此推荐: 初始化git项目时就创建.gitignore文件.

可以使用上一小节的--assume-unchanged,也可以使用下面的方式

$ git rm -r --cached .idea
rm \'.idea/encodings.xml\'
rm \'.idea/misc.xml\'
rm \'.idea/modules.xml\'
rm \'.idea/testgit.iml\'
rm \'.idea/vcs.xml\'
rm \'.idea/workspace.xml\'

 

提交时最好注释下删除了哪些文件 "deleteSomeIdeaFiles" , 指定具体哪些文件夹或文件

$ git commit -m deleteSomeIdeaFiles
[f1 9b4b52b] delete_.idea_Folder
 6 files changed, 638 deletions(-)
 delete mode 100644 .idea/encodings.xml
 delete mode 100644 .idea/misc.xml
 delete mode 100644 .idea/modules.xml
 delete mode 100644 .idea/testgit.iml
 delete mode 100644 .idea/vcs.xml
 delete mode 100644 .idea/workspace.xml

 

$ git push

 

 

git bcompare整合

$github merge tool 可视化的合并工具==》https://blog.csdn.net/tidus5/article/details/8765602

git bcompare整合==>https://www.cnblogs.com/frostbelt/p/5994105.html

 Windows下使用Beyond Compare作为git的比对与合并工具==>https://blog.csdn.net/paincupid/article/details/49909997

如果在git gui使用Run Merge Tool报如下错,couldn\'t execute "meld": no such file or directory表示没有配置mergetool工具，解决方式有两种， 见后文

 

 

方式一: git bash 命令行配置

依次输入以下两条命令,会直接在.gitconfig中生成方式二对应的配置
git config --global diff.tool bc3
git config --global difftool.bc3.path "D:/OldPC/G/big soft/bccompare/beyond compare/beyond compare/BCompare.exe"

方式二: 修改C:\Users\用户名\.gitconfig（推荐）

在文件末尾添加如下配置，注意是否已存在相同配置，注意[diff]是对比，merge是合并，在命令行中可以通过git difftool XXX, git mergetool XXX来调出bcompare

[user]
    name = Jinjb
    email = 359920692@qq.com
[http]
    sslVerify = false
[gui]
    encoding = utf-8

[diff]
    tool = bc3
[difftool "bc3"]
    path = D:/OldPC/G/big soft/bccompare/beyond compare/beyond compare/BCompare.exe
[difftool]
    prompt = false
[merge]
    tool = bc3
[mergetool "bc3"]
    path = "D:/OldPC/G/big soft/bccompare/beyond compare/beyond compare/BCompare.exe"
[mergetool]
    keepBackup = false
    trustExitCode = false

 

 

 git+bcompare效果

我自己的成功配置文件并没有连接中介绍的需要加那么多额外参数,仅仅添加完BCompare.exe文件路径就可以成功了

 

 

 

给独立的项目添加签名

 

 

fetch和 pull的区别

Git中从远程的分支获取最新的版本到本地有这样2个命令：
1. git fetch：相当于是从远程获取最新版本到本地，不会自动merge, 如果没有fetch的话, 本地仓库的master对比远程仓库origin/master还是一致的.

Git fetch origin test
git log -p test..origin/test  #不明白
git merge origin/test

    以上命令的含义：

•    首先从远程的origin的test主分支下载最新的版本到origin/test分支上
•    然后比较本地的test分支和origin/test分支的差别
•    最后进行合并

   上述过程其实可以用以下更清晰的方式来进行：

git fetch origin test:tmp
git diff tmp 
git merge tmp

从远程获取最新的版本test分支到本地的tmp分支上 , 再进行比较合并

2. git pull：相当于是从远程获取最新版本并merge到本地

git pull origin master

上述命令其实相当于git fetch 和 git merge

在实际使用中，git fetch更安全一些，因为在merge前，我们可以查看更新情况，然后再决定是否合并

本小节完全引用自 : 【git之】fetch和 pull的区别--https://www.cnblogs.com/gyjx2016/p/6822113.html

其它参考: git提交本地分支到远程分支==>https://www.cnblogs.com/ydxblog/p/7988317.html

$$$$$ git fetch, git pull 以及 FETCH_HEAD==>https://www.cnblogs.com/Venom/p/5477367.html

 

首先，git fetch 有四种基本用法

1. git fetch            →→ 这将更新git remote 中所有的远程repo 所包含分支的最新commit-id, 将其记录到.git/FETCH_HEAD文件中

2. git fetch origin         →→ 这将更新名称为origin 的远程repo上的所有branch的最新commit-id，将其记录。 

3. git fetch origin remote_branch_name        →→ 这将这将更新名称为origin 的远程repo上的分支： remote_branch_name

4. git fetch origin remote_branch_name:local_branch_name       →→ 这将更新名称为origin 的远程repo上的分支： remote_branch_name ，并在本地创建local_branch_name 本地分支保存远端分支的所有数据。(波波已验证,确实会创建新分支)

FETCH_HEAD： 是一个版本链接，记录在本地的一个文件中，指向着目前已经从远程仓库取下来的分支的末端版本。

git pull : 首先，基于本地的FETCH_HEAD记录，比对本地的FETCH_HEAD记录与远程仓库的版本号，然后git fetch 获得当前指向的远程分支的后续版本的数据，然后再利用git merge将其与本地的当前分支合并。
所以 git pull = git fetch + git merge FETCH_HEAD
本小段参考自：https://www.cnblogs.com/ToDoToTry/p/4095626.html

 git add 操作

git add . ：将文件的修改，文件的新建，添加到暂存区。

git add -u：将文件的修改、文件的删除，添加到暂存区。

git add -A：将文件的修改，文件的删除，文件的新建，添加到暂存区。

 git commit 操作

修改最近一次提交的注释,会产生新的commitId,但是多次执行也还是只会有一个commitId , 只是每次把最近HEAD指身听那个commit顶替掉

git commit --amend

 git pull操作

git pull后代码不是最新更新的，这时在排除不是项目提交不成功的情况下（可在远程仓库上查看），可使用命令

git pull origin master

git fetch, merge, pull, push需要注意的地方（转）--https://www.cnblogs.com/softidea/p/4967616.html

 

 

git diff

假设远端库名是 origin，你要比较的本地分支为 test，远端分支是master

#获取远端库信息
git fetch origin master
#做diff
git diff test origin/master

本地分支的话，直接

git diff branchA branchB

，而远程分支的话，

git diff branchA remoteB/branchB

区别就是远程分支前面要加上remote名称, 一般remote名称就是origin

 

Git diff结果显示分析-->https://www.cnblogs.com/renyuan/p/9017077.html

diff 工作区和其它文件对比

 

 

git diff 文件对比
filepath意为比较指定文文件, filepath不能以/开头 , 不加filepath则比较的是所有文件
1. git diff filepath (当前工作区与暂存区比较)  等于 git diff --cached filapath
2. git diff HEAD filepath (当前工作区与本地仓库的当前分支比较)
3. git diff branchName filepath  (当前工作区与本地仓库的其它branchName分支进行比较)
4. git diff commitId filepath (当前工作区与某一次提交的commitId分支进行比较)
5. git diff origin/branch-name filepath (当前工作区与远程任意分支进行比较)
1.--5. 然而上面1到5,还会根据暂存区此时是否add的新东西(git status 有绿色),而有不一样的对比效果,最好指定两者成如下6-11的形式:

6. git diff --staged HEAD filepath (暂存区与本地仓库的当前分支比较,也可以简写成git diff --staged或--cached filepath)
7. git diff --staged branchName filepath (暂存区与本地仓库的其它分支比较)

8. git diff HEAD commitId filepath (本地仓库的当前分支与某一次提交commitId分支进行比较)
9. git diff HEAD origin/branch-name filepath (本地仓库的当前分支与远程仓库的任意分支进行比较)

10. git diff branchName origin/branch-name filepath (本地仓库的其它branchName分支的文件与远程任意分支进行比较)
11. git diff origin/branch-nameA origin/branch-nameB filepath (远程任意分支A与远程任意分支B进行比较)

Git diff 常见用法==>https://www.cnblogs.com/qianqiannian/p/6010219.html

stash暂存

stash是栈操作, 后进先出(后push的先pop), 不过也可以让 指定下标的暂存区先pop.

git stash (暂存工作区)
git stash list (查看暂存列表,最近stash的为{0},在最上面)
git stash apply stash@{0}(恢复暂存的工作区)
git stash drop  stash@{0}(删除暂存的工作区)
git stash pop (恢复并删除最近的一次暂存工作区,相当于apply + drop 操作,但遇到冲突或有本地修改时是不会自动删除的)

 

reset

git reset HEAD^ <file> 丢弃index的<file>文件的修改,直接回退到commit版的前一版,所以执行两次reset HEAD^是回退了2个版本,而不是回退到同一个版本,也就是说会叠加回退 (可以恢复git rm 的文件)

举例说明,假如有以下6个提交
commit9(current)
commit8
commit7
commit6
commit5
commit4

第一次git reset HEAD^ 将index区回退到commit8版本,
再一次git reset HEAD^^ 将index区回退到commit6版本.

 

git reset commitId <file> 可以回退到commit的dd71版,如果本地文件和回退的dd71版有差异,则以本地文件为标准 (用于恢复误删的文件, 所以还是用commitId的回退比较稳定 , 比如 git reset 7d28te readMe.md , 默认为 --mixed)

git reset --hard HEAD^^ 强行回退(还原)到上上个版本,如果文件有冲突需要用--hard 
git reset HEAD~100 回退到前100个版本 (不常用)
git reset 4d26 (4d26必须大于等于4位 , 会失弃index的所有修改,直接回退到commit的4d26版)

当本地工作区add了文件到暂存区却想要撤消的时候，并不是再次把暂存区的内容撤回到本地工作区， 而其实是把本地仓库的内容覆盖回了暂存区。（自我理解）

git checkout -- <file>命令中的--很重要，没有 -- ，就变成了“切换到另一个分支”的命令。

reset 还有三个参数 --soft --mixed --hard

reset soft mixed(默认) hard	本地工作区	暂存区	本地仓库	远程	说明
git reset --soft commitId	无变化	无变化	HEAD指针移动	无变化	#把head指向commitId
git reset --mixed commitId	无变化	变成HEAD指向	HEAD指针移动	无变化	#把head指向commitId, 把index暂存区重置成commitId的内容,默认为mixed
git reset --hard commitId	变成HEAD指向	变成HEAD指向	HEAD指针移动	无变化	#把head指向commitId, 把index暂存区重置成commitId的内容, 把工作区重置成暂存区的内容

 

参考自: git reset soft,hard,mixed之区别深解==>https://www.cnblogs.com/kidsitcn/p/4513297.html

 

 

git reset 三种模式的区别：

1. --hard：重置位置的同时，直接将 working Tree工作目录、 index 暂存区及 repository 都重置成目标Reset节点的內容,所以效果看起来等同于清空暂存区和工作区。

2. --soft：重置位置的同时，保留working Tree工作目录和index暂存区的内容，只让repository中的内容和 reset 目标节点保持一致，因此原节点和reset节点之间的【差异变更集】会放入index暂存区中(Staged files)。所以效果看起来就是工作目录的内容不变，暂存区原有的内容也不变，只是原节点和Reset节点之间的所有差异都会放到暂存区中。

3. --mixed（默认）：重置位置的同时，只保留Working Tree工作目录的內容，但会将 Index暂存区 和 Repository 中的內容更改和reset目标节点一致，因此原节点和Reset节点之间的【差异变更集】会放入Working Tree工作目录中。所以效果看起来就是原节点和Reset节点之间的所有差异都会放到工作目录中。  

 

1. 亲测后发现以上第3点并不标准 ,  只读说明 https://www.processon.com/view/link/60476d3007912947636f027e
2. 源文件编辑 https://processon.com/diagraming/604767a46376897969e8c5c6

以上三行完全引用自: Git Reset 三种模式==>https://www.jianshu.com/p/c2ec5f06cf1a

 

 

merge和rebase区别

流程图 https://www.processon.com/view/link/5c874970e4b0c996d35f6a5a

思维导图 https://www.processon.com/view/link/5c88ca68e4b09a16b9a0d18f

merge时尽量用--no-ff 模式 , 不管merge和 rebase下图都是从f2分支的角度去观察的 , git merge branchName 处理提交log是按照时间戳先后顺序的.

黄色为变动情况,灰色为原始节点. 注意大小写的cC和eE,大写的CE都是新的commitID.

下图中的abcde节点都是我把a.txt的内容分别改成abcde单个字符后的节点.所以模拟的是每次都有冲突的场景.

上图目录备注 D:\Forever\www.draw.io\git\merge_rebase.xml

 

当在f2分支使用git rebase f1 时, 如果f2有和f1完全相同的提交,那么会舍弃f2上相同的commitID而保留f1 , 而且rebase过程中f2的节点是先被移除,拼接上f1的节点后再装回去的, 所以在mergetool合并的时候会发现本地版本竟是f1的版本, 远程版本才是f2的版本, 不过基线BASE却还是f2的上一个commitId. 

在rebase的操作时会有几个步骤,取决于当前f2分支和目标分支f1已经在分叉点开始提交了多少新的commit,像本样例就是2步, 所以一开始处于(f2|REBASE 1/2)

• 如果当前步骤的解决冲突结果完全同f1本地分支,那么应该使用git rebase --skip跳过本步骤,不然无法进行下一个冲突合并.
• 如果当前步骤的解决冲突结果不同于f1本地分支, 那么可以使用git rebase --continue 继续下一个步骤,而不需要git rebase --skip, 其实大多数情况是本场景.

 

$$$$$https://www.jianshu.com/p/4a8f4af4e803
rebase铁则:决不要在公共分支(比如master分支上)使用rebase命令.
再三强调: 千万不要通过rebase对任何已经提交到公共仓库中的commit进行修改（你自己一个人玩的分支除外）


git rebase master(on branch f2,rebase master分支)

git rebase --continue 继续下一个衍合

git rebase --skip 则会将引起冲突的commits丢弃掉, 另外在衍合时,如果用了左边的Local(本样例为f1),那么需要skip之后才能继续到rebase 2/2步,因为rebase是以目标分支为基础的, 所以目标分支才是Local,此时skip就相当于是不改变,沿本地的Local.
 把当前分支f2和目标分支f1的 共同最近祖先节点到f1分支最后一次提交的节点 并入当前f2分支 git am --show-current-patch 查看当前补丁(该命令完全意义不明)

知乎用户回答  在开发过程中使用git rebase还是git merge，优缺点分别是什么？==>https://www.zhihu.com/question/36509119/answer/67828312

两个使用场景是不一样的，merge只是合并另外一个分支的内容，rebase也合并另外一个分支的内容，但是会把本分支的commits顶到最顶端

假设我们现在有3个分支

1. master分支：线上环境使用的分支
2. testing分支：测试环境使用的分支
3. my_feature分支：开发新功能的分支，也就是当前分支

A. 假设我在my_feature上开发了一段时间，之后另外的同事开发的功能正式上线到master分支了，那么我可以在当前的分支下rebase一下master分支，这样我这个分支的几个commits相对于master还是处于最顶端的，也就是说rebase主要用来跟上游同步，同时把自己的修改顶到最上面，关于rebase的使用，我们更应该把它当成一种在提交到服务器之前清理本地提交历史的手段，而不当成合并的唯一手段。

B. 我在my_feature上开发了一段时间了，想要放到testing分支上，那就切到testing，然后merge my_feature进来，因为是个测试分支，commits的顺序无所谓，也就没必要用rebase (当然你也可以用rebase)

 

一般我们使用衍合的目的，是想要得到一个能在远程分支上干净应用的补丁，比如某个项目你不是维护者，但是想帮点忙，最好使用衍合处理。
先在自己的一个分支进行开发，当准备向主项目提交补丁的时候，根据最新的orgin/master进行一次衍合操作然后再提交，这样维护者就不需要任何整合工作。

实际为：把解决分支补丁同最新主干代码之间的冲突的责任，划转给由提交补丁的人来解决。
作为维护项目的人只需要根据你提供的仓库地址做一次快进合并，或者直接采纳你提交的补丁。

衍合的风险，请务必遵循如下准则：
一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作。所以本样例意为如果f2已经提交到了远程仓库,那么就不要再rebase其它分支了. @from

 

小结:

merge会丢弃目标分支的所有commit， 重新生成一个新的commit\' ,          这样其实在当前主分支上看着还是比较干净的, 但是查看所有分支时比较凌乱.

rebase会保留目标分支的部分commitId,在当前分支上复制出很多commit ,这样在当前主分支上看着会有很多commit点, 但是查看所有分支时比较清晰.

 

参考:　git rebase简介(基本篇)==>https://blog.csdn.net/hudashi/article/details/7664631

相同文章：　git rebase简介(基本篇)＝＝＞https://www.cnblogs.com/whatlonelytear/p/10518788.html

 【Git】rebase 用法小结--https://www.jianshu.com/p/4a8f4af4e803

 

如果一个人commit莫名奇妙地冲突了,就rebase一下

经常只有自己一个人commit的项目,提交一下宛然就冲突了, 不知道什么原因导致了这个鬼畜现象,重新rebase一下就行, 频率还挺高, 也是许我哪里操作不规范.

$ git status
On branch devtest
Your branch and \'origin/devtest\' have diverged,
and have 1 and 1 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

 

$ git dog
* dd3d7fb (HEAD -> devtest) 增加查询功能
| * afc0a57 (origin/devtest) 增加登录功能
|/
* e355799 增加注册功能

$ git rebase afc0a57
First, rewinding head to replay your work on top of it...
Applying: 增加查询功能
Using index info to reconstruct a base tree...
M src/main/java/com/ngari/www/dao/impl/BedReservationDaoImpl.java
M src/main/java/com/ngari/www/dao/impl/PropertyDaoImpl.java
Falling back to patching base and 3-way merge...

$ git dog
* dd3d7fb (HEAD -> devtest) 增加查询功能
* afc0a57 (origin/devtest) 增加登录功能
* e355799 增加注册功能

使用TortoiseGit处理代码冲突

当使用git status时出现如下信息时,表示将有代码冲突了

On branch f2
Your branch and \'origin/f2\' have diverged,
and have 1 and 3 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

 

场景一 

user0 有新提交

user1 没有pull -> 写新代码 -> pull -> 提示有冲突

 

解决办法一

-> stash save(把自己的代码隐藏存起来) -> 重新pull -> stash pop(把存起来的隐藏的代码取回来 ) -> 代码文件会显示冲突 -> 右键选择edit conficts，解决后点击编辑页面的 mark as resolved ->  commit&push

 

解决办法二

(尽量少使用，这种方法的优点是在在原编辑器里处理冲突，代码逻辑看得更清楚一些)

-> stash save(把自己的代码隐藏存起来) -> 重新pull -> stash pop(把存起来的隐藏的代码取回来 ) -> 代码文件会显示冲突 -> 右键选择resolve conflict -> 打开文件解决冲突 -> commit&push

 

 

场景二(推荐)

user0 有新提交

user1 没有pull -> 写新代码 -> commit&push -> 提示有冲突

 

解决办法一

-> pull -> 代码文件会显示冲突 -> 右键选择edit conficts，解决后点击编辑页面的 mark as resolved ->  commit&push

 

总结

把改动的东西都先commit(不push) ， 绝对不会错。

 

本小节完全引用自: 使用TortoiseGit处理代码冲突==>https://www.cnblogs.com/jason-beijing/p/5718190.html

 

rebase -i 交互模式

https://www.processon.com/view/link/5c886de6e4b01e76977c5930

原始log

$ git dog
* 210b8d8 (HEAD -> f2, origin/f2) 6
* 827b667 5
* 63cdbd9 4
* 353a260 3
* 4d05795 2
* a54de53 1
* 5b13a7e aa 
King@DESKTOP-BRRD683 MINGW64 /k/mycode/git/testgit (f2) 

 

 $ git rebase -i  4d05795 827b667 (该命令最终会让分支detached)

pick 353a260 3

squash 63cdbd9 4

squash 827b667 5

 

此时仍处于detached状态,

我们需要使用git reset --hard 4a7887b,让f2的HEAD强行指向最新的commitID 4a7887b

由于是把4,5 压缩到了3中,所以其实4a7887b的内容和827b667的是一样的,

一般情况我们会使用git reset -i commitId HEAD 来压缩最新提交到之前的commitId提交中

 

 

 bisect [baɪˈsekt] 二分查找bug

 

 https://www.processon.com/view/link/5c88785be4b0f88919abb12b

# 开始 bisect
$ git bisect start
 
# 录入正确的 commit
$ git bisect good xxxxxx
 
# 录入出错的 commit
$ git bisect bad xxxxxx
 
# 然后 git 开始在出错的 commit 与正确的 commit 之间开始二分查找，这个过程中你需要不断的验证你的应用是否正常
$ git bisect bad
$ git bisect good
$ git bisect good
...
 
# 直到定位到出错的 commit，退出 bisect

 

 

cherry-pick

git cherry-pick commit1 commit2 commit3  (但在我自己使用过程中, 不能一起cherry-pick 多个, 只能 一个一个cherry-pick)

意本像摘草莓一样把任意分支的commit1,commit2,commit3摘下来放到当前所在分支中, 当然被摘的那些分支还是没有变化的, 而不是摘下来就没了 , 即整合其它分支上的部分功能时使用比较合适。

另外使用分支f1 cherry-pick分支f2上的commit1时, (个人感觉会把f1暂存, 以f2分支作为基础, 把f1中的提交塞回f2中, 因为发现base文件内容是commit2的前一个提交commit )  如果冲突后最终还是保留了分支f1的内容, 那相当于pick了空,此时还需要继续的话,要么 git commit --allow-empty , 要么直接 git cherry-pick --abort 。  

https://www.processon.com/view/link/5c88ca68e4b09a16b9a0d18f

tag使用

git tag <tagname>   (打标签: 比如git tag v1.0.1)
git tag (查看标签)
git tag v0.9 f52c633 (针对某一commit id打标签
git tag -a <tagname> -m "blablabla..." (可以指定标签信息)
git tag -d <tagname> (删除标签)
git push origin <tagname> (推送一个本地标签)
git push origin --tags (推送全部未推送过的本地标签)

git tag -d <tagname> (可以删除一个本地标签)
git push origin :refs/tags/<tagname> (删除一个远程标签,最好先删除本地标签)

patch使用

Git的Patch功能【转】==>https://www.cnblogs.com/whatlonelytear/p/10523228.html

IDEA 使用补丁 patch==>https://blog.csdn.net/LitongZero/article/details/83012196 (很实用)

删除分支

git branch -d branch1    删除本地分支branch1（当前分支必须在非branch1分支时,才可以删除）

git push origin --delete branch1    #删除远程分支branch1

 

 

 

git迁移

git clone --bare git://github.com/username/project.git
git push --mirror git@gitcafe.com/username/newproject.git
git clone git@gitcafe.com/username/newproject.git

 

本小节参考自: 从一个git仓库迁移到另外一个git仓库==>https://blog.csdn.net/samxx8/article/details/72329002

我的git笔记

git clone http://
git status
git add .    添加到本地
git commit -m "增加一行代码" 本地提交

git log --pretty=oneline 查看版本
git push(origin branch1:branch1)    推送到远程库


假如其它人修改了
git fetch -v (以查看详情的模式更新到本地)
git checkout master(切换分支)
git branch -ra(查看远程和本地分支)
git tag (查看标签)
git tag v1.0.0 -m "生产版本 (在当前分支建标签,tag是不能修改的固定版)"
git branch bug129 (在当前分支下创建bug129分支,且此时只有local才有)
git init (在当前目录建一个脱离服务器的本地仓库)



https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001374831943254ee90db11b13d4ba9a73b9047f4fb968d000
廖雪峰总结
场景1：当你改乱了工作区某个文件的内容，想直接丢弃工作区的修改时，用命令git checkout -- file。
场景2：当你不但改乱了工作区某个文件的内容，还添加到了暂存区时，想丢弃修改，分两步，
    第一步用命令git reset HEAD <file>，就回到了场景1，
    第二步按场景1操作。
场景3：已经提交了不合适的修改到版本库时，想要撤销本次提交，参考版本回退一节，不过前提是没有推送到远程库。




https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/001375840038939c291467cc7c747b1810aab2fb8863508000
廖雪峰总结
查看本地分支：git branch
查看本地和远程分支：git branch -a
创建分支：git branch <BranchName>
切换分支：git checkout <BranchName>
创建+切换分支：git checkout -b <BranchName>
合并某分支到当前分支：git merge <BranchName>
删除本地仓库分支：git branch -d <BranchName>
删除远程仓库分支: git push origin --delete <BranchName>
强行推送本地分支内容,无视冲突,直接以本地为标准: git push origin master -f 

把本地工作文件切换成远程orign仓库所在分支文件:git checkout origin/master



查看分支合并情况
git log --graph --pretty=oneline --abbrev-commit     (oneline:单行显示日志 , abbrev:Abbreviation缩写)
git log --oneline 
git show commitID 查看提交情况
合并分支
git merge feature1

以非fastforward模式合并分支
git merge --no-ff -m "merge with no-ff" dev
注意:merge分支时会把目标分支删除的文件也一并删除

https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013760174128707b935b0be6fc4fc6ace66c4f15618f8d000
查看远程库信息，使用git remote -v；
本地新建的分支如果不推送到远程，对其他人就是不可见的；
从本地推送分支，使用git push origin branch-name，如果推送失败，先用git pull抓取远程的新提交；
在本地创建和远程分支对应的分支，使用git checkout -b branch-name origin/branch-name
(强调:本地和远程分支的名称最好一致,只有checkout远程仓库时才会使用到/)
建立本地分支和远程分支的关联，使用git branch --set-upstream origin/branch-name branch-name;(文章有误,此处已修正)
从远程抓取分支，使用git pull，如果有冲突，要先处理冲突。
git add -i 暂存区交互模式(interactive)
git add -p a.txt 
输入 y 来暂存该块
输入 n 不暂存
输入 e 手工编辑该块
输入 d 退出或者转到下一个文件
输入 s 来分割该块

 

显示所有日志

git log --all
a. 列出所有历史记录，最近的排在最上方
b. 如果记录过多，则按Page Up、Page Down、↓、↑来控制显示
c. 按q退出历史记录列表

 

 

遇见异常

Pull is not possible because you have unmerged files.

在git pull的过程中，如果有冲突，那么除了冲突的文件之外，其它的文件都会做为staged区的文件保存起来。 

git 冲突基本样例【原】==>https://www.cnblogs.com/whatlonelytear/p/10515244.html

 

error: src refspec master does not match any.

本地仓库刚创建,没有add,就想push

 

Your local changes to the following files would be overwritten by checkout

 有些时候，当我们使用 git checkout <branchname>命令切换分支的时候，有时会切换失败，然后出现以下的提示信息

error: Your local changes to the following files would be overwritten by checkout:
        .idea/compiler.xml
        .idea/workspace.xml
Please commit your changes or stash them before you switch branches.
Aborting

解决方法1(改动的文件/新增的文件很重要)

1.1

#第一种方式 存到暂存区
git add.
git stash 
#取出的时候使用 
git stash pop

1.2

#第二种方式 发起一个commit 存到提交历史
git add.
git commit -m "commit message"

 

 

解决方法2(改动的文件/新增的文件不重要)

此模式为删除未执行add的文件

2.1处理(推荐)

#这个是清除文件预览 , 主要用于清除未关联的文件,未add的文件
git clean -n  

#强制清除文件
git clean -f 

 

2.2暴力无视(不推荐)

# 使用-f 强制检出分支, 容易丢失文件,慎重
git checkout -f <branch> 

 

参考自:  Git-命令行-拯救“Your local changes to the following files would be overwritten by checkout”==>https://blog.csdn.net/qq_32452623/article/details/75645578

 

git换远程仓库地址

有三种方式, 本文只介绍最简单的修改config文件的方式

打开 项目目录下的.git/config文件 , 修改 url 地址成新地址即可

[remote "origin"]
url = git@gitee.com:KingBoBo/springboot-03-rabbitmq.git 

 

git 测试研究语句

echo \'1\' > a.txt
echo \'1\' > b.txt
git commit -m "1"
echo \'2\' > a.txt
echo \'2\' > b.txt
git commit -m "2"
echo \'3\' > a.txt
echo \'3\' > b.txt
git commit -m "3"

 

 

 

git私服

git clone git@git.isoftstones.com:/home/git/bobo.git

备份文 Git服务器搭建与使用【纯转】==>https://www.cnblogs.com/whatlonelytear/p/11059700.html

原文 Git私服搭建与使用==>https://segmentfault.com/a/1190000013999832

原文(权限) CentOS搭建Git服务器及权限管理==>https://www.cnblogs.com/fly_dragon/p/8718614.html

原文(权限) centos+git+gitolite 安装和部署==>https://www.cnblogs.com/ponyliu/p/5383096.html

原文 git私服==>https://www.cnblogs.com/jarl/p/6637751.html

他人建议

难用的SourceTree==>https://www.jianshu.com/p/3431bc8429a2

自我总结

不能checkout的原因: 本地工作区和暂存区有修改没有提交到本地仓库,没有add (当然也可以用stash存储)
不能merge的原因: 本地工作区和暂存区有修改没有提交到本地仓库,没有add (当然也可以用stash存储)

参考:

Eclipse中Egit冲突解决--http://blog.sina.com.cn/s/blog_4dd787e40102uysg.html

git原理图解--https://www.cnblogs.com/cb0327/p/5066685.html

Git 图解、常用命令和廖雪峰教程笔记总结--https://segmentfault.com/a/1190000008617626

windows上Git bash 查看log乱码==>https://blog.csdn.net/zhr349351/article/details/78066497

进阶

10 个迅速提升你 Git 水平的提示==>https://www.oschina.net/translate/10-tips-git-next-level?cmp&p=1

git-merge完全解析==>https://www.jianshu.com/p/58a166f24c81

系列文章

Git知识总览(一) 从 git clone 和 git status 谈起==>https://www.cnblogs.com/ludashi/p/8052739.html

Git知识总览(二) git常用命令概览==>https://www.cnblogs.com/ludashi/p/8053382.html

Git知识总览(三) 分支的创建、删除、切换、合并以及冲突解决==>https://www.cnblogs.com/ludashi/p/8093145.html

Git知识总览(四) git分支管理之rebase 以及 cherry-pick相关操作==>https://www.cnblogs.com/ludashi/p/8116434.html

Git知识总览(五) Git中的merge、rebase、cherry-pick以及交互式rebase==>https://www.cnblogs.com/ludashi/p/8213550.html?tdsourcetag=s_pctim_aiomsg

Git知识总览(六) Git分支中的远程操作实践==>https://www.cnblogs.com/ludashi/p/8323617.html

 

 

其它

Git使用总结(包含Git Bash和Git GUI的使用)==>https://blog.csdn.net/iabbg/article/details/80002260