実際、今ではインターネット上でGITの設定と操作に関する多くの情報を見つけることができますが、特定のプロジェクトの最初から最後までの集団開発と「作業プロセス」の問題は十分にカバーされていません。
必要なソフトウェアのインストールの問題については説明せずに、このギャップをオープンなMidnight Commanderプロジェクトの例で埋めようとします。この点はインターネットで詳しく説明されており、自分に興味のある追加情報を簡単に見つけることができます。
使用される用語と定義
- チケット -エラーや要望、改善について報告します。 他の名前-バグレポートなど
- ブランチ -バージョン管理システムに存在する開発ブランチ （git）
- 上流はバージョン管理システムの主要なブランチです。 gitの場合、これは通常masterブランチです
- 安定ブランチ -マスターブランチから分岐され、リリースとしてタグ付けされリリースされたブランチ（以下、個別に）
エラーの修正/機能の追加
Tracで現在の開発状況をキャプチャする
私たちのチームにはそのようなプロジェクトリーダーはいません。また、民主主義を
破壊するという原則があります。 多数決により集団で決定されます。 意思決定が長時間遅れないように、すべてのコミュニケーションはジャバー会議でリアルタイムに行われます。 誰も時間がなかった-彼は遅れていた:)。 しかし、ソリューションがすべてのアクティブな開発者の投票を必要とする場合、プロジェクトのTracに投票するための別のチケットが開始されます。
開発プロセスの混乱を避けるために、直接の「作業プロセス」を規定する多くの規制を採用しています。 プロセスはいくつかの段階に分けられます。
- 問題の特定
- Tracでのチケット作成
- 働くチケットの開発者による受け入れ
- ブランチ出版
- 見つかったソリューションの部屋での議論、パフォーマンスチェック、コード監査
- 必要な数の開発者がソリューションを受け入れられると判断した場合、ブランチの承認
- アップストリームブランチ
開発者の1人がチケットに記載されている問題を修正するか、新しい機能を追加することを決定した場合、彼は自分自身をチケットの所有者に任命し、この問題を解決する責任があると見なされます。 今、彼はチケットを観察し（タスクマネージャーと通信し、サードパーティの開発者がパッチなどの「解決策」を提案したかどうかを監視します）、さらに作業するための新しいブランチ（ブランチ）を作成します。 新しいブランチは命名規則に従う必要があります：
XYZ_ <here_some_description>ここで、XYZはチケット番号です。 説明は意味があり、可能な場合は短くする必要があります。
チケットパッチが「マスター」ブランチに直接適用されることはありませんが、常に個別のブランチとしてディスカッションおよび改訂プロセスを通過します。
ブランチを作成してリポジトリに公開した後、チケットを担当する開発者はブランチをレビュー（レビュー）し、他の開発者がこのチケットの改訂と議論の準備ができていることを確認できるようにします。 これが行われず、チケットがレビュー用に送信されない場合、ブランチは不安定であると見なされ、さらなる開発の対象となります。
例として、チケット
＃1746を提供します。ビルボは、ビルトインftpクライアントの問題の本質を説明し、問題を修正するパッチを適用しました。
さらに同じチケットで、彼は新しいブランチ
1746_passive_mode_over_proxyのリポジトリでの公開を発表し、投票にかけます。
*ビルボに設定された所有者
*ステータスが新規から承認済みに変更されました
*重大度はブランチなしからレビュー中に変更されました
ブランチ1746_passive_mode_over_proxyを作成しました
初期変更セット： b32c9e4a2a15cd50a6a07ad85b1a587328bd2cfc
コードを表示した後、2人の開発者がこのコードに投票し、承認済みとして指定しました。
*投票がスラバザンコからスラバザンコに変更されましたandrew_b
*重大度はレビュー中から承認済みに変更されました
さらに、開発者はブランチ
1746_passive_mode_over_proxyをメインブランチ
マスターと
マージし、チケットでこれを報告しました。
*ステータスが承認済みからテストに変更されました
*投票がslavazanko andrew_bからcommited-masterに変更されました
*解像度を固定に設定
*重大度が承認済みからマージ 済みに変更されました
修正済み2cfed22012ded42c2f4f47a13edc05bf405842db
GITの制御下でコードを操作する
1つのチケット内でgitを使用してコードを操作するには、次の手順に従います。
マスターブランチへの切り替え
$ git checkout master
最新の変更を取得する
$ git pull
このブランチの命名規則に従って、ローカルブランチを作成する
$ git checkout -b 123_branch_name
次に、開発者はソースコードに変更を加え、変更をコミットします...
変更をコミットする
$ git commit file.1 file.2 file.3
支部出版
$ git-publish-branch
git-publish-branchスクリプトは
ここからダウンロードでき
ますコード修正
チケットを作成するためのガイドがあるように、それらをレビューするためのガイドがあります。
コードをレビューする際に使用する基本的な原則は、記事によく簡潔に記載されており、その翻訳は
「嫌いです：コードはゴミです！」で公開されてい
ます 。
コードの改訂を担当する開発者は、レビュープロセス中に次の質問に対する回答を受け取る必要があります。
- パッチはプロジェクトの全体的な概念に組み込むことができますか、それともパッチはハックですか？
- コードはきれいに見えますか？
- コードは、本来行うべきこと（パッチコメントで宣言されていること）を行いますか？
- コードは新しい問題（エラー）を追加しますか？
パッチが心地よい（容認できるように見える）場合、レビューアは投票を<login>形式のチェンジセットの投票フィールドに追加する必要があります。loginはTracのユーザーの名前です。 パッチが完全に無罪ではない場合、これについてチケットの責任者に書き、チケットのステータスを
レビューから
リワークに変更する必要があり
ます現在、親ブランチ（または「マスター」ブランチ）にパッチを適用するには、2人の開発者の投票が必要です。 レビューアの1人が2番目の投票を追加する場合、チケットのステータスを
承認済み （承認済み）に変更する必要もあります。
チケットでの議論中、またはパッチの表示中に、開発者は問題が発生した場合に声を消すことができます。
理想的なテストオプション：
$ git checkout master
$ git reset --hard origin / master
$ git pull
$ git merge --log --no-ff origin / 123_branch_name
よりシンプルなオプション
$ git checkout origin / 123_branch_name -b 123_branch_name
さらにアセンブリ、テスト、コードレビュー、レビュー。
パッチを適用する
監査手順とブランチに必要な投票数の取得後、開発者はリポジトリのメイントランクに変更を注ぐことができます。 同時に、次の規制を遵守する必要があります。
- 修正を組み合わせるために、「マスター」に対して安定したブランチをリベースしないでください！
- コミットの最初の説明でブランチの形式でチケット番号を示すようにしてください。これは次のようなものです。
チケット＃123（チケットの概要）
<空行>
追加：テキスト...
修正：一部のテキスト...
これは、将来、最初のコミットの説明を通じて、Tracのチケット番号を含むブランチに接続するのに役立ちます。
- 親ブランチを基準にしてブランチをリベースしてください。
たとえば、ブランチがマスターブランチに基づいている場合
$ git checkout master
$ git pull
$ git checkout 123_branch_name
$ git rebase -i origin / master
-iスイッチは、インタラクティブなリベースが必要な場合に指定されます（個々のコミットを削除/接着/再配置する必要がある場合）
その後、サーバー上のブランチを更新する必要があります
$ git push origin + 123_branch_name
「+」は、リモートブランチにコミットの更新を強制する必要があることを示します
注：再配置しない場合、他の開発者が既に競合する変更を親ブランチに注ぎ込んでいる状況が発生します。最良の場合、そのストーリーは混乱して乱雑になり、最悪の場合、親ブランチは収集を停止するか、正しく動作しません。
- 親ブランチとマージ
$ git checkout master
$ git merge --log --no-ff 123_branch_name
--logキーは、マージコミットで、このマージによって導入されたパッチのリストを示します。
--no-ffスイッチを使用すると、ブランチが親の頂点の子である場合でもマージコミットを生成できます（このチケット内でどのパッチが作成されたかを追跡する方が簡単です）。 このキーは、コミットの関係の理解を大幅に簡素化します。
リモートリポジトリのデータを更新する
$ git push origin master
サーバーおよびローカルでの123_branch_nameブランチの削除
$ git push origin：123_branch_name
$ git branch -d 123_branch_name
- 上記のように、フォームにコメントを書くことで、チケットの合併の事実を修正してください
修正済み2cfed22012ded42c2f4f47a13edc05bf405842db
ここで、 2cfed22012ded42c2f4f47a13edc05bf405842dbはマージブランチコミットです。
- 「マージ済み」ステータスを示すチケットを閉じます
Uff ...すべてのように見えます、あなたの注意をありがとう...
PS：それがあなたのためにどのように機能するかを読んでうれしいです。