我的工作笔记Git
持续更新...
Unix 哲学：“没有消息就是好消息”
Git，一个代码管理库
- feat：增加一个新功能
- fix：修复 bug
- docs：只修改了文档
- style：做了不影响代码含义的修改，空格、格式化、缺少分号等等
- refactor：代码重构，既不是修复 bug，也不是新功能的修改
- perf：改进性能的代码
- test：增加测试或更新已有的测试
- chore：构建或辅助工具或依赖库的更新
# VIM
进入vim编辑，写注释
*******************************************************************
1、k,j,h,l 光标上下左右 （也可以使用上下左右键）
2、o 在当前行下方插入新行并进入插入模式 (一般写注释，注释要详细)
3、:wq 保存并退出
注意：注释添加完毕后需要先将输入法切换为英文并按ESC键输入:wq指令后按Enter
*******************************************************************
2
3
4
5
6
7
# 工作区域和流程
# Workspace Directory
工作区，简言之就是你工作的区域，在开发的过程也就是对工作区的操作。对于 git 而言，就是的本地工作目录。工作区的内容会包含提交到暂存区和版本库(当前提交点)的内容，同时也包含自己的修改内容。此时文件处于 untracked（未追踪） 状态。
# Stage Area(又称索引区 Index | 暂存区域)
暂存区，将修改提交本地仓库前的一个过渡阶段。在工作目录下有一个.git 的目录，里面有个 index 文件，存储着关于暂存区的内容。当执行 git add 的命令后，工作区的文件就会被移入暂存区，暂存区标记了当前工作区中那些内容是被 Git 管理的，当完成某个需求或者功能后需要提交代码，第一步就是通过 git add 先提交到暂存区。 此时文件处于 unstaged 状态。
# Local Repository
本地仓库。版本控制系统的仓库，存在于本地磁盘。当执行 git commit 命令后，会将暂存区内容提交到本地仓库之中。在工作区下面有.git 的目录，这个目录下的内容不属于工作区，里面便是本地仓库的数据信息，暂存区相关内容也在其中。这里也可以使用 merge 或 rebase 将远程仓库副本合并到本地仓库。图中的只有 merge，注意这里也可以使用 rebase。
# Remote Repository
远程仓库，与本地仓库概念基本一致，不同之处在于一个存在远程，可用于远程协作，一个却是存在于本地。用来托管代码的服务器，远程仓库的内容能够被分布在多个地点的处于协作关系的本地仓库修改，本地仓库修改完代码后通过 git push/pull 可实现本地与远程的交互。
# 远程仓库的本地副本
可以理解为存在于本地的远程仓库缓存。如需更新，可通过 git fetch/pull 命令获取远程仓库内容。使用 fech 获取时，并未合并到本地仓库，此时可使用 git merge 实现远程仓库副本与本地仓库的合并。git pull 根据配置的不同，可为 git fetch + git merge 或 git fetch + git rebase。
# 对象
# GIT 配置
本地 Git 仓库和 GitHub 仓库之间的传输是通过 SSH 加密的，因此 Git 需要绑定本地计算机环境的公钥。
# Git 绑定 SSH 步骤：
- 下载 Git 计算机对应系统版本。
- 打开 bash shell 在根目录 上运行命令 ssh-keygen 生成 .ssh 公\私钥文件：
ssh-keygen -t rsa -C "[youremail@example.com]"- 公钥：
id_rsa.pub - 私钥：
id_rsa
- 公钥：
- 以 Github 为例，进入 Github 网站，然后
Settings > SSH and GPG keys > 在SSH keys栏目点击New SSH key添加公钥id_rsa.pub。这一步等于说把你的公钥放到了 Github 上进行托管。 - 最后运行验证连通性：
ssh -T git@github.com - 全局配置 Git 的用户名和邮箱:
$ git config --global user.name "xxx"
$ git config --global user.email "xxx@xx.com"
$ git config --global core.autocrlf false # 修改git全局配置，禁止git自动将lf转换成crlf
$ git config --global core.eol lf # 配置全局git命令文件换行使用lf方式或者在terminal中对单个git代码仓库执行git config core.eol lf使用lf换行方式（这一步也可以不配置）
$ git config --global core.autocrlf input # 提交时转换为lf，检出时不转换
$ git config --global core.safecrlf true # 拒绝提交包含混合换行符的文件
2
3
4
5
6
7
完成以上几步，你就可以愉快 pull&push 代码了。
# HTTPS 与 SSH 区别
- HTTPS：不管是谁，拿到 url 随便 clone，但是在 push 的时候需要验证用户名和密码；
- SSH：clone 的项目你必须是拥有者或者管理员，而且需要在 clone 前添加 SSH Key。SSH 在 push 的时候，是不需要输入用户名的，如果配置 SSH key 的时候设置了密码，则需要输入密码的，否则直接是不需要输入密码的。
# Git 使用操作
# git config
Git 配置操作。
- 语法：
git config [<options>]
git config -l # 查用户配置
# 设置用户全局配置
git config --global user.name "xxx"
git config --global user.email "xxx@xx.com"
git config --global core.autocrlf false # 设置文件行结束符为lf模式
2
3
4
5
6
# git init
初始化 Git 仓库。
- 语法：
git init
git init # 创建创库
# git remote
配置、重命名、删除远程仓库操作。
在本地环境使用git init初始化 Git 仓库后，需要配置远程仓库的remote_label和远程仓库的remote_url，
其中remote_label用于平常的 Git 操作，通常命名为 origin、git、gitlab等，如：git push origin xxx, origin就是配置的remote_url。
remote_url就是远程仓库用于下载源码的链接，链接有两种方式分别为HTTPS和SSH。以 git 为例：
https://git.com/liejiayong/jtools.git
git@git.com:liejiayong/jtools.git
语法：
git remote [-v | --verbose]git remote add [-t <branch>][-m <master>] [-f][--tags | --no-tags] [--mirror=<fetch|push>] <name> <url>git remote rename <old> <new>git remote remove <name>git remote set-head <name> (-a | --auto | -d | --delete | <branch>)git remote [-v | --verbose] show [-n] <name>git remote prune [-n | --dry-run] <name>git remote [-v | --verbose] update [-p | --prune][(<group> | <remote>)...]git remote set-branches [--add] <name> <branch>...git remote get-url [--push][--all] <name>git remote set-url [--push] <name> <newurl> [<oldurl>]git remote set-url --add <name> <newurl>git remote set-url --delete <name> <url>
git remote add [remote_label] [remote_url] # 配置远程仓库
git remote rename [old_remote_label] [new_remote_label] # 远程仓库名称重设
git remote remove [remote_label] # 删除远程仓库配置
git remote set-url [remote_label] [remote_url] # 重新设置已配置的远程仓库的链接
2
3
4
5
6
7
# git mv
文件移动、重命名操作。
- 语法：
git mv [<options>] <source>... <destination>
git mv old_file new_file # 对已跟踪的文件进行重命名操作
git mv file folder # 移动file到folder
git mv file file1 file2 folder # 移动file、file1到folder
2
3
4
5
# git rm
文件删除操作。
- 语法：
git rm [<options>] [--] <file>...
git rm -rf file.js # 删除已跟踪的文件清单中的文件
# git status
Git 仓库状态操作。
- 语法：
git status [<options>] [--] <pathspec>...
git status # 查看仓库状态。默认详情状态
git status -s # 查看仓库简明状态
git status --show-stash # 查看仓库隐藏信息状m态
2
3
# git diff
查看 Git 仓库文档修改状态，显示修改字段。
- 语法：
git diff [<options>] [<commit>] [--][<path>...]git diff [<options>] --cached [<commit>][--] [<path>...]git diff [<options>] <commit> [--merge-base] [<commit>...] <commit> [--][<path>...]git diff [<options>] <commit>...<commit>] [--][<path>...]git diff [<options>] <blob> <blob>]git diff [<options>] --no-index [--] <path> <path>]
git diff # 查看仓库显示修改字段
# git log
查看 Git 当前分支的提交记录。
- 语法：
git log [<options>] [<revision-range>] [[--] <path>...]git show [<options>] <object>...
git log # 查看当前分支的提交记录
# git reflog
查看 Git 所有提交记录的历史操作记录。
- 语法：
git reflog [ show | expire | delete | exists ]
git reflog # 查看历史操作记录
git reflog show # 查看历史操作记录
2
# git add
工作区文件添加到暂存区。
- 语法：
git add [path_name]
git add . # 将当前工作区文件添加到暂存区
# git commit
暂存区文件添加到本地仓库。
- 语法：
git commit --[params] [commit_msg]
git commit -m "[commit_msg]" # 暂存区文件添加到本地仓库
git commit --amend # [commit_msg]内容写错，需要重新提交内容时使用
git commit -am # 等同于 git add . && git commit -m
2
3
# git push
# git rebase
控制版本的分支的基准
# git pull
# 从远程仓库拉取代码并合并到本地，可简写为 git pull 等同于 git fetch && git merge
git pull [remote_name] [branch_name]:[local_branch_name]
git pull [remote_name] [branch_name] # local_branch_name、branch_name名字相同时
# 使用rebase的模式进行合并
git pull --rebase [remote_name] [branch_name]:[local_branch_name]
2
3
4
5
6
# git fetch
与 git pull 不同的是 git fetch 操作仅仅只会拉取远程的更改，不会自动进行 merge 操作。对你当前工作区的代码没有影响
# 获取远程仓库特定分支的更新
git fetch [remote_name] [branch_name]
# 获取远程仓库所有分支的更新
git fetch --all
# 取回更新后，会返回一个FETCH_HEAD ，指的是某个branch在服务器上的最新状态，我们可以在本地通过它查看刚取回的更新信息：
git log -p FETCH_HEAD
# 将拉取下来的最新内容合并到当前所在的分支中
git merge FETCH_HEAD
# git拉取远程新分支到本地
git fetch origin develop
git checkout -b develop origin/develop
git pull origin develop
2
3
4
5
6
7
8
9
10
11
12
13
# git branch
分支的创建、删除、查看。
Git 中保存着一个名为 HEAD 的特别指针，这个指针指向了当前的工作分支。
切换分支，实际是切换 HEAD 指针的指向。
- 语法：
git branch --[params] [branch_name]
git branch # 查看分支状态
git branch -r # 查看远程分支
git branch -a # 查看本地和远程分支
git branch [branch_name] # 创建分支，但不切换
git branch -D [branch_name] # 删除本地分支
git branch -m [old_branch_name] [new_branch_name] # 重新命名分支
2
3
4
5
6
7
8
9
10
11
12
# git merge
合并分支。用于当前分支合并其他分支所有内容。
具体操作是，在需要合并的分支输入合并分支命令。
当合并分支时不想要被合并分支之前的 commit 提交记录，可以使用参数 --squash。
- 语法：
git merge [branch_name]
git merge <branch_name> # 当前分支合并branch_name分支
git merge <branch_name> --squash # 当前分支合并branch_name分支，且不合并branch_name分支的commit提交记录
git commit -m "<commit_msg>" # 当合并分支使用--squash后，需要重新提交commit记录
2
3
4
5
# git checkout
切换分支。还可以用于在切换分支时创建分支。
git checkout [branch_name] # 切换到branch_name分支
git checkout -b [branch_name] # 创建branch_name分支，并将当前分支切换到branch_name分支
git checkout --orphan [branch_name] # 创建无父节点的分支branch_name。此分支无拷贝当前所在分支的所有文件，且任何历史log。
git rm -rf . # 删除本分支下所有文件
2
3
4
5
6
# git reset
撤回已提交版本。
# 回退所有内容到上一个版本
git reset HEAD^
# 回退a.py这个文件的版本到上一个版本
git reset HEAD^ a.py
# 向前回退到第3个版本
git reset –soft HEAD~3
# 将本地的状态回退到和远程的一样
git reset –hard [remote_name]/[branch_name]
# 回退到某个版本057d
git reset 057d
# 回退到上一次提交的状态，按照某一次的commit完全反向的进行一次commit
git revert HEAD
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
共有三种模式：
--hard--soft-- mixed
# git reset --hard [commit_id] : 重置 暂存区 和 工作区
--hard 模式 会在重置 HEAD 和 branch 的指针位置 的同时，重置 暂存区 和 工作区里的内容。
此时，git commit 记录强制回溯到某一个提交节点 commit_id，同时 commit_id 之前的记录与修改内容会彻底删除。
换句话说，就是没有 git commit 的修改会被全部擦掉，已 git commit 的内容会在git log中删掉，需要在git reflog 中查找历史提交信息。
# git reset --soft [commit_id] : 保留工作区，并将已 commit 到仓库的内容放到暂存区
--soft 模式 会在重置 HEAD 和 branch 的指针位置 的同时，保留工作区和暂存区中的内容，并把重置 HEAD 指针位置 所带来的新的差异放进暂存区（将已 commit 到仓库的内容放到暂存区）。
什么是「重置 HEAD 所带来的新的差异」？重置 HEAD 和 branch 的指针位置，就等于 HEAD指针回退到上一个版本，类似于 HEAD@{1} 到 HEAD@{0} 的过程，但指针回退后已经被 git commit 的内容回本放到暂存区。
此模式保留了工作区的内容，同时将当前版本节点到目标版本节点的内容保留在暂存区，让其与重置前暂存区与工作区的内容保持一致。
此时可以直接执行 git add 和 git commit 分别将工作区、暂存区的内容提交到仓库，如果由于版本不同无法提交可以加-f处理git push [remote_name] [branch_name] -f。
--soft 如其名如柔软般撤回信息，除了回溯到节点 commit_id 外，还会保留最新节点的修改内容，类似于只撤回 git commit -m [commit_msg] 中的 提交信息 commit_msg。
所以当我们想合并「当前节点」与「reset 目标节点」之间不具太大意义的 commit 记录(可能是阶段性地频繁提交)時，可以考虑使用 Soft Reset 来让 commit 演进线图较为清晰点。
# git reset [commit_id] : 保留工作区，并将已 commit 到仓库的内容和暂存区放到工作区
git reset 不带参数则默认使用--mixed模式。
--mixed模式 会在重置 HEAD 和 branch 的指针位置 的同时，会保留工作目录，并将已 commit 到仓库的内容和暂存区放到工作区，并且清空暂存区。
换而言之，将工作区的修改、暂存区的内容以及由 reset 所导致的新的文件差异，都会被放进工作区。
简而言之，就是「把所有差异都混合（mixed）放在工作目录中」。
# 三种模式区别:
--hard: 重置指针位置的同时，将工作区、暂存区及仓库都重置回退到 [commit_id] 目标节点的内容。--soft: 重置指针位置的同时，保留工作区和暂存区的内容，只让仓库中的内容和 [commit_id] 目标节点保持一致。其中暂存区的内容是指，将原节点和 [commit_id] 目标节点之间的「差异变更集」会放入 暂存区中。--mixed（默认）: 重置指针位置的同时，只保留工作区的内容。其中工作区的内容是指，将原节点和 [commit_id] 目标节点之间的「差异变更集」会放入工作区中。
# 使用场景:
--hard:要放弃目前本地的所有改变時，即去掉所有 add 到暂存区的文件和工作区的文件，可以执行
git reset -hard HEAD来强制恢复 git 管理的文件夹的内容及状态；真的想抛弃目标节点后的所有
commit（可能觉得目标节点到原节点之间的 commit 提交都是错了，之前所有的 commit 有问题）。
--soft:- 使用--soft 合并
commit节点信息。假如想合并「当前节点」与「reset 目标节点」之间不具有太大意义的 commit 记录(可能是阶段性地频繁提交,就是开发一个功能的时候，改或者增加一个文件的时候就 commit，这样做导致一个完整的功能可能会好多个 commit 点，这时假如需要把这些 commit 整合成一个 commit 的时候)時，可以考虑使用git reset --soft [commit_id]来让 commit 演进线图较为清晰。
- 使用--soft 合并
--mixed（默认）:合并无意义的
commit，使 commit 演进线图较为清晰。与--soft相似，区别是需要多操作git add才能git commit。git add错误文件到暂存区。移除所有 Index 暂存区中准备要提交的文件(Staged files)，可以执行git reset HEAD来 Unstage 所有已列入 Index 暂存区 的待提交的文件。git commit提交某些错误代码，或者没有必要的文件也被 commit 上去，不想再修改错误再 commit（因为会留下一个错误 commit 点），可以回退到正确的 commit 点上，然后所有原节点和 reset 节点之间差异会返回工作目录，假如有个没必要的文件的话就可以直接删除了，再 commit 上去就 OK 了。
# 总结
git reset 的本质：所有模式都是通过 移动 HEAD 和 branch 的指针位置来实现重置。
git reset 指令虽然可以用来撤销 commit ，但它的实质行为并不是撤销，而是移动 HEAD ，并且「捎带」上 HEAD 所指向的 branch（如果有的话）。
也就是说，git reset 指令的行为其实和它的字面意思 "reset"（重置）十分相符：它是用来重置 HEAD 以及它所指向的 branch 的位置的。
而 git reset --hard HEAD^ 之所以起到了撤销 commit 的效果，是因为它把 HEAD 和它所指向的 branch 一起移动到了当前 commit 的父 commit 上，从而起到了「撤销」的效果：
Git 的历史只能往回看，不能向未来看，所以把 HEAD 和 branch 往回移动，就能起到撤回 commit 的效果。
所以同理，git reset --hard 不仅可以撤销提交，还可以用来把 HEAD 和 branch 移动到其他的任何地方。
譬如：可以将某个分支的代码完全覆盖另一个分支代码。
假设每个人有个开发分支，想隔一段时间就把自己的开发分支上的代码保持和测试分支一致，
以远程服务器名称为[remote_name]，分支有 [branch_dev]、[branch_test] 为例，则需要如下操作：
# 将test分支上的代码完全覆盖dev分支，首先切换到dev分支
git checkout [branch_dev]
# 然后直接设置代码给远程的test分支上的代码
git reset --hard [remote_name]/[branch_test]
# 或简写
git reset --hard [branch_test]
# 执行上面的命令后dev分支上的代码就完全被test分支上的代码覆盖了，注意只是本地分支，这时候还需要将本地分支强行推到远程分支。
git push -f
2
3
4
5
6
7
8
# 参考文献
# git revert
撤消操作。
git revert HEAD~3 #丢弃最近的三个commit，把状态恢复到最近的第四个commit，并且提交一个新的commit来记录这次改变。
git revert -n master~5..master~2 # 丢弃从最近的第五个commit（包含）到第二个（不包含）,但是不自动生成commit，这个revert仅仅修改working tree和index。
2
# git stash
将工作区修改的文件暂存起来，文件会被暂存到 stash 脏暂存区。
语法：
git stash save|list|show|drop|pop|apply|clear...使用场景：
主要用于保存当前工作区未提交的修改。例如有种场景：在 feature 分支做需求变动中，release 版本突然有缺陷需要处理，但是需求的代码因没开发完不能提交，所以需要先通过
git stash save [msg]将修改保存到本地缓存堆栈中，而且可以保存多个分支。然后切换到 hotfix 分支上进行 bug 的修复，修复完后切换回 feature，使用git stash apply [stash_hash]从本地缓存堆栈中恢复修改内容。pull 更新时保护本地修改的文件。
git stash # 把本地的改动暂存起来
git stash save "message" # 执行存储时，添加备注，方便查找。如查看记录：stash@{0}: On gp-blog: 我的工作笔记Git
git stash pop # 应用最近一次暂存的修改，并删除暂存的记录
git stash apply # 应用某个存储,但不会把存储从存储列表中删除，默认使用第一个存储,即 stash@{0}，如果要使用其他个，git stash apply --index [stash_num] 。
git stash list # 查看 stash 有哪些存储
git stash clear # 删除所有缓存的 stash
# 使用git stash 后，可查看记录hash
cat .git/refs/stash
cat .git/logs/refs/stash
cat .git/refs/heads/master
# 查看所有对象内容
git cat-file --batch-check --batch-all-objects
# 查询sha-1对应的文件内容.
git cat-file -p [sha-1]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
推荐：
- 需要暂存的时候，不要直接使用
git stash命令进行暂存下来，而是使用git stash save "message..."这种方式，给本次的提交做一个信息的记录。因为git stash list查看所有的暂存列表的时候会更清晰明了。 - 少用
git stash pop恢复暂存记录，改用为git stash apply --index [stash_num]的方式，因为 apply 不会清空已有的 stash 的列表项，并且能应用到当前的工作区，不需要这个暂存的话，再手动清除就可以了。
- 需要暂存的时候，不要直接使用
# 参考文档
# git tag
git 下打标签其实有 2 种情况
- 轻量级的：它其实是一个独立的分支,或者说是一个不可变的分支.指向特定提交对象的引用
- 带附注的：实际上是存储在仓库中的一个独立对象，它有自身的校验和信息，包含着标签的名字，标签说明，标签本身也允许使用 GNU Privacy Guard (GPG) 来签署或验证,电子邮件地址和日期，一般我们都建议使用含附注型的标签，以便保留相关信息
# git tag使用
创建、删除、查看标签操作。
# 创建本地tag
git tag -a [tag_name] -m [tag_msg]
# 提交本地tag
git push [remote_name] --tags
# 删除本地tag
git tag -d [tag_name]
# 删除远程tag
git push [remote_name> :refs/tags/<tag_name]
# 获取远程版本tag
git fetch [remote_name] tag [tag_name]
2
3
4
5
6
7
8
9
10
11
12
# 进阶
# 合并分支
# 合并分支所有提交的 [commit_hash]
语法：
git merge [branch_name]使用场景：
当需要在当前分支并入其他分支的完整提交时，那么就可以使用 git merge [branch_name]了。
git fetch 相当于是从远程获取最新到本地，不会自动merge
git fetch orgin master //将远程仓库的master分支下载到本地当前branch中
git log -p master ..origin/master //比较本地的master分支和origin/master分支的差别
git merge origin/master //进行合并
git pull：相当于是从远程获取最新版本并merge到本地
git pull origin master
git pull <远程主机名> <远程分支名>:<本地分支名>
# 将远程分支拉到本地
git fetch [remote_name] [branch_name]
# 创建自己本地分支并且关联远程分支
git checkout -b [local_remote_name] [remote_name]/[branch_name]
# 拉取最新远程分支代码
git pull origin [远程分支名]
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 合并分支指定提交的 [commit_hash]
- 语法：
git cherry-pick [commit_hash]git cherry-pick [first_commit_hash]...[last_commit_hash]: 连续 commit_hash 合并模式。一个左开右闭的区间，表示 first_commit_hash 提交带来的代码不会被合并过去git cherry-pick [first_commit_hash]^...[last_commit_hash]：连续 commit_hash 合并模式。表示包含 first_commit_hash 到 last_commit_hash 在内的提交都会被合并过去
cherry-pick 译为 精选，从字面意思即可知道，其可以挑选某分支的单个指定提交 [commit_hash] ，并作为一个新的提交引入到当前分支上。
- 使用场景：
当需要在当前分支并入其他分支的提交时，如果不想对其他整个分支进行合并，而是只想将其他分支的某一次提交并入到本地当前分支上，那么就要使用 git cherry-pick 了。
- 案例：
以origin/feature_one和origin/feature_two合并到origin/master为例。
依次执行以下两条指令 git cherry-pick 2a9e17f 、git cherry-pick 2a9e17e，合并过程中如果出现冲突，解决冲突后进行 git add ., 接着执行 git cherry-pick --continue，最后将合并后的 feature 提交到 master 即可。
E:\git> git reflog show
254f424 (HEAD -> master, origin/master) HEAD@{0}: checkout: moving from feature_one to master
5cd8f90 (origin/master, master) HEAD@{1}: commit (cherry-pick): style:游戏绑
定页面合并为注册页面；feat:支付模块从v1升级到v2
2a9e17e (origin/feature_one,feature_one) HEAD@{2}: ccommit: style:游戏绑
定页面合并为注册页面
2a9e17f (origin/feature_two,feature_two) HEAD@{3}: ccommit: feat:支付模块从v1升级到v2
E:\git> git cherry-pick 2a9e17f
E:\git> git cherry-pick 2a9e17e # 遇到冲突解决冲突
Auto-merging package.json
CONFLICT (content): Merge conflict in package.json
Auto-merging dev-log.md
CONFLICT (content): Merge conflict in dev-log.md
error: could not apply 2a9e17e... style:游戏绑
定页面合并为注册页面
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'
E:\git> git cherry-pick --continue # 若使用连续commit_hash合并模式提交，解决冲突合并后执行本命令可恢复其合并队列进行下个合并。
E:\git> git add . # 解决好冲突将内容添加到暂存区
E:\git> git commit -m <msg> # 提交最新特性到master
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# git reset 删除并回滚到指定 commit
# git commit 之后，想撤销 commit
在开发过程中，偶尔会发生 git commit 注释写错的情况，
如果只需要修改 commit 的注释内容，可以使用命令 git commit --amend，届时会进入默认 vim 编辑器，修改注释完毕后保存退出页面即可修改注释。
# git push 时保持版本没获得关联 fatal: refusing to merge unrelated histories
在多端开发时可能会遇到这样的情景：
A 和 B 开发项目 Lib，然后在 A、B 开发过程中分别多次提交源码，突然的 A 或 B 遇到本地仓库源码与远程仓库源码提交历史不同步，某些提交历史不关联，然后 Git 冒红fatal: refusing to merge unrelated histories
提交历史不关联的情况主要发生在如下情景：
git mergegit pullgit push
针对这种报错，Git 给出的方案是在上述情景中后缀添加属性声明，允许不关联历史合并操作--allow-unrelated-histories。
然后轻轻地一敲git pull origin master --allow-unrelated-histories，Git 将会强制合并不关联历史版本。Bingo！
# 设置 Git 短命令
对我这种喜欢敲命令而不用图形化工具的爱好者来说，设置短命令可以很好的提高效率。
下面介绍两种设置短命令的方式
- 命令式 设置
git config --global alias.ps push
- 全局配置文件 设置
vim ~/.gitconfig
# 写入内容
[alias]
co = checkout
ps = push
pl = pull
mer = merge --no-ff
cp = cherry-pick
2
3
4
5
6
7
8
9
- 使用短命令
# 等同于 git cherry-pick <commitHash>
git cp <commitHash>
2
# 遇见冲突问题
# CONFLICT (content): Merge conflict in deploy.sh. Automatic merge failed; fix conflicts and then commit the result.
在git pull 下拉数据时，遇到合并文件冲突问题
解决：
code [filename]
git add [filename]
git merge --continue
git pull [remote_name] [branch_name]
2
3
4