Clever Geek Handbook

Midnight CommanderプロジェクトでgitとTracを使用したチーム開発

実際、今ではインターネット上でGITの設定と操作に関する多くの情報を見つけることができますが、特定のプロジェクトの最初から最後までの集団開発と「作業プロセス」の問題は十分にカバーされていません。



必要なソフトウェアのインストールの問題については説明せずに、このギャップをオープンなMidnight Commanderプロジェクトの例で埋めようとします。この点はインターネットで詳しく説明されており、自分に興味のある追加情報を簡単に見つけることができます。



使用される用語と定義




エラーの修正/機能の追加



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



さらにアセンブリ、テスト、コードレビュー、レビュー。



パッチを適用する


監査手順とブランチに必要な投票数の取得後、開発者はリポジトリのメイントランクに変更を注ぐことができます。 同時に、次の規制を遵守する必要があります。





Uff ...すべてのように見えます、あなたの注意をありがとう...



PS：それがあなたのためにどのように機能するかを読んでうれしいです。


More articles:


All Articles