もちろん、私は git を 5 年間使用していますが、Byte に来てからは、git をまったく使用したことがないような気がします。靠，我5年前端开发经验难道是假造的咩~，真的是栓q. ブログでgit rebase;git rebase -i;git cherry-pick;git stash;git commit --amend;しか見ないこれらのコマンドはすべて日常的になっています。仕方がありません。家に帰って秘密の波を学ぶしかありません。今はそれらを整理して共有しています。各位同学千万不要走我的老路，被人发现了真的社死。
支店管理
- git checkout -b feat/sass-v1 origin/feat/sass-v1 // リモート ブランチ feat/sass-v1 をローカルにクローンします
- git checkout -b feat/saas-0817 // 現在のブランチから新しいブランチ feat/saas-0817 を作成します
- git merge [ブランチ名] ブランチ名を現在のブランチにマージ
- git merge [branchName] --squash ブランチ名を現在のブランチにマージし、ブランチ名のすべてのコミットを 1 つのコミットにマージします
git commit --amend 修改上次的提交信息，push后不会增加新的commit记录，但是会修改本次的commithash(也可以理解为删掉了最新的一次commit，重新又提交了一次)
git commit --amend
// 修改commit msg
复制代码- git branch -D [branchName] ローカル ブランチを削除
git push origin -D [branchName] 删除远端分支
ブランチのリベース
- git pull --rebase origin [ブランチ名] = git fetch + git rebase
// 假设当前分支dev, commit 为 a b c d e
// 假设master分支, commit 为 a b f g h
git pull --rebase origin master
// 当前分支dev commit 变为 a b c d e f g h
复制代码- git リベース マスター
// 假设当前分支dev, commit 为 a b c d e
// 假设master分支, commit 为 a b f g h
git pull --rebase origin master
// 当前分支dev commit 变为 a b f g h c d e
复制代码スタッシュ スタッシュ コード
- シナリオ: 関数が開発されておらず、コミットできないが、マスターをリベースする必要がある場合、キャッシュ領域のコードをどうする必要がありますか? 数行のコードを記述した後、バグを修正するために他のブランチに切り替える必要がある場合、キャッシュ内のコードをどうする必要がありますか? git stash を使用するだけです
- git stash stash コード
- git stash pop はワークスペースとキャッシュに復元し、stashid を削除します
- git stash list で現在のスタッシュを表示
注意：stash@{0} stash@{1} stash@{2} 是stashname
git stash apply stashname 恢复指定贮藏代码到工作区和缓存区，会保留stashidgit stash save 'msg' 带备注贮藏- git stash show -p は、最新の stash ファイル固有の変更を表示します
- git stash show -p stashname は、指定された stash ファイルへの特定の変更を表示します
専念
- git commit -m "msg" --no-verify チェックせずにコミットを強制する
- git push -f 强制提交代码并以本地版本代码为主覆盖远程
git push -f是不安全的，git push --force-with-lease更安全，注意--force-with-lease失败后再执行一次也会强制提交覆盖
reset回退
- git log 查看提交日志
- git reset 将所有暂存区回退到工作区
- git checkout . 丢弃工作区所有的更改
- git reset --hard [commit hash] 将从commithash及之后的丢弃
- git reset --hard 将暂存区、工作区所有内容丢弃
git reset --soft [commit hash] 将从commithash及之后的提交回退到暂存区git reset --soft HEAD~4 回退最近4次提交到暂存区
cherry-pick 复制提交
- 场景：当你在merge或者rebase的时候发现冲突太多了，想哭的时候，可以用原分支check目标分支处理，然后再cherry-pick当前分支的每个提交，这样冲突就会少很多。或者另一分支上有些代码还没有merge到master，但是你当前分支又非要用的时候，就可以cherry-pick过来一份。
git cherry-pick [commit hash] 将其他分支上已提交的commit在当前分支再提交一次，产生新的commithash
revert
- git revert [commit hash] 非merge的commit
- git revert -m [1|2] [commit hash] merge类型的commit
- 通过git show [commit hash]查看
- 第三行第一个hash为编号1，第二个hash为编号2，以哪个父hash为主线则保留哪个，删除另一个
复制代码
- git revert -m 1 bd86846 则回滚bd86846的提交，且以ba25a9d master分支为主线保留，回滚掉1c7036f 所在分支提交
复制代码rebase -i
- 场景：使用merge导致git提交线乱七八糟，提交日志过多非常难看。自从使用了rebase提交线变得无比丝滑，使用rebase -i合并每个需求的所有提交成1个，使日志变得清晰
git rebase -i HEAD~10调整最近10次提交的日志、或合并多次提交为1次，让log更好看更清晰
p使用, pick = use commit
s合并掉, squash = use commit, but meld into previous commit
所有的提交按时间倒序排列
被s的会合并到上一次commit,也就是当前排列的上一个里面
scope
feat: 新功能、新特性
fix: 修改 bug
perf: 更改代码，以提高性能（在不影响代码内部行为的前提下，对程序性能进行优化）
refactor: 代码重构（重构，在不影响代码内部行为、功能下的代码修改）
docs: 文档修改
style: コード形式の変更、cssの変更ではないことに注意（セミコロンの変更など）
test: テスト ケースの追加と変更
build: プロジェクトのビルドまたは依存関係の変更に影響します
元に戻す: 最後のコミットを元に戻します
ci: 継続的インテグレーション関連のファイルの変更
雑用: その他の変更 (上記の種類以外の変更)
release: 新しいバージョンをリリースします
ワークフロー: ワークフロー関連のファイルの変更
以上仅为个人学习总结，欢迎评论讨论
觉得不错的记得点个赞哦~