常规项目中的git命令使用
掌握Git是一个程序员的基本必备技能，特别是多人合作中，如何进行分支管理开发，如何与他人一同协作，应对复杂的需求进度需求，我们如何通过git代码管理我们的项目，变得尤为重要，本文是一篇笔者关于git一些总笔记结，希望看完在项目中有所帮助。
本文主要会从以下几点
- git如何初始化一个0项目
- 如何进行
merge操作，如何理解merge rebase变基替代merge操作- 如何进行项目分支管理
正文开始...
如何提交一个初始化项目
当我们需要初始化一个项目时，我们如何将本地的代码提交到git上
# 在你本地新建一个项目目录test
mkdir test
# 命令行进入当前新建的文件夹
cd test
# 初始化仓库
git init
# 新增文件，比如新增一个readme.md文件,将当前文件添加
git add .
# 关联远程分支
git remote add origin https://github.com/xxx/xxx.git
# 推送远程分支main
git push -u origin main
在关联远程分支上注意，有两种方式，一种是https,另一种是ssh
- https
https://github.com/maicFir/lessonNote.git - ssh
git@github.com:maicFir/lessonNote.git
选择这两种remote方式不同，那么前提条件是，如果选择https，那么你可以使用Person key方式，具体可参考放弃SSH keys,拥抱Personal Access Tokens[1],如果是ssh，那么你需要配置本地ssh key了，具体可参考git ssh[2]
把本地分支推送对应分支上
# 查看本地分支是哪个分支
git branch
# 假设当前是dev分支,基于dev分支创建your_branch
git checkout -b your_branch
# 将当前修改的添加,将当前修改的文件添加到提交记录中
git add .
# 提交当前分支信息
git commit -m 'fix:修复xxxbug'
# 将本地分支提交到远程分支
git push origin your_branch
git merge
以上是你在当前main分支，然后将dev分支的c3'、c4'提交merge到了main分支上
假设你在featureA分支，现在你的功能要上测试环境
前提在自己分支featureA已提交到remote分支的条件下,并且有把远程所有分支fetch到本地
1.本地切换到test分支
git checkout test
### 2.及时拉取远程对应分支
git pull origin test // pull 默认会merge操作，or git pull origin test --rebase
### 3.把featureA分支合并到test分支上
git merge featureA
### 4.合并分支后，将当前分支提交到远程对应分支
git push origin test
git rebase
变基操作，如果将当前功能分支featureA, rebase到dev分支
变基操作
### 1.首先切换到当前dev分支
git checkout dev
### 2.更新对应分支并使用--rebase合并远程到本地分支
git pull origin dev --rebase
### 3.将fetrueA rebase到当前分支
git rebase fetureA
### 4.提交当前分支到dev分支
git push origin dev
关于git rebase[3]的更多思考可以参考这篇文章
分支管理
我们先想几个场景，前置条件假设我们的dev、test、main同时在最初起点分支
场景一
A:开发了一个功能featureA
B:开发另一个功能featureB
A,B分别从dev拉了一个分支featureA，featrueB
现在A在featrueA开发了一些功能，B在featureB上也开发了一些功能，现在featureA与featureB分别要上测试环境？怎么办？如何让两个不同的功能同时发测试环境，但并不会互相影响？
- 你应该从dev拉一个单独分支，假设这个分支就叫dev-pre分支,然后你只需要分别把featureA与featureB分支往这个dev-pre分支合并就行，发测试环境你就发这个dev-pre分支就行【如果其他同事有要更测试环境其他功能代码，你告诉要告诉他，让他的功能合并到你当前这个dev-pre分支就行，保证当前测试环境代码不会被覆盖，并且不会因为别人的代码更新，漏到或者覆盖你的功能】
- 现在测试环境已经有了
featureA与featureB的功能代码，但是两个分支依旧在对应修复一些问题，不确定哪个要先上？ - 假设在测试环境计划
featureA测试没问题了，那么我们优先上featureA功能，那么此时应该怎么办？我们只需要将featureA分支合并到test分支去，然后，我们再把test分支合并到main主干分支去【为了规范，我们遵循合并dev->test-main】分支 - 然后发生产环境，我们就是发main分支代码，一旦我们发了生产环境，我们当前的featureA已完成使命，需及时删除
- 如果你的功能featureA已合并到main分支，但此时产品发现了线上bug？那么怎么办？接下来看场景二
场景二
A: 你从dev拉了一个分支featureA，正在开发featureA功能，现在产品发现了一个线上bug,需要修复，此时应该怎么办？，如何让当前分支功能正常开发，同时也不影响产品提出的线上bug修复。
- 首先你当前分支有两种方案，一是暂存你当前的开发功能，二是直接提交到你自己当前分支。
- 然后你应该从main分支拉一个bug-fix分支，当你修复这个问题后，你需要及时合并到main分支去【建议使用rebase】到main分支
- 同时，你也需要将当前的bug-fix分支分别rebase到dev，test或者刚刚的dev-pre分支【保证测试环境有你当前修复的代码】
- 当你修复了问题后，你应该删除
bug-fix分支【最好以main分支打一个对应的tag】
场景三
A:假设你已经在featureA开发的功能，此时你当前功能的部分代码已提交,小功能有commit1,commit2...，但是有些功能此时暂时不上,假设只需要上commit1、commit2 功能
- 方案一：你可以在commit2的节点单独拉一个临时分支，然后将这个临时分支代码合并到你测试分支去
- 方案二：你可以使用cherry-pick的摘抄你commit，然后你再push对应分支即可
切换到你需要的分支上
git checkout target_branch
查看最近提交log
git log
摘抄某个指定的commit-hash
git cherry-pick commit-hash
如遇到冲突，解决冲突后，继续摘抄
git cherry-pick --continue
如果你想要取消摘抄
git cherry-pick --abort
场景四
如果你正在你开发的新功能分支需求，你不想提交当前的功能代码，但需要你修复目前测试环境的问题，你应该怎么办？
- 当前代码stash保存
将当前功能stash到暂存中，并不会被提交
git stash save "test_1"
### 将当前stash取出test_1
git stash apply test_1
### -从已开发的功能分支去修复当前的测试问题，并合并到测试分支去
总结
- 了解学习如何从零初始化一个项目
- 分别了解学习
git merge与git rebase操作 - 关于分支管理的一些思考，如何在复杂的需求变化，如何处理好不同场景下的分支情况
更多关于git学习资料
- https://book.git-scm.com/book/zh/v2
- https://www.bootcss.com/p/git-guide/
总结
[1]放弃SSH keys,拥抱Personal Access Tokens： https://juejin.cn/post/7125686977369735204
[2]git ssh： https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
[3]git rebase： https://waynerv.com/posts/git-rebase-intro/
最后，看完觉得有收获的，点个赞，在看，转发，收藏等于学会，原创不易，欢迎关注Web技术学苑，好好学习，天天向上！