git在真实开发的系列场景问题

以此记录实习期间的git工具的使用，如果入职前git不熟练或者不懂，千万千万小心写代码！！！当然都是犯错是难免了，踩了很多的坑或许会进步很快。

不是讲git命令本身，而是结合开发的场景来使用git，当然个人开发和企业级别的团队开发使用git的场景也是不同的。

绪论

列出经常使用的git命令、个人开发的场景、团队开发的场景。

从以上三点来写。

常用命令

# 目录结构
.
|-- README.md
|-- clickhouse.cpp
|-- main.cpp
|-- mysql.cpp
`-- save.h

# 最基本最基本
git add main.cpp
git commit -m "修复xxxbug"
git push origin main
# 如果想git push一步到位使用,之后直接push即可
git push --set--upstream origin main

# 查看远程链接地址
git remote -v
# 删除远程地址
git remote remove origin
# 添加令牌token
git remote add origin https://token@github.com/githubname/test1_github.git

# 分支操作
# 查看本地分支
git branch
# 查看远程分支
git branch -a
# 创建分支
git branch dev
# 切换分支
git checkout dev
# 创建分支并切换分支
git checkout -b dev

# 删除分支
# 删除本地分支
git branch -d D_Campaign
# 强制删除本地分支
git branch -D D_Campaign
# 删除远程分支
git push origin --delete D_Campaign

# 暂存操作
缓存当前分支的一些操作，方便不执行commit进行切换分支。
git stash：没有命名直接存储；
git stash save "修改了弹窗"：有名字的存储；
git stash list：查看存储了哪些；
git stash show stash@{0}：显示第一个存储的改动；
git stash show -p stash@{0}：显示第一个存储的详细改动；
git stash apply stash@{0}：应用第一个存储，不进行删除；
git stash pop stash@{0}：应用第一个存储，进行删除；
git stash drop stash@{0}：删除第一个存储；
git stash clear：清除所有的存储。

# 暂存未跟踪的文件
git stash save -u "暂存修改"

# 查看log信息
git log
# 精简的log信息
git log --oneline

# 查看节点或者文件的不同
git diff aesaads
git diff filename

# 撤销操作
# 第一种方法：
git checkout config.yaml：放弃修改
# 第二种方法:
# 如果是没有add也没有commit的文件：
git restore config.yaml
# 如果是add的了文件:
git restore --staged config.yaml

# 回退操作
# 会保留回退之前add的内容，只是将commit撤销
git reset --soft sahwkrww
# 会直接回退到之前的add前的内容，连修改都被抹去了
git reset --hard sahwkrww

所有的场景用到的命令上面都用。

场景1：新需求需建新分支

公司的代码肯定是多分支进行开发的，一般来说线上跑着的（main分支），开发者测试的以及大家可能还会有一个共同的测试分支(dev分支)。

首先有个需求下发，那么必须是在main分支的基础上开分支，不能在dev也不能在任何其他的分支。

写完了需求是需要合并到main和dev分支的，dev也是基于main一步一步迭代的，固然有新需求应该基于main开新分支。

场景2：旧需求切分支

假如现在在开发一个新需求，但是旧的需求在线上或者未上线前的dev分支有bug，那么就需要找到之前的分支进行修改bug（如果已经上线在mian分支了，当然也可以在main分支上新开一个分支），那么在这之前，需要将当前的分支进行切换。

现在有的代码，可能有问题，而且直接add还要commit才能生成一个节点方便回退。

那么就可以使用git stash暂存来解决这个问题，先git stash当前分支的修改内容，然后再git checkout到相应的分支。

场景3：合并有冲突需回退

假如当前的需求开发完了，自己也在自己的分支测试了，那么就可以将当前分支先合并到dev分支上。

但是呢，切换到dev分支执行git merge操作的时候出现了大量的冲突，人麻了。

就在你解决冲突觉得自己可以的时候，解决完冲突肯定是需要先自己测试的，因为你可能在解决冲突的时候将代码弄乱了，导致运行出错，所以解决完冲突是不能直接push的。

需要回退的话，直接git log找到合并之前的那个节点的hash，直接git reset --hard就可以。

场景4：合并有冲突得解决

解决冲突是最痛苦的，特别是多个人同时开发相似的需求改到相同的文件，那么这个冲突简直是多的离谱。

解决冲突的方式：还是乖乖使用编译器给的git工具。

需要注意的是，你开发的需求的分支是plan，需要合并到的分支是dev，切换到dev执行git merge plan后的冲突，应该优先保留dev上的，因为dev分支在你合并之前是没问题的，那么你的代码要incoming，必须得保证incoming后不出问题。

场景5：边测试边push

比如python你需要执行某个函数或者写一些操作，同时还是修改一些函数的内容，然后push。

这里用两种方法：

第一种是用两个窗口，一个用来测试，另一个用来提代码。

这种方式需要复制测试的部分代码到提代码的分支，可能在复制粘贴的过程出现错误，如果改动的少，可以使用。

第二种是使用git stash，对没错，又是git stash，这个命令真的好用。

注意

每次git add先git status和git diff