【Git】Git使用整理
一、Git安装并配置
- 生成密钥对
ssh-keygen
- 获取公钥
cat ~/.ssh/id_rsa.pub
- 测试访问
ssh -T git@github.com
- 自定义配置
## 配置代码提交的用户名和邮箱
git config user.name qingshan
git config user.email zqunor@foxmail.com
此处的配置可以添加--global配置全局的，不用在每个仓库下都配置一遍。但是实际可能不会这样配置，因为公司项目(花名)和个人项目(真名)的用户名可能为了区分是不一样的，所以根据自己的情况看。
细节可参看：git+github入门
二、实战开发
1.了解分支
通常有一个线上分支(master/main)、测试分支(dev/deploy)、开发分支(qingshan/...)
- 开发分支(qingshan/...)： 自己本地环境开发功能的代码分支，是一个从 线上分支 切出来的新分支，用于新功能的开发、和测试通过后的单独上线。
- 测试分支(dev/deploy): 测试分支，指向测试环境的代码分支，集合了所有开发者的开发中代码，不能直接合并到线上分支。
- 线上分支(master/main): 代码通过测试通过后，合并到该分支，并发布到线上环境，是线上环境运行的代码。
2.基本开发流程示意图
3.步骤说明
① 从 线上分支(master)上新开一个开发分支(qingshan)到本地进行开发，
② 提测。将本地的开发分支合并到测试分支(dev)[此处实际有将测试代码直接发布到测试环境的任务]，和前端联调并让测试人员测试
③ 改测试bug，如果测试过程有bug或优化，需要回到开发分支(qingshan)修改，
④ 修完bug后再次将开发分支(qingshan)合并到测试分支(dev)，
重复②.③.④
⑤ 全部开发完，并测试完之后，将开发分支(qingshan)的代码合并到线上分支(master)
4.终端命令执行过程
步骤①操作
master: git checkout -b qingshan
步骤② 操作
qingshan: git add .
qingshan: git commit -m '提交开发代码'
qingshan: git checkout dev
dev: git pull origin dev
dev: git merge qingshan
dev: git push origin dev
步骤③ 操作
dev: git checkout qingshan
qingshan: git add .
qingshan: git commit -m 'fix xxx的问题'
步骤④ 操作
qingshan: git checkout dev
dev: git pull origin dev
dev: git merge qingshan
dev: git push origin dev
步骤⑤ 操作
dev: git checkout master
master: git pull origin master
master: git checkout qingshan
qingshan: git rebase -i master
qingshan: git checkout master
master: git merge qingshan --no-ff
master: git push origin master
- 线上环境部署
测试环境会有流水线自动发布 git 仓库的代码到测试服务器，但是线上环境安全起见，是需要手动发布的。
- 阿里云流水线：https://flow.aliyun.com/
三、问题整理
1.代码冲突
## 将master合并到dev的时候冲突
=> 用master的代码覆盖dev的()
## 冲突太多,改了一部分之后改不下去, 无法撤销, 又不能继续
=> 提交并放弃此次提交
2.代码回滚
## 回滚到上一次提交之前, 将上一次的提交恢复到暂存区,可重新提交,或舍去
git reset HEAD^
3.代码暂存
使用场景：
- 开发中突然需要处理其他问题的情况，此时不适合直接提交代码，也不能全部舍弃。
- 在开发分支1上改了开发分支2上的需求，因为同时修改了某个文件，导致此时直接切到分支2上会有代码冲突。不想处理冲突的话，就可以将当前改动暂存起来，然后切到分支 2 上恢复。
## 将开发中的代码添加的暂存区
git stash
## 将上次提交暂存的代码恢复到当前分支
git stash pop stash@{0}
## 查看暂存区有多少个
git stash list
## 恢复上上次暂存的代码
git stash pop stash@{1}
- 分支/提交历史美化
场景说明: 由于每次提交都是“载入史册”的，所以为了少记录点自己的不完美提交，可以美化一下代码提交的历史记录。
## 重新设置提交历史
git rebase -i master
## 默认全部 pick, 可以将 pick 改成对应需要的命令。
pick ## 采用该提交
stash ## 采用该提交的内容，但是将这次提交内容合并到上一次被采用的提交里，不单独作为一次提交节点，保留提交文案
fixup ## 采用该提交，将这次提交内容合并到上一次被采用的提交里，不单独作为一次提交节点，不保留提交文案
drop ## 不保留该提交代码
5.代码误提交
场景说明: 实际工作中,可能并发的处理几个需求,这样就可能存在同时有几个开发分支的情况, 并且需要来回切换分支, 这可能导致将另外一个分支(分支2)需求的代码提交到了当前分支(分支1), 这时候怎么办?
# 获取误提交的版本号哈希值(hash1)
> 分支1: git log --oneline -n 5
# 切换到分支2
> 分支1: git checkout 分支2
# 获取上一次的提交
> 分支2: git cherry-pick hash1
这样, 就将分支1上误提交的代码版本hash1, 提交到了分支2上, 对于分支1, 如果是新分支,可以直接删掉切新分支,如果已经有开发中的其他提交,可以在合并上线的时候 执行git rebase -i master的时候,drop 掉误提交的hash1
git pull 合并规则配置
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint:
hint: git config pull.rebase false # merge (the default strategy)
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
From github.com:zqunor/mypro
* branch master -> FETCH_HEAD
Already up to date.
