苦隊友は Git を長い間使っていません。プロジェクトごとに Git を教えるのを避けるために、このチームメイト必見の Git マルチユーザー協力チュートリアルを発表します（古い文の再投稿、霧
Git を学ぶには実践が必要で、熟練が正道です
チームメイトが Git すら使えないなら、チームを組まない方が良いでしょう
本文の一部は Git マルチユーザー協力チュートリアル | 異国迷宮の十字路 を参考にしています。
最初に#
Git リポジトリとは何ですか？ プロジェクトは、1 つの Git リポジトリです。もう少し具体的に言うと、プロジェクトフォルダの場所が Git リポジトリです。プロジェクトフォルダを Git リポジトリにするには、git init コマンドを実行してローカル Git リポジトリを作成する必要があります（ローカルとは、自分のコンピュータ上のことです）。
もちろん、Git コードリポジトリを作成するのにローカルである必要はなく、Github サイトを通じても Git コードリポジトリを作成できます。
Git とは何ですか？ Git はバージョン管理システムで、Git リポジトリのファイルバージョンを管理します。Git リポジトリに対する操作記録を保存します。必要なときに、操作記録から履歴バージョンを復元できます。
Github とは何ですか？ Github は Git リポジトリをホスティングするウェブサイトです。ユーザーは自分のノートパソコン上の Git リポジトリを Github サイトにアップロードし、デスクトップでダウンロードして編集したり、他の人とコードを同期・協力したりできます（例えば大創、霧
Git プログラムのインストール は Git 公式サイト https://git-scm.com/ や各種ブログサイトを参考にしてください。詳細は省略します。
コマンドラインで Git を操作することをお勧めします ただし、新人には少しハードルがあります。グラフィカルインターフェースを使って操作することもできます。
Git GUI (グラフィカルユーザーインターフェース) はたくさんあります 例えば：Github Desktop, Sourcetree, GitKraken など、さまざまな IDE にも Git GUI が搭載されています。
具体的なインストールについては省略しますので、Bilibili や各種ブログサイトで検索してください。
clone から始める#
git clone コマンドを使用して、Github などの Git リポジトリホスティングサイトから必要なリポジトリ（コードリポジトリ）をダウンロードします。
図のように、これが必要なリンクアドレスです。git clone コマンドを使用し、コピーしたアドレスを追加するだけで、必要なリポジトリを引き出すことができます。
git clone https://github.com/github/site-policy.git
このコードは、github の公式 site-policy リポジトリを引き出します。
コマンドラインの方法でリポジトリをクローンする場合、注意が必要です。リポジトリはコマンドラインの現在のパスにダウンロードされます。パスを変更するには cd コマンドを使用します。具体的には各種ブログプラットフォームを参照してください。
余裕があれば、Github に SSH Key を設定すると、SSH プロトコルを使用してコードリポジトリをクローンできます 同様に、ここでも詳細は省略します。
コードリポジトリのクローンが完了すると、私たちのコンピュータ上にも Github 上と全く同じ Git リポジトリができたことになります。
私たちのコンピュータ上のコードリポジトリを local repository と呼び、Github や他のホスティングサイト上のコードリポジトリを remote repository と呼びます。
❗❗コンピュータのローカルリポジトリを開くと、.git という名前の隠しフォルダが見つかるかもしれません。この .git フォルダには、リポジトリのすべての変更記録やリモート接続情報が保存されています。
❗❗.git フォルダを削除すると、現在のプロジェクトはもはやリポジトリではなく、普通のフォルダと何の違いもなくなります。
Git コードの変更とアップロード#
前述の通り、プロジェクトフォルダは Git リポジトリと見なすことができます。
コードファイルについては、避けられないことですが、いくつかのエラーを削除したり、機能を追加したりすることになります。これにはファイルの新規作成、削除、変更が関わります。
Ctrl+S を押すと、コードリポジトリは更新されますか？ そうではありません。
Ctrl+S ショートカットキーはファイルを保存できますが、Git の記録を更新することはできません。つまり、私たちの視点ではコードは確かに変更されていますが、Git の視点ではコードは変更されていません。
ファイルの新規作成や削除についても、同様の状況です。
では、Git にファイルの変動を察知させるにはどうすればよいのでしょうか？
git add コマンドを使用する必要があります。
git add *
ここでの * はワイルドカードで、すべてのファイルに適用されることを示します。
他の使い方については git add コマンド | 菜鳥教程 や各種ブログサイトの関連ブログを参照してください。
Git はファイルの変更を察知しましたが（ファイルはステージングエリアに入ります）、操作記録は生成されていません（変更はローカルリポジトリに入っていません）。
では、どうやって Git リポジトリを更新するのでしょうか？
git commit コマンドを使用して変更をローカルリポジトリにコミットする必要があります。この時点で、git log に「操作記録」が生成されます。
git commit -m "my first commit"
ここでの -m は commit 操作に引数を渡し、今回のコミットのメッセージとして使用されます。このメッセージは、今回のコミットの概要です。
commit message テンプレート
conventional commits や Commit message と Change log 作成ガイド - 阮一峰のネットログ を参考にし、簡潔明瞭を心がけましょう。
git commit コマンドの他の使い方については git commit コマンド | 菜鳥教程 や他のチュートリアル資料を参照してください。
これで、私たちはローカルリポジトリ、つまり自分のコンピュータ上のコードリポジトリを成功裏に更新しました。
しかし、次に問題が発生します —— 私たちはローカルリポジトリを変更しましたが、Github サイト上の remote repository には誰も手を加えていません。この時点で、2 つのリポジトリに不一致が生じました。
私たちは更新されたバージョン（変更したローカルリポジトリ）を Github にアップロードして、remote repository を更新します。
このプロセスでは git push コマンドを使用します。
git push origin main
上記のコードを実行すると、ローカルの main ブランチがアップロードされ、リモートの main ブランチを上書きします。
詳細な構文については git push コマンド | 菜鳥教程 を参照してください。他のチュートリアルサイトも参照できます。
Git コードの同期とダウンロード#
Github 上のリモートコードリポジトリが自分のコンピュータ上のローカルコードリポジトリよりも新しい場合、コードをダウンロードする必要があります。
この時、git pull コマンドを使用できます。
git pull origin main
この時、リモートコードリポジトリの main ブランチが引き下ろされ、その後ローカルの main ブランチが更新されます。
詳細については git pull コマンド | 菜鳥教程 や他の資料を参照してください。
コードの衝突と解決 図はネットからのコード衝突の例です。
<<<<<<<<<<<
A
===========
B
>>>>>>>>>>>
この記号は衝突記号と呼ばれます 上記のように、A と B は互いに衝突しています。
一般的に IDE は衝突記号を自動的に認識します そして、対応する衝突コードをハイライト表示します（図中では緑と青で表示）し、衝突解決のショートカットメニューを提供します：Accept Current Change, Accept Incoming Change, Accept Both Change, Compare Changes など。対応するオプションをクリックすることで、2 つのコードのいずれかを選択できます。
時には、衝突記号が正しく認識されないことがあります その場合は、重複コードや衝突記号を手動で削除する必要があります。そうしないと、マージが失敗します。
実際、コードをプッシュする際にもこのような状況が発生する可能性があります。解決方法は似ています。
ブランチ管理#
git branch コマンドと git checkout コマンドを使用してブランチを作成し、切り替えます。コマンドの使用については省略しますので、git branch コマンド | 菜鳥教程 や他の関連資料を参照してください。
Git ブランチの命名と機能：
- master/main（主ブランチ、常に利用可能な安定版、このブランチで直接開発してはいけません）
- develop（開発主ブランチ、すべての新機能はこのブランチから自分の開発ブランチを作成します。このブランチはマージ操作のみを行い、このブランチで直接開発してはいけません）
- feature-xxx（機能開発ブランチ、develop からブランチを作成し、自分の開発機能モジュールに名前を付け、機能テストが正常に行われた後、develop ブランチにマージします）
- feature-xxx-fix（機能バグ修正ブランチ、feature ブランチがマージされた後にバグが発見された場合、develop からブランチを作成して修正し、その後 develop ブランチにマージします）
- hotfix-xxx（緊急バグ修正ブランチ、master ブランチから作成し、修正が完了したら master にマージします）
- bugfix/* ブランチ（短期的に develop から作成）
- release/* ブランチ（短期的に develop から作成）
各ブランチの関係は、下の図を参照してください。
上記のように、マルチユーザー協力開発のプロジェクトは、通常、複数のブランチを並行して進めます。main/master ブランチや develop ブランチに直接プッシュすることは許可されていません。
なぜ main/master ブランチに直接プッシュできないのか？ main/master ブランチは安定したブランチであるべきだからです。悪性のバグがなく、ほぼいつでも使用可能で、基本的に予定された機能を実現しています。
もちろん、多くの友人は個人の小規模プロジェクトを管理するために git を使用したことがあるかもしれませんが、その場合はそれほど厳密ではありません。
Pull Request (PR) を使用してコードをマージする PR の方法は、直接プッシュによる予期しない結果を避けることができ、コードレビューをサポートし、自動化ツールを導入することもできます。
具体的には なぜ直接 push できないのか | Weitang Li's blog を参照してください。
PR を発起する方法は、下の図を参考にし、ページの指示に従って操作してください。
必読の開発プロセス#
いくつかの重要なポイントを強調する必要があります。
開発前に必ず pull 操作を実行する#
開発のたびに pull すること❗ 可能性のある衝突を解決し、コードを更新します。重複作業を避けるためにも。
main (master) ブランチと develop (dev) ブランチで開発しない#
main ブランチと develop ブランチに直接プッシュすることを禁止します。対応する feature (feat) 機能ブランチを新たに作成して開発するのが最適解です。
feature-xxx ブランチの命名は、開発する機能に基づいて決定できます。その後、PR を使用してコードをマージします。
PR の方向性： feat などのブランチから dev ブランチに提出し、その後 dev ブランチから main ブランチに提出します。越級提出はしないでください。
この手順を違反すると、ブランチが混乱し、結果は地獄のような難易度になります。
コードの提出および PR には、commit message を明確に記載する#
チームメイトに何をしたのかを伝えましょう❗みんなの時間を節約します。具体的には上記を参照してください。
ブランチのマージにはレビューが必要#
通常、PR は直接通過しません。他のメンバーによるコードレビューが必要で、その後にマージが許可されます。PR インターフェースのコメントセクションに注目し、フィードバックや修正提案をタイムリーに受け取ることができます。
不明な点があれば操作せず、グループで質問する#
例えばコードの衝突が発生した場合、必ずしも他の人のコードが間違っているわけではありません。
また、見たことのない問題が発生する可能性もあります……
解決策を検索するのも一つの手ですが、必ず他のチームメンバーに一声かけてください。閉じた環境で作業しないでください😅
Good Luck#
祝好