工做中 Git 使用流程 commit 提交规范 提交一条没有冲突的MR

工做中 Git 飞行姿式

记录使用git的一些姿式，没那么细节，但都是一些工做中经常使用的。

配置用户名称和邮箱

# 全局设置
git config --global user.name "username"
git config --global user.email "username@email.com"
# 针对项目单独配置 须要进到相对应的项目根目录
git config --local user.name "username"
git config --local user.email "username@email.com"
复制代码

修改远程仓库地址

由于我每次忘记命令，结果都去改文件里面地址:joy:好气呀。

# 查看
git remote show origin 
# 直接命令添加
# 若是存在则要先删除
git remote rm origin
git remote add origin [url]
# 命令修改
git remote origin set-url [url]
# 这都记不住！（跟我同样）
# 修改config文件吧
复制代码

开发新需求

记得从最新的master分支中切出来一个新的分支出去开发

# 拉取master分支最新的代码
git pull --rebase
# 建立新的需求分支
git checkout -b feature/xxxx
# coding...
复制代码

解决某问题

记得从最新的master分支中切出来一个新的分支出去开发

# 拉取master分支最新的代码
git pull --rebase
# 建立问题分支（两种名称均可以主要是要统一）
git checkout -b hotfix/xxxx
# git checkout -b fix/xxxx
# coding...
复制代码

commit

每次的commit最好仍是要作commit内容格式化的不要让别的看你的commit信息的时候都是update，更新，修复，新增，删除这些之类的太不明确的词语:triumph:，不说别人看到怎么样子，我是接受不了这样的提交信息的。

版本回退

在咱们的实际开发中老是会有各类各样的问题，那么咱们就须要它了 reset 版本回退。

# 对于本地的 commit 尚未提交到远程分支
# 首先看一下咱们的 commit id 
git log
# 复制你想要回退的commit id
# --soft 保存文件状态到 添加暂存区后
# --mixed（默认）保存文件状态到 未添加暂存区
# --hard 不保存文件状态回退
git reset --hard [commit id]
# HEAD~ 回退到上一次 commit
# 没有加 --hard 则保存 commit 状态就是 status
git reset HEAD~
# 回退到前面三个 commit 位置
git reset HEAD~3
复制代码

cherry-pick

git cherry-pick 能够理解为挑拣获取某个分支的单次提交，而且做为一个新的 commit 引入到你当前操做分支上面。这个命令也是颇有用滴～

# 基本格式
git cherry-pick [<options>] <commit-id>
# options
# --quit 退出当前的cherry-pick序列
# --continue 继续当前的cherry-pick序列
# --abort 退出当前的cherry-pick序列 恢复当前分支到没有 pick 前状态
复制代码

push

在咱们的工做里面都会有不少次的push代码

每次的推送请保证当前分支是最新的代码

# 基本格式
git push <远程主机名> <本地分支名>:<远程分支名>
# 省略远程分支名称
# 推送到跟本地分支名称相同的远程分支 若是没有则会被新建
git push origin master
# 省略本地分支名 等于推送一个空分支
# 表示会删除这指定的远程分支！
git push origin :master
# 删除远程分支（上面的等同于这条命令）
git push origin --delete master
# 强制推送 -f or --force 会强行是本地分支覆盖远程分支
# 尽可能避免强制推送 除非你知道你本身在作什么
git push --force
# 这个命令在个人理解只有在作代码 rebase（下面有讲到） 的时候才会用
# 我本身的理解就是不会让你 rebase 过来的代码影响原本分支的时间线
git push --force-with-lease
# 没有option 默认推送当前分支到远程 规则同上前面几条
git push
复制代码

代码rebase

当咱们经历过漫长的开发周期的时候，这个需求分支终于开发完毕，能够上线了，可是咱们历来都没有 rebase 过咱们的代码。实际上是建议在需求分支上面天天结束的时候git rebase master一样也要保证master是最新的，你会问什么是？为何要？ 固然建议是在一个新的分支上面坚持这么作，不然最后的 rebase 可能会使你感到有点崩溃（当有不少次的 commit ）。

1. 会让你知道你和master分支具体会有那些冲突，这些冲突会由你本身解决，而不是在你提MR的时候，由合并者去解决存在的代码冲突。
2. 同时也会加快工做的效率。
3. master上面的版本时间线会是一条笔直漂亮的线，而不是很杂乱，同时也利于版本回退。
4. 总的来讲利大于弊（天天 rebase 会浪费时间？）

# 在 master 分支拉取最新代码
git pull --rebase
# 切换到开发的需求分支上面
# 我试过好像不能直接 rebase 远程 master 分支
git rebase master
# 开始 rebase 过程当中容易出现的问题
# 代码冲突 rebase 就会中止下来 当前的分支会停在一个临时的分支上面让你解决冲突（不要慌） 没有什么大的问题 正常解决冲突 完事记得 git add .
# 继续 rebase
git rebase --continue 
# 若是还有冲突 还会循环上面步骤
# 还有就是 rebase 过程当中停在了临时分支上面 你去 idea 上面看的时候 也没有发现什么冲突的 这时候就应该跳过这个了
git rebase --skip
# 这时候又进入正常 rebase 过程
# 剩下的就是重复上面的步骤了
# 还有就是如何中止呢 当你发现 rebase 出现的不可预测的问题 好比本身一脸懵逼 或者误操做 或者...
# 中止它 而且回到没有 rebase 以前状态
git rebase --abort
# 当 rebase 完成的时候 当前分支会自动切回来 剩下的就是我上面讲到的
git push --force-with-lease
复制代码

merge

到这里基本上就能够开心去提 MR（没有冲突的） 啦～

• 你的代码里有你读过的书和走过的路
• 经历过才会有更好的成长

博客地址 欢迎到访

GitHub 我不要Star✨（疯狂暗示）