Git の使用仕様 && Git の共通コマンド

分岐指定

マスターブランチ

マスターのブランチ HEAD と履歴コミットは両方とも安定しており、解放可能な状態にあります。
master ブランチの各コミットには、v1.0、v1.1、v1.2、v2.0 などのタグを付ける必要があります。
テストブランチとホットフィックスブランチからのみマージできます。
ホットフィックスのマージは、コードレビューとテストを通じて検証する必要があります。
テストからマージする場合、テストで承認された品質ステータスと製品で承認された機能ステータスの両方を達成する必要があります。
チームリーダーとマスターブランチの責任者のみがコードを送信する権限を持っています

開発ブランチ

メインの開発ブランチは、master ブランチに基づいて複製され、理論的には、dev ブランチのコードは master ブランチと一貫しています。

機能ブランチ

コード変更の範囲が大きい場合、開発用に dev ブランチから feature ブランチを切り取ることができます。
コードをリファクタリングするには、feature/feature_security ブランチを切り取ります。
複数の機能ブランチが同時に存在できる
新しい変更は、feature ブランチの反復で dev ブランチからマージできません。
対応する機能の開発を 1 人だけが担当し、共同開発する必要がない場合、その機能はローカルウェアハウスにのみ存在し、リモートウェアハウスにプッシュすべきではありません。
理論的には、機能ブランチは、要件の開発前にチームリーダーによってプルされます。ブランチの命名規則は、feature/feature_function 名です。たとえば、セキュリティ変換 2.0 開発ブランチは、feature/feature_security2 です。

テストブランチ (チームリーダーのみがコードをマージします)

テストブランチ。フィーチャーブランチが dev にマージされた後、テスト段階でバグ修正をこのブランチで直接変更したり、フィーチャーブランチからテストブランチに直接マージしたりできます。
テストブランチは、テスト時にチームリーダーによってマージできます。
コードレビュー中に、テストブランチをマスターブランチと比較できます。

ホットフィックスブランチ

マスターブランチクローンをベースにしたパッチブランチ。主にオンラインバージョンのバグ修復に使用されます。
オンラインのバグ修正が完了して開始された後、ホットフィックス修正の内容を現在のテストブランチにマージする必要があります。
チームリーダーに引っ張られて

git 送信プロセス

ここに画像の説明を挿入

コードのマージ (すべて統合してリベースを使用)

コマンドモード

git pull --rebase
或者
git fetch    # 将远端代码更新到本地仓库
git rebase origin/master # 将代码合并到当前分支

アイデアのやり方

ここに画像の説明を挿入

タグ使用仕様

デマンドバージョンのメジャーバージョンは、V1.0.0 および V1.1.0 が後で追加されます。

オンラインでのバグ修正マイナーバージョン: V1.0.0 は後で V1.0.1 を追加します

# 查看当前所有tag
git tag --list
git tag -a V1.0.0 -m "xxxxx需求上线"
git push --tags

一般的な git 使用コマンド

ブランチを作成し、リモートエンドにプッシュします。

git checkout -b feature/feature_security dev  # 基于dev分支创建
git push origin feature/feature_security

dev ブランチに基づいてブランチを直接プッシュすることもできます。

git push origin dev:feature/feature_security  # 这样会创建分支并且将分支push到远端分支

git stash 一時ストレージ

git stash通常、次の 2 つのシナリオが使用されます。

同じブランチを変更する人が多く、ローカルで変更したところ、リモートブランチも変更されており、現時点ではプルすることができません。
```
git stash #先将本地代码暂存至缓存区域
git pull --rebase #再更新代码至本地
git pop   #再将暂存区域代码重新加载到本地
```
他の支店コードを誤って変更してしまいました。たとえば、もともとfeature/feature01ブランチで開発していて、誤ってmaster ブランチに切り替えて、masterブランチ上のコードを変更した場合、この時点でコードをfeature/feature01ブランチに切り替えたいとします。
```
git stash #先将本地代码暂存至缓存区域
git checkout feature/feature01 #再将分支切换到feature/feature01分支
git pull --rebase # 非必须步骤，更新远程代码到本地
git pop  #再将暂存区域代码重新加载到本地
```

コードを送信する

提案: コードを送信するたびに、同じ関数コードの場合は、送信時にローカルに送信します。毎回リモートエンドにプッシュしないでください。1 つの送信にマージされるのは同じ関数です。ファイルが複数回変更され、複数回送信され、コメントが複数回変更され、送信されたなど、無効な送信が少なくなります。

git add .    # 添加提交内容 ‘.’表示当前目录所有，如果需要单独添加某一个文件：git add xxx.txt
git commit -m 'feature(bin): add first commit'  # 提交代码到本地仓库
git push origin master   # 将代码推送到远程仓库

すべてのリモートリポジトリ参照を表示する

git remote

リモートブランチのリストを表示する

git branch -a

コミットをマージする

git cherry-pick 'commit-id'

ワークスペース、ステージングエリア、ローカルウェアハウス内のファイルのステータスを表示する

git status

送信されたコメントを変更します (リモートレコードにはプッシュされません)。

git commit --amend

iを押して編集モードに入ります (vim の使用法と同じ)。た

ESC を押して編集モードを終了します

wq: 保存を終了します

q!: 保存せずに終了します

保存して終了し、送信されたコンテンツが変更されているかどうかを確認しますgit log

特定の送信のコメントを変更します (リモートレコードにプッシュされません)

まず、変更する必要があるコミットを見つけて、git log 送信のコミット ID を見つける必要があります。送信は 2 つ以上のみ使用できます。送信が 1 つだけの場合は、git commit --amendそれを使用してください

git log 
git rebase -i 28b197a00473ea1b46fab13263c294cce0d7401c

コメントを変更したら、pickに変更する必要がありますreword。

送信されたコメントを変更します（リモートレコードにプッシュ）

上記の方法を使用することもできます

ここでの変更後は、バージョンブランチに強制的にプッシュする必要があります。

git push origin master -fしたがって、ここで注意する必要があります。通常の状況ではこれを行わないでください

コードをローカルで更新してマージします

git fetch    # 将远端代码更新到本地仓库
git rebase origin/master # 将代码合并到当前分
git rebase origin/feature:test # 将代码合并到测试分支

git pull --rebase # 将代码更新到本地仓库并且合并到当前分支

ローカルとマージ

git fetch    # 将远端代码更新到本地仓库
git rebase origin/master # 将代码合并到当前分
git rebase origin/feature:test # 将代码合并到测试分支

git pull --rebase # 将代码更新到本地仓库并且合并到当前分支