1.アイデアを構成する

2. プロジェクトの複製

3. ファイルステータスの識別

四、Git操作

4.1 git add -- 一時記憶域を追加する

4.2 git commit -- ローカルウェアハウスを提出する

4.3 git push -- リモートウェアハウスのプッシュ

4.4 git pull -- ローカルウェアハウスの更新

5. 開発プロセスの完了

5.1 ステップ 1: プロジェクトのクローンを作成する

5.2 ステップ 2: 独自の開発ブランチを作成する

5.3 ステップ 3: 自分のローカルブランチでコーディングする

5.4 ステップ 4: ローカルの master ブランチに切り替える

5.5 ステップ 5: 独自のブランチコードを master ブランチにマージする

5.6 ステップ 6: ローカルマスターのブランチをリモートウェアハウスのマスターブランチにプッシュする

5.7 ステップ 7: 同僚をシミュレートしてコードをリモートウェアハウスにマージする

5.9 ステップ 9: 独自のローカルブランチに切り替え、マスターをマージし、開発を続行する

5.10 ステップ 10: ステップ 5 から 9 を前後に繰り返す

5.11 ステップ 11: ローカルブランチのリモートバックアップ

1.アイデアを構成する

アイデアには Git プラグインが付属していますが、多くの場合、プラグインのバージョンは最新ではないため、一般的な操作の前にインストールされている Git のバージョンとして構成できます。

2. プロジェクトの複製

一般的には、入社後リモート Git ウェアハウスアカウントのパスワードとウェアハウスアドレスが送信され、ウェアハウスアドレスを取得した後、開発ツールでウェアハウスをローカルにダウンロードできます。

注: マイクロサービス開発またはモジュールによる開発の場合、ウェアハウスに複数のプロジェクトファイルが含まれる可能性があるため、コマンド git clone を使用して、最初にリモートウェアハウスをローカルにクローンし、次にプロジェクトをウェアハウス 1 にインポートすることをお勧めします。ひとつのアイデア

3. ファイルステータスの識別

アイデアでは、ファイルのさまざまな状態を識別するためにさまざまな色が使用されます。

通常、いくつかの色があります。

茶色： Gitで管理されていないことを意味する色（一時保存領域に追加されていない）

緑:新しく追加されたファイルを表し、一時ストレージ領域に追加されました

青:ファイルがリモートに送信され、ファイルが編集されたことを意味します

黒:ファイルの現在のバージョンがリモートバージョンと一致していることを示します。

グレー:ファイルが以前に (リモートまたはローカルにかかわらず) ウェアハウスに送信されたが、削除されたことを示します。

赤:ファイルの内容が競合していることを示します

新しいファイルを作成するとき、アイデアはそれを git 一時ストレージエリアに追加するかどうかを確認するプロンプトボックスを表示します。

四、Git操作

4.1 git add -- 一時記憶域を追加する

方法1

方法 2

4.2 git commit -- ローカルウェアハウスを提出する

方法1

方法 2

方法 3

送信をクリックした後

4.3 git push -- リモートウェアハウスのプッシュ

方法1

方法 2

4.4 git pull -- ローカルウェアハウスの更新

方法1

方法 2

方法 3

5. 開発プロセスの完了

5.1 ステップ 1: プロジェクトのクローンを作成する

5.2 ステップ 2: 独自の開発ブランチを作成する

チーム開発では、自ローカルブランチを含めてマスターブランチにコードを書くことはできないという取り決めがあるため、開発する際には独自の開発ブランチを引き出す必要があります。

アイデアの右下隅に作成します

作成が成功すると、デフォルトで新しく作成されたブランチに切り替わります。

5.3 ステップ 3: 自分のローカルブランチでコーディングする

要件開発では、通常、自分でブランチを作成し、このブランチで自分が担当する要件を実現します。開発がいくつかの独立した要件 (完全なロジックの実装など) を完了すると、単体テストを自分で行うことができます. テストに合格すると、git add git commit によってローカルブランチが送信されます。

ここで、コミット後に独自のコードを分岐し、手順 4 を実行する必要があることに注意してください。

5.4 ステップ 4: ローカルの master ブランチに切り替える

独自のローカルブランチを開発したら、バグがないことをテストし、コミットしたことを確認してから、マスターブランチに切り替えます。

5.5 ステップ 5: 独自のブランチコードを master ブランチにマージする

ブランチコードに問題がなければ、master ブランチにマージします

5.6 ステップ 6: ローカルマスターのブランチをリモートウェアハウスのマスターブランチにプッシュする

注: 独自のブランチをマスターブランチにマージした後、独自のコードをテストする必要があります. テストが成功した後、コードを変更した場合は、再度コミットして、リモートウェアハウスのマスターブランチにプッシュする必要があります.

5.7 ステップ 7: 同僚をシミュレートしてコードをリモートウェアハウスにマージする

会社のプロジェクトはチームの形で実行されます. あなたが提出するコードは同僚によって提出されます. コードクラウドウェアハウスコンソールは、コードをリモートウェアハウスにマージする同僚をシミュレートするために使用されます.

クラス名を書く

メモを書く

正常に追加されました

5.8 ステップ 8: 最新のコードをリモートウェアハウスマスターからローカルマスターブランチにプルする

リモートウェアハウスのコードが更新されました. 新しい日のコーディング開始前に、リモートウェアハウスから最新のコードをプルします. Note that the latest code is in the remote master branch. 最新のコードをプルするには、ローカルの master ブランチに切り替えてから git pull コマンドを実行する必要があります。