1. Git Flow の開発プロセス
実際の開発では、git flow を使用することでプロジェクトの各バージョンを簡単に管理でき、機能開発も効率化できます。具体的な利用方法は以下の通りです。
Git クライアントをインストールします。
git をダウンロードしてインストールします。
https://github.com/petervanderdoes/gitflow-avh/wiki/Installation
対応するプラットフォームを選択するだけです。
ここでは、Windows プラットフォームの git がデフォルトで使用されます: Git for Windows
PS：
1. TortoiseGit も日常の開発にインストールされます。これは、ローカル ウェアハウスに提出されたファイルの表示に便利であり、リモート ウェアハウスにも簡単に提出できます。
TortoiseGitダウンロード リンク:ダウンロード – TortoiseGit – Git への Windows シェル インターフェイス
知らせ：
1. TortoiseSVNは SVN ツールです プロジェクトでバージョン管理ツールとして SVN を使用する場合、バージョン開発には TortoiseSVN を使用する必要があります。ダウンロードリンク：ダウンロード・TortoiseSVN
Git と SVN の違い: Git と SVN の比較 - WindrunnerMax - 博客园
2. TortoiseGit と TortoiseSVN の両方に、対応するダウンロード リンクに対応する LanguagePack 多言語パックがあり、異なるツールの LanguagePack を共有することはできません。
プロジェクトで git flow を使用する詳細なプロセス:
1. リモート リポジトリのクローンを作成します。
git clone 远程仓库链接知らせ：
1. git clone コマンドを使用すると、現在のディレクトリにリモート ウェアハウス リンクのプロジェクトの名前のフォルダーが自動的に作成されます。
たとえば、現在のディレクトリ「D:\Project\Unity」を右クリックし、「Git Bash Here」を選択して git ウィンドウを開きます。
git clone コマンドを使用すると、リモート ウェアハウスにリンクされたプロジェクト名に従って、対応するフォルダー「testBranch」が自動的に生成されます。
そのため、別のフォルダを作成してリモートの倉庫アイテムを配置する必要がなく、ネストを回避できます
2. クローン コマンドが完了したら、
***ローカル倉庫をリモート倉庫に自動的に関連付けます
*** そして、リモート ウェアハウスのデフォルト ブランチに従って、ローカル ウェアハウスに同じ名前のブランチを自動的に作成します (Gitlab のデフォルト ブランチはメインです)。
*** 後で必要に応じて、上記のリモート プロジェクトに基づいて自動的に作成された同じ名前のフォルダーの名前を自由に変更できます。
注: フォルダ名を変更しても、ローカル ウェアハウスとリモート ウェアハウスの間の関連付けは変更されません。
3. その後、ローカル ウェアハウスおよびリモート ウェアハウスでのすべての操作は、最初に「testBranch」フォルダーに入り、次に git ウィンドウを開く必要があり、「testBranch」と同じレベルのディレクトリで操作することはできません。
PS：
ローカル倉庫の関連付けステータスを表示します。
git remote -vローカル倉庫をリモート倉庫に関連付けます。
git remote add 远程仓库别名(默认为origin，也可以自定义) 远程仓库链接知らせ：
1. リモート倉庫エイリアスを設定する機能は、リンクの長い文字列を入力する代わりに、リモート倉庫リンクを後で使用する必要がある場合にのみ、このエイリアスを直接使用することです。
2. ローカル倉庫をリモート倉庫と同じ名前の支店に関連付けることもできます。
git push -u origin 本地分支名2. リモート ウェアハウスの内容をローカル ウェアハウスに同期します。
PS: git clone コマンドを初めて使用すると、リモート プロジェクトの最新のコンテンツがデフォルトでローカル ウェアハウスにクローンされます。この時点で追加の同期は必要ありません。
リモート ウェアハウスの指定されたブランチをローカル ウェアハウスの指定されたブランチに同期します。
git pull 远程仓库别名 远程仓库指定分支：本地仓库指定分支リモート ウェアハウスの指定されたブランチをローカル ウェアハウスの現在のブランチに同期します。
git pull 远程仓库别名 远程仓库指定分支3. git フローで初期化します。
ここでは、Git プロジェクトの各ブランチの名前を設定します。これには、リリース ブランチのリリース、開発ブランチの開発、関数ブランチの機能などが含まれますが、既定の構成のままにしておきます。
注: git flow init コマンドを実行した後、ローカル ウェアハウスは自動的に開発ブランチに切り替えられます。
ただし、これはローカルの倉庫に新しい開発ブランチを作成するだけで、リモートの倉庫には新しい開発ブランチを作成しません。リモート ウェアハウスに開発ブランチを作成する必要がある場合は、"git push origin local branch name: remote branch name" を使用するか、Gitlab で直接新しいブランチを作成できます。
PS: 初期化を実行するときに、ブランチ名が間違っているという問題が発生する可能性があり、正常に初期化できません。
これは、ブランチ名が正しくなく、一部のプロジェクト マスター ブランチで「master」が使用されているためです。そこでここで「本番リリースのブランチ名」をマスターに記入
4. 新機能開発機能ブランチ:
実際の開発では、通常、特定の機能に対して独立したブランチを作成して開発します。この関数の開発が完了すると、管理しやすいように開発ブランチにマージされます。
機能開発用の機能ブランチを作成する: 上記の git flow init コマンドで機能開発に使用されるブランチ プレフィックスは feature であり、自由に設定できます。
git flow feature start 分支名上記のコマンドを実行すると、 「機能/ブランチ名」ブランチがローカル ウェアハウスに自動的に作成されます。
知らせ：
1. git flow feature start のブランチ名は、リモート ウェアハウスの開発ブランチではなく、ローカルウェアハウスの開発に基づいて新しいブランチを作成するためのものです。最新の状態。
2.作成されたフィーチャー ブランチにはフィーチャー プレフィックスが自動的に追加されるため、上記で取得したブランチの実際の名前は次のようになります: フィーチャー/ブランチ名
5. ブランチ内のファイルをローカル キャッシュに送信します。
最初に、指定されたファイル トラッキングを追加します。
git add 文件路径知らせ：
1.ここでのファイルパスは相対パスであり、プロジェクトのルートディレクトリの下の相対パスです
次のように file01.txt ファイルを追加する場合は、「git add file01.txt」を直接使用してください。
PS:ルート ディレクトリ内のすべてのファイルを送信する必要がある場合は、"git add ." (ドット)を使用できます。これは、ルート ディレクトリ内のすべてのファイルを意味します。
2.「git status」を使用して、ファイル送信のステータスを表示します。
次に、すべてのファイルを追加した後、これらの変更されたファイルをローカル ウェアハウス キャッシュに送信します。
git commit -m "注释"注: TortoiseGit を使用する場合、git commit -m "comment" を実行すると、すべてのファイルが緑色に変わります。つまり、ローカル ウェアハウスへの送信が完了します。
6. ローカル ウェアハウス キャッシュの内容をリモート ウェアハウスにプッシュします。
ローカル ウェアハウスの現在のブランチを、リモート ウェアハウスの指定されたブランチにプッシュします。
git push origin <本地分支名>:<远程分支名>ローカル ウェアハウスの現在のブランチを、リモート ウェアハウスの同じ名前のブランチにプッシュします。
git push origin <本地分支名>知らせ：
1. 送信するファイルが大きい場合、送信に失敗する場合があります. このとき、git キャッシュ領域のサイズを設定できます:
# 缓存大小单位：B，例如：524288000（500MB）
$ git config --global http.postBuffer <缓存大小>2. git push origin 操作を実行した後、リモート ウェアハウスにブランチが存在しない場合は、リモート ウェアハウスにブランチが自動的に作成され、存在する場合は、ローカル ウェアハウスの現在のブランチの内容が同期されます。離れた倉庫にある同名の支店。
7. 関数フィーチャー ブランチを閉じます。
関数全体が実装され、受け入れが正しいことが確認されたら、git flow を使用してブランチを閉じることができます。
git flow feature finish 分支名知らせ：
1.ブランチの実際の名前は「feature/branch name」ですが、上記のコマンドでは「branch name」と書くだけでよく、「feature」プレフィックスを追加する必要はありません。
2.上記コマンド実行後、ローカル倉庫のブランチ「feature/ブランチ名」が自動的に削除され、ローカル倉庫のdevelopブランチに自動で切り替わります。
デフォルトでは、リモート ウェアハウスの「機能/ブランチ名」も削除されます. ローカルの開発ブランチがリモートの開発ブランチと同期されていない場合など、リモートの「機能/ブランチ名」が削除されない場合があります.
3.上記の操作は、ローカル ウェアハウスを開発ブランチに切り替えるだけであり、リモート ウェアハウスの開発ブランチは一切変更されません。したがって、リモート ウェアハウスの開発ブランチに同期する場合は、git push のオリジン ローカル ブランチ名を追加で使用する必要があります。
PS：
1. 上記の手順を実行してフィーチャー ブランチを閉じると、次の問題が発生する場合があります。
$ git flow feature finish archiveDrawing
Branches 'develop' and 'origin/develop' have diverged.
Fatal: And branch 'develop' may be fast-forwarded.理由:この時点で、リモートの "develop" ブランチの最新のコンテンツがローカルの "feature/archiveDrawing" ブランチにプルされていますが、ローカルの "develop" ブランチにはまだ最新のコンテンツがないため、ローカルの "develop" ブランチを最初に " ブランチし、次にローカルの "develop" を更新します。次に、「git flow finish」を使用して機能ブランチを閉じます
解決策:
ステップ 1:最初にローカルを「開発」ブランチに切り替えてから、リモートの開発ブランチの最新のコンテンツをプルします。
git checkout develop //先将本地切换到develop分支
git pull origin //更新本地develop分支到最新ステップ 2:最新のローカル開発ブランチに基づいて archiveDrawing ブランチに切り替えます。
git flow feature rebase archiveDrawing //archiveDrawing为feature分支名この時点で、いくつかの競合するファイルが存在する可能性があります。したがって、「git flow feature finish」コマンドを実行する前に、ローカルの archiveDrawing ブランチで最新のリモート開発ブランチ コンテンツを取得することをお勧めします。競合を引き起こす可能性のあるファイルは、このステップで直接処理されます。処理後、ここで「git flow feature rebase」命令を使用しても、通常は競合は発生しません。
PS: git flow 機能の rebase 命令を使用すると、「REBASE 1/1」が発生しました。
分岐の最後に「REBASE 1/1」マーカーが表示されます
これは、リモート ブランチをプルした後のローカル ファイルとの競合が原因です。現時点では、「git rebase --continue」コマンドを直接実行することはできません。
解決：
最初に「git rebase --skip」を直接使用して、現在のコミットをスキップします。
次に、開発ブランチに切り替えて、最新の開発コンテンツをローカルにプルします。フィーチャー関数ブランチの使用をあきらめて、変更されたコンテンツを直接コミットし、develop ブランチにプッシュするだけです
ステップ 3: 「git flow feature finish archiveDrawing」コマンドを再実行する
「git flow feature rebase」コマンドを実行した後、ローカルで「archiveDrawing」ブランチに切り替えます。このとき、「git flow feature finish archiveDrawing」コマンドを再実行して、ローカルとリモートの「archiveDrawing」ブランチを正常に削除します。次に、リモート開発にプッシュして、提出プロセスを完了します
8. ローカル ウェアハウスの開発ブランチをリモート ウェアハウスの開発ブランチに同期します。
これは重要なステップです。
理由：
1. git flow 機能の終了コマンドを使用すると、ローカル ウェアハウスが開発ブランチに切り替わるだけで、リモート ウェアハウスの開発ブランチに変更が同期されないため、再度 git push コマンドを実行する必要があります。
git push origin developこれらの変更があるのはリモート ウェアハウスのみです。それ以外の場合、リモート ウェアハウスの開発ブランチには変更がありません。
2. 同じプロジェクト内の develop ブランチは、通常、受け入れられて比較的安定している現在のプロジェクトの関数を保存するため、develop は複数の人によって同時に変更される可能性があります。その時点で機能を完了した後、誰もが開発ブランチにマージします。そのため、ローカル ウェアハウスの開発ブランチは、リモート ウェアハウスの開発ブランチよりも遅れる可能性があります。
したがって、一部のファイルの復元を避けるために、同期する前に、リモート ウェアハウスの開発ブランチの最新のコンテンツをローカルに同期する必要があります。
リモートウェアハウスの開発ブランチをローカル開発ブランチにプルする場合、ファイルの競合が発生する可能性があるため、最初に競合を処理してから、処理されたコンテンツをローカルウェアハウスの開発キャッシュ領域に「git commit -m」する必要があります。 、次に git push origin develop を使用して、リモート ウェアハウスの開発ブランチに同期します
上記は通常の git flow 開発プロセスであり、以下は単純化されたバージョンです。
git flow ブランチの開発プロセスは簡素化されています。
実際の使用では、git flow は開発プロセスを一元的に管理できますが、feature ブランチが完成し、develop にマージされる際に、「git flow feature finish branch name」コマンドで問題が発生し、ブランチのクローズに失敗することがよくあります。プロセスはここで簡略化されています。
1.開発の開始時に、コマンド「git flow feature start branch name」は開発に基づいて新しい機能ブランチを作成するために引き続き使用され、その後のすべての提出はこのブランチで操作されます。
2.機能ブランチの開発が完了したら、機能ブランチの変更をローカルおよびリモートの機能ブランチに同じ名前で送信する必要があります。プロセスは次のとおりです。
まず、develop ブランチから feature ブランチに最新のコンテンツをプルする必要があります。プロジェクトは複数の人によって開発されているため、ファイルの競合が頻繁に発生します。
競合処理:
1. リモートの開発ブランチをローカルの機能ブランチにプルする場合、ローカルの変更が上書きされて失われるのを避けるために、git はプル操作を自動的に停止し、ローカルの変更を「stash」にする必要があることを促します。 、最初にローカルの変更内容をローカル機能ブランチにコミットして、損失を回避します。
2. コミットがローカルのフィーチャー ブランチに変更された後、リモートの開発ブランチをプルすると、git は同じファイル内の異なる場所にある変更されたコンテンツを自動的にマージします。ただし、同じファイル内の同じコード行を変更すると、この時点で対応するバージョンを選択するように git が促し、特定の状況に応じて開発または独自の機能に対応する変更を選択できます。
それで争いは解決する
次に、最新の開発コンテンツをフィーチャー ブランチにプルした後、ローカルには最新の開発ブランチ コンテンツがあるため、ローカルのフィーチャー ブランチ ウェアハウスに再度コミットする必要があります。
最後に、ローカル機能ブランチをリモート機能ウェアハウスにプッシュします。これで機能ブランチは完成です。
ブランチのマージ: フィーチャー ブランチを開発ブランチにマージする方法は?
最初にローカルブランチを開発に切り替えます: git checkout develop
次に、ローカルの develop ブランチを更新します。ローカルの develop が最新でない場合、マージ操作は実行できません。
git pull オリジン開発。—— このステップでは git ツールを使用することをお勧めします。このツールは比較的シンプルで明確です。
最後に、機能を開発ブランチにマージします。
知らせ：
1. ブランチ a がブランチ b にマージされる場合、ローカルはブランチ b にチェックアウトする必要があり、ブランチ a はブランチ b に基づいてマージされます。
2. マージの過程で競合が発生することが多い機能ブランチの内容は以前にマージされているため、一部の競合は回避できますが、競合が発生する可能性はまだあります。
機能を開発ブランチにマージする操作は、git ツールを使用して直接行うことができます。
上図の「From」の「Branch」は、マージされたブランチ C を指します。「Merge メッセージ」にマージを記入する必要はなく、自動生成されます。選択が完了すると、ブランチ C が開発にマージされることを意味します
「OK」をクリックすると、マージが開始されます。マージ プロセス中に競合処理が発生する場合があります。特定の状況に応じて、使用するバージョンを選択してください。
ブランチのマージに関する参照リンク: git ブランチのマージ (ひと目でわかる) - Programmer Sought
マージが完了すると、2 つのブランチのコンテンツはローカルで利用可能になりますが、以前に変更されたコンテンツはブランチ C を使用して送信されているため、ブランチ C をマージして開発した後、開発ブランチを使用して変更されたコンテンツを再コミットする必要はありません。一度 -マージが完了した後、開発ブランチにはブランチ C がコミットしたコンテンツが既に含まれているため、開発ブランチをリモート ウェアハウスの開発ブランチにプッシュするだけで済みます。
2. git を使用して、指定したバージョンにロールバックします。
開発中に、コミットしてリモート ウェアハウスにプッシュした後、一部のコンテンツが提出に適していないことが判明することがあります。このとき、元のバージョンに戻す必要があります。「git reset --soft」および「 git リセット --hard":
git リセット --soft：
指定されたバージョン A にのみロールバックします。このコマンドを使用した後、ローカル ウェアハウスはバージョン A にロールバックします。バージョン A の後、ローカル ウェアハウスのすべての送信は無効になります。これは、ローカル ウェアハウスが直接ロールバックする状況と同等です。バージョン A に戻ります。——これはローカルの倉庫であり、再提出を容易にするためにローカルの支店は以前の変更内容を保持していることに注意してください
ただし、リモート ウェアハウスは引き続き最新バージョンを保持しますが、最初にローカル ウェアハウスとリモート ウェアハウスが整合性を保つように更新されてから「git reset --soft」が使用されるため、リモート ウェアハウスに再度プッシュするときに競合が発生することはありません -誰かが何かを提出した場合は、この時点でそれを引っ張ってください
このコマンドを使用した後、ローカル ウェアハウスはバージョン A にロールバックしますが、最新のコミットで行われたローカルの変更は保持されます。これらの変更はローカル ウェアハウスに送信されていないため、「ソフト」ロールバックとも呼ばれます。この時点で、通常のプロセスに従ってコミットして再度プッシュできます
git リセット --hard：
ローカル リポジトリをバージョン A にロールバックし、ローカルで変更されたすべてのコンテンツを削除します。「ハード」フォールバックとも呼ばれます。ローカルで変更されたコンテンツがクリーンアップされ、その時点でコードを書き換えることしかできないためです。
ロールバック プロセス:
1. git log を使用して、コミット バージョン レコードを表示します。
ロールバックする必要がある指定されたバージョンを慎重に選択してください。ローカルで変更されたコンテンツはソフトに保持されるため、通常は最新の送信レコードの以前のバージョンへのロールバックにすぎません。特定のバージョンに従って自由に指定することもできます。シチュエーション
2. 「git reset --soft」を使用して、指定したバージョンにロールバックしますが、ローカルの変更は保持します。
git reset --soft acf6abf01d622a89dd14db10a7d03ae842ec9b4f「git reset --hard」を使用して、指定したバージョンにロールバックしますが、ローカルの変更は保持しません。
git reset --hard acf6abf01d622a89dd14db10a7d03ae842ec9b4f上記の「git reset」コマンドを実行した後、「git log」と入力して現在のバージョンを確認し、ターゲット バージョンにロールバックされていることを確認できます。
3. commit を再度使用して、ローカルの変更をローカル ウェアハウスに送信し、リモート ウェアハウスにプッシュします。
ローカル ウェアハウスは最初に最新のバージョン B にプルされ、次に "git reset" を使用してローカル ウェアハウスをバージョン A にロールバックし、ローカル ウェアハウスは再コミット後にバージョン C になるため、再プッシュするとこの時点でリモート ウェアハウスをプルする必要があります。この時点でのプルは、ローカル ウェアハウス バージョン C に基づいて、リモート ウェアハウスの他の変更されたコンテンツ (ある場合) をローカル ウェアハウスに更新することです。
PS: "git reset" の前にローカル ウェアハウスには既にリモート ウェアハウスのバージョン B があるため、この時点で再プルしてもバージョン C がバージョン B で上書きされることはありません。ただし、リモート ウェアハウスにバージョン B 以降の新しい提出物がある場合、これらの提出物のみがローカル ウェアハウスに更新されます。これは通常のバージョン更新コンテンツです。通常のプロセスに従ってください。
3. git における「core.autocrlf」の役割
プラットフォーム間でプロジェクトを開発する場合、windows、mac、および UNIX システム間の改行の違いにより、リモートにプッシュされたときにファイルが大きく異なります。
Windows プラットフォームに「git for windows」をインストールすると、デフォルトで「core.autocrlf = true」がオンになります。
注意点：
1.クロスシステム開発の一貫性と、Windows 自体の git のデフォルトの core.autocrlf 設定を確保するために、リモート ウェアハウスは常に「CRLF」ではなく改行文字として「LF」を使用します。
2. 「core.autocrlf」を勝手に変更しないでください。core.autocrlf を閉じてから「core.autocrlf = true」を再度開く場合は、元のファイルを削除して再クローンまたは生成し、「core.autocrlf = true」を有効にする必要があります - 元のファイルを削除して再クローンします、このワンステップは非常に面倒なので、「core.autocrlf」パラメータを安易に変更しないでください
3. Windows プラットフォームに git for windows をインストールすると、デフォルトで "core.autocrlf = true" が有効になるため、リモート ウェアハウスへのプッシュが "LF" 改行であり、実行中は "CRLF" であることを確認できます。ローカルチェックアウト開発。—— これは完全に無神経で、開発プロセスに影響を与えません。これが、「core.autocrlf」パラメーターを簡単に変更できない理由の 1 つです。
要約:
Windows プラットフォームの Windows 用の git のデフォルト設定を使用すると、「core.autocrlf」は追加の設定を必要とせず、開発プロセスに影響を与えません。したがって、通常、このパラメータを変更する必要はありません
ただし、Windows プラットフォームで現在の「core.autocrlf = false」の場合は、再度開く必要があり、ローカル ファイルを削除して再度クローンを作成するまで有効になりません。
PS: Git のその他の一般的なコマンド
git branch:
列出本地所有分支，当前所在分支以“*”标出： git branch
在本地创建新分支： git branch 分支名
删除指定的本地分支：git branch -d 分支名
git checkout:
切换到本地的指定分支：git checkout 分支名
(1.如果本地没有该分支，但是远程仓库有该同名分支，那么在使用“git checkout 远程仓库同名分支”后，会
直接在本地仓库创建一个同名的分支，并且自动将远程仓库同名分支和本地仓库同名分支关联起来
2.如果在使用“git checkout 分支名”前，本地仓库已经有该分支，那么此时使用“git checkout 分支名”后只会切换到本地仓库该分支，并不会自动与远程仓库同名分支关联起来。所以后面要push或者pull时都需要在TortoiseGit工具面板中手动重新选择远程仓库指定分支才可
)
创建并切换到本地指定分支：git checkout -b 分支名
git push:
删除远程仓库的指定分支：git push 远程仓库别名 :远程分支名
git push 远程仓库别名 --delete 远程分支名
git config:
查看git配置信息：git config --list
查看用户名：git config user.name
查看邮箱：git config user.email
设置全局用户名：git config --global user.name "xxx"(输入你的用户名)
设置全局邮箱：git config --global user.email "xxx"(输入你的邮箱)Git コマンドの完全な作品: Git コマンドの完全なコレクション - 簡単な本