6

グループ、

ソース管理システムとして Borland Starteam を使用しています。私は Java コードを開発し、Eclipse を IDE として使用しています。私は最近、個人的なソース管理システムとして EGit の使用を開始し、コードのチェックアウト、機能の追加、バグの修正、テスト、Star チームの親ソースとのマージで構成される開発作業を合理化するために、次のワークフローを思い付きました (膨大な労力)多くの人がその間に変更を加えた場合)、ビルド、テスト、およびインストールします。私は EGit を使用して、コンパイル、マージ、およびテストのプロセスを簡素化したいと考えています。開発中、および大きなマージが行われた後のコード インストールの直前でもあります。これが私が思いついたものです。

  1. ファイル システム フォルダの作成 - 「Master」および「Work」
  2. Starteam から「Work」への新しいソース フォルダ構造をチェックアウトします。
  3. 「Work」という Eclipse ワークスペースを作成し、「Work」フォルダーから Eclipse プロジェクトをインポートして、それらのプロジェクトを EGit リポジトリーに追加します。
  4. 「作業」ワークスペースで機能を追加/バグを修正します。テストなど。インストールの準備ができたら、パッチを作成します。今度は、大規模なマージを行い、再構築し、再度テストする時が来ました。
  5. インストールの日に Starteam から新しいソースをファイル システムの「Master」フォルダにチェックアウトします。
  6. 「Master」フォルダーのソースから Eclipse ワークスペース「Master」を作成し、Eclipse プロジェクトをインポートして、それらを新しく作成した EGit リポジトリーに追加します。
  7. パッチを「マスター」ワークスペースにインポートし、マージを実行します。コンパイルエラー、テストなどを修正します。
  8. インストール。

このワークフローは効率的ですか? これをさらに簡単にするEGitのより高度な機能はありますか?

ご指導ありがとうございます。ランジット

4

1 に答える 1

1

これが間違っていることを理解していない限り、既存の git ブランチ機能の代わりに Eclipse ワークスペースを使用しているようです。私が正しければ、Egit はすべてのブランチを単独で管理できるため、ワークスペースを切り替えて行ったり来たりする必要はありません。ブランチを作成してマージし、単一のプロジェクト内で他のすべての楽しいことを行うことができます。

ここからのワークフローはすべて git です。健全なワークフローの維持に関する優れた記事は、http ://sandofsky.com/blog/git-workflow.html にあります。

于 2012-06-13T18:22:58.197 に答える