|
Windows 環境で Git バージョン管理ツールを使用するための手順とガイドライン。 目次 1. Gitのインストールと使い方 2. Gitの使用ガイドライン 3. 良い仕事をするためには、まず適切な道具が必要です。 1. Gitのインストールと使い方 1.1 はじめに Gitは、LinuxオープンソースコミュニティがLinuxの開発と保守のために開発したプロジェクトです。現在、広く利用されています。バージョン管理ツールにはそれぞれ異なる特徴があり、私たちの部門ではGitのみを使用しています。ソフトウェア開発を行う前に、Gitを使いこなし、関連する運用基準を遵守することが不可欠です。 1.2 インストール Gitを初めてお使いになる方は、https://git-scm.com/docsにある入門ドキュメントを数分ほどお読みください。少し準備をしておけば、作業がきっと楽になります。 Gitアドレス: https://git-scm.com/downloads サーバー側のソフトウェアは既にイントラネットサーバーにインストールされています。この記事では、WindowsプラットフォームへのGitクライアントのインストールと使用に焦点を当てます。 1. TortoiseGit-2.5.0.0-64bit.msiをインストールします。「次へ」を最後までクリックしてください。これでGitのコア機能のみがインストールされます。WindowsでGitを操作するには、グラフィカルインターフェースシェルをインストールする必要があります。 2. GitExtensions-2.50.02-SetupComplete.msi または Git-2.15.0-64-bit.exe をインストールします。これらはインターフェーススタイルが異なりますが、主な機能は似ています。私は後者を選択しましたが、両方インストールすることも可能です。 3. インストール中に多くの設定オプションが表示されます。「Windows」というキーワードを含むすべてのオプションを選択してください。そうしないと、すぐには問題が顕在化しないかもしれませんが、保存されたレコードが破損する可能性があります。グラフィカルインターフェースなので、右クリックのショートカットアイコンを有効にしてください。 以降のすべてのインストール オプションでは、キーワード「Windows」を含むオプションを選択します。 4. インストール後、右クリックするとGit GUI Hereが表示されます。 5. 初心者の場合は、中国語ローカライズパッチ TortoiseGit-LanguagePack-2.5.0.0-64bit-zh_CN.msi をインストールできます。 1.3 基本的なデモンストレーション 1. 構成 ユーザー名は自分の名前を完全に入力する必要があります。後でレコードを検索、追跡、変更しやすくするために、略語やその他の特殊文字は使用しないでください。 2. ローカルリポジトリを作成します: `git create repository here`。これによりリポジトリが作成され、空の `test` フォルダに `.git` ファイルが生成されます。 3. 「test」フォルダ内で変更を加え（例えば、123.txtという新しいファイルを追加するなど）、変更をコミットします。右クリックメニューに以下の項目が表示されます。 4. この修正記録を編集します。修正記録は簡潔かつ明確に記述する必要があります。具体的なガイドラインについては、次の章を参照してください。 5. 変更を保存した後、Git GUI Here->Repository->Visualize master's History を使用して、完全なバージョン履歴を表示します。 6. リモートサーバーに送信する 7. リモートブランチを同期する 場合によっては、「プッシュ送信に失敗しました」というメッセージが表示されることがあります。その場合は、まずサーバー上に新しいノードがあるかどうかを確認してください。その後、データを同期してリベースしてから、再度送信してください。 8. ブランチのマージ リベースは一般的に推奨される方法ですが、欠点もあります。重要な注意点として、マージする前に、現在のブランチの名前を新しい名前に変更してください。そうすることで、操作が失敗した場合にノードの破損や現在のノードの損失を防ぐことができます。マージ後は、コミットする前に変更内容をコンパイルして検証する必要があります。 9. 一般的な構成と共通機能 1.4 要約 Git を使用する場合、特に共同プロジェクトでは、次の点に注意してください。 1. サーバーにプッシュする前に同期します。 2. 2つのブランチバージョン間で競合が発生した場合は、まずリベースで解決してください。マージに慣れていない場合は、マージを使用しないでください。 3. バージョンノードでは中国語は使用できません。説明の変更は可能です。説明の変更に関するガイドラインについては、次の章を参照してください。 4. 自動生成された一時ファイルはコミットしないでください。TortoiseGitの「削除」メニューで「無視リストに追加」を選択し、特定のファイルをフィルタリングすることで、変更されていてもコミットされないようにすることができます。 5. Git に組み込まれている比較ツールはあまり機能的に貧弱ですが、外部の比較ツールを使用するように設定できます。 合計3箇所あります。DiffビューアとマージツールをHA-BCompareに変更してください。
このツールには強力な比較機能とわかりやすい表示インターフェースが備わっています。 2. Gitの使用ガイドライン 1.1 ユーザー名 問題の追跡と変更履歴の記録を容易にするため、初回送信前にユーザー名とメールアドレスを設定する必要があります。特に、ユーザー名はご自身のお名前を小文字でフルスペルで入力してください。略語や特殊コードは使用しないでください。 1.2 支店名 同様の機能を持つプロジェクトでは、関数マクロまたはプロジェクト マクロを使用して、ソフトウェア ソース コードの分岐を減らすようにしてください。 ブランチ名には大文字とアンダースコアを使用する必要があります。スペースや漢字を含めることはできません。 機能の一時的なテストや検証に使用するブランチは、「TEST_」で始まる必要があります。検証が完了し、本番環境プロジェクトに適用されたら、リモートブランチを削除するのが最善です。 運用または顧客の問題を解決することを目的とした、以前のバージョンへのマイナー変更は、現在のブランチが特別な状況でのみ使用され、後続の公式リリースでは維持またはアップグレードされないことを示すために、PATCH_ で始まる必要があります。 要件の変更により、元のXXXプロジェクトはXXX_AAとXXX_BBという2つのブランチに分割する必要がありました。AAとBBは2つのブランチを区別する主なキーワードです。これらが同じであるという事実は、元々同じブランチノードに属していたことを示しています。XXX_BBがさらに分割された場合、新しいブランチはXXX_BB_CCとXXX_BB_DDとなり、以下同様に続きます。 XXX1 XXX2 XXX3 のようなブランチ名は禁止されており、master のようなブランチ名も禁止されています。 個人的なテストや再起動前に使用されるリモート ブランチについては、元の作成者が不要であることを確認した場合、バージョン ブランチ ツリー構造を簡素化するためにリモート ブランチを削除する必要があります。 1.3 注記 変更履歴の標準化は、この論文の主要な焦点です。コメントは次の形式で記述する必要があります。
各行は50文字以内でなければなりません。`type`パラメータはコミットの種類を指定し、以下の動詞プリミティブのみを使用できます。 ソフトウェアをリリースするときは `release` ディレクティブが必要であり、最初の行に記述し、その後にバージョン番号を続ける必要があります。 新機能の追加 バグの修正の説明。 既存の基本機能をアップグレードおよび改善するためのアップデートです。 変更とは、要件の変更または実装計画の変更を指します。 ドキュメントが更新されました テストサンプルコードの追加/変更 merge/rebase はコードの競合を解決し、ブランチをマージするために使用されます。 `create` は、初めて新しいプロジェクトを作成するときに使用されます。 コードを削除するときは `remove` を使用します。 パッチの統合とSDKパッチのマージ メッセージは、提出物の説明テキストを指定するために使用され、いくつか注意すべき点があります。 1. 中国語を使用して簡潔に説明し、重要なポイント、特に修正すべき問題を強調します。 2. 「update」「add」「repair」などの動詞で始めるようにしてください。 3. 特に複雑な機能やプロセスについては、関連ドキュメントを参照して説明を確認し、付随するドキュメントを更新してアップロードしてください。 正しい例: [リリース] リリース V1.0.0_2021 [修正] ログインボックスに影が表示される問題を修正しました。 [更新] RFID カード情報の読み取り用ドライバーを最適化しました。 [テスト] GNSSデコードテスト機能を追加しました [削除] インターフェースから冗長なツールチップを削除することに関連するコード。 エラーの例: [修正] 重大なバグを修正しました // 具体的に何が問題だったのでしょうか? ネットワークモジュールを追加 // タイプなし [追加] [追加] APIドキュメントを更新 // タイプが間違っています。[doc]にする必要があります [release] V1.0_20210220 // release は最初の行に記述する必要があります 3. 良い仕事をするためには、まず適切な道具が必要です。 良い仕事をするには、まず適切なツールが必要です。ツールの熟練した使用、変更記録の適切な保存、後から問題を容易に検索・追跡できること、そして複数のソフトウェアプロジェクトのシームレスな切り替えと統合は、シンプルで簡単な操作とコード品質の確保に不可欠です。 この記事はWeChat公式アカウント「Embedded Systems」から転載したものです。以下のQRコードからフォローできます。転載の許可については、「Embedded Systems」公式アカウントまでお問い合わせください。 |
