git开发场景常用命令

注意：

• {url} 这样的，代表占位符~
• 如果merge、pull代码的时候发生了冲突，分支名称 后面会多出来 | rebase 或者 | merging
• git是分布式的代码管理，每一个机器都是仓库，为了共享更改内容，才需要远程仓库
• 工作区就是idea，暂存区是add 后保存的地方，commit后 到本地库，push后 到远程库
• commitId 是每一次commit后生成id
• 所有开发工具都会有 代码格式化的功能，就是美化代码格式、排版等，不要在这个文件全局使用，可以选择局部代码 排版，可能会引起 整个文件改动，git 会记录这些改动，导致以后review 代码困难
• git 默认文档位置 Git/mingw64/share/doc/git-doc/

https://note.youdao.com/ynoteshare/index.html?id=ac17384e5cb26a0d89ea9a845adbf3fe&type=note&_time=1634619641390

1. 克隆远程仓库代码

直接克隆默认的master分支
git clone {url}

克隆指定分支
git clone -b {branch} {url}

2.分支操作 

切换分支,分支必须存在
git checkout {branchName}

切换分支，如果不存在，默认复制当前分支
git checkout -b {branchName}

切换分支，复制本地的oldBranchName，oldBranchName也可以是远程分支，比如 origin/dev2.0
git checkout -b {NewBranchName} {oldBranchName}

查看本地和远程所有分支
git branch -a

删除本地分支
git branch -D {branchName}

删除远程分支
git push origin --delete {branchName}

合并本地某个分支到当前分支，合并所有修改的commit
git merge {branchName}

合并本地某个分支到当前分支，合并所有修改的commit到一个commit，保持commit的整洁性
但要注意合并后，修改的部分在暂存区，需要重新 commit。
git merge --squash {branchName}

把其它分支的某个commit 合并到当前分支
git cherry-pick {commitId},{commitId}

操作本地前三个提交，可以合并为一个提交
git rebase -i HEAD~3 

操作本地的所有 修改的提交,基于指定的branchName的commit
git reabse -i {branchName}

变基操作!
在普通的merge，会把某个commit按照时间节点合并到新的分支，会导致最终的主分支的commit 看起来
非常混乱，因为两个人的两个功能的commit会根据时间穿插的显示在主分支。rebase 会把自己的所有
commit放到主分支的提交前，自己的分支永远是最新的，参考下方图！
git rebase {branchName}

3.代码更新和推送

拉取远程分支到本地，注意，只拉取远程的改动（猜测是origin/master之类的），不会影响本地的分支
也就是不会合并，你可以查看远程的改动等等
git fetch -p

拉取指定的远程的分支到本地，直接合并到当前分支
git pull origin {branchName}

查看工作区、暂存区已修改的文件
git status

添加工作区修改的文件到暂存区，一般是 git add ., . 表示所有文件
git add {fileName[]}

提交暂存区的文件到本地库
git commit -m {message}

修改上次提交的日志内容
git commit --amend -m "更好的提交日志" 

# 空提交 —— 可以用来重新触发 CI 构建  
git commit --allow-empty -m "chore: re-trigger build"

在上次提交中追加一些内容
git add . && git commit --amend --no-edit 

撤销暂存区的文件，不要忘了 --cached！否则会删除文件,会保留工作区修改
git rm -r dir_name --cached

git checkout {fileName}
从暂存区恢复文件到工作区，不会保留工作区修改！

直接把这个分支回退到 commitid, 丢弃所有的改动，要注意！代码会丢失，如果没有add 操作，则会
丢失，可以指定某个文件 fileName
git reset --hard {commitId} {fileName}

直接把这个分支回退到 commitid, 不删除工作空间改动代码，撤销commit，并且撤销git add .
 可以指定某个文件 fileName
git reset --mixed {commitId} {fileName}

直接把这个分支回退到 commitid, 不删除工作空间改动代码，撤销commit，不撤销git add .
，可以指定某个文件 fileName
git reset --soft {commitId} {fileName}

回退某个commit的代码，与reset不同的是，revert会新建 一个commit, 
反向的把之前的commit修改回去，版本库commit会继续向前推进，而reset 则会舍弃所有的commit
git revert {commitId}


推送本地 当前的分支到远程的 {branchName} 分支
git push origin {branchName}

推送本地 的{branchName}分支到远程的 {originBranchName} 分支
git push origin {branchName}:{originBranchName}

4.rebase和merge使用以及发生冲突时

合并{branchName}分支并变基 发生冲突
git rebase {branchName}
变基发生冲突，分支名后会多出来 | REVERT 1/10 的，要注意。
解决冲突后,使用git add . 然后使用 git rebase --continue 合并冲突
git rebase --skip 则会将引起冲突的commits丢弃掉（慎用！！）；
git rebase --abort 会放弃合并，回到rebase操作之前的状态，之前的提交的不会丢弃


git merge 或者 git pull的时候发生冲突
合并发生冲突 ，分支名后会多出来 | MERGING 的，要注意
解决冲突后，手动add 然后commit 即可

5.rebase和merge对比

rebase 和 merge 对比，重点是看commit时间
77、88两个commit是A开发人员提交的，99commit 是B开发人员提交的，
99commit的时间比较晚，所以merge的时候会按照时间排序，导致不同人员的多个commit会穿插显示，这样显示比较混乱，不方便回滚的时候找commit~
使用rebase后，77、88两个commit 会在最新的99commit 之后提交，不受commit时间的限制，这样我们开发的commit 就会按顺序显示

rebase

merge

6.代码暂存 git stash

使用场景，比如自己正在开发一个功能模块，有大量修改的代码没有提交，就是没有commit，但是我们不想commit, 因为还有功能没做完，频繁的commit会导致合并的时候主分支commit太乱，代码回滚混乱，当然也可以保存更改到另外一个分支，使用merge --squash合并到主分支，都可以的；

保存当前暂存区和工作区的修改，执行后，本地的修改均被撤回 (实际保存起来了)
git stash -save {message}

查看第一次git stash的 修改内容，0换成1就是查看第二次的
git stash show stash@{0} -p

应用第一次修改到 当前的分支，不会本次的 保存记录
git stash apply stash@{N}

应用第一次修改到 当前的分支，并删除本次的保存记录
git stash pop stash@{N}

删除这次的保存记录
git stash drop stash@{$num}

清空所有的保存记录
git stash clear