linuxカーネルを追跡するためのgitワークフロー

Question

Linux用のカスタムハードウェアのソフトウェアを開発している4人のエンジニアがいます。私たちは、Linux 3.3/3.4カーネルを可能な限り厳密に追跡したいと考えています。 //git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux：

1. クローンからのgitのレポは、gitのを言う：

   これは、我々がやりたいものです。 git

2. 私たちの内部のgit-serverを指し示し、ブランチを作成する 'devel'というものがあります。これは、私が 'companyremote' git repoにこのdevelブランチを作成するときに注意する必要があるものですか？
3. 3人の開発者はすべて、このコミットをcompanyremoteのこのブランチにプッシュします。
4. その後、companyremote/develブランチの起点/マスターをリベースして（最新のカーネル3.4-rc1、3.4-rc2など）、その変更をcompanyremoteにプッシュすると、4人のエンジニアはすべてベースのカーネルソースで作業します。

Linuxカーネルのトップを追跡したいと思っていても、内部ブランチ/コラボレーションのタイプがある場合は、上記のワークフローは正しいと思いますか？

このプロセスを説明するドキュメントがある場合は、ポインタを理解していただければ幸いです。

Answer 1

もう少し明確にする必要があるかもしれないと思います。

開発者は、Linuxカーネルの最新の変更を追跡し、すべてが同じベースラインに対してコーディングしていることを確認するだけでよいですか？ これが当てはまる場合は、gitサブモジュールを使用して調べることができます。

http://book.git-scm.com/5_submodules.html

のGitのサブモジュールのサポートは、リポジトリは、 サブディレクトリとして、外部プロジェクトのチェックアウトを含めることができます。サブモジュールは、自身のIDを に維持します。サブモジュールサポートはサブモジュール のリポジトリロケーションとコミットIDを保存するだけなので、プロジェクト（ "スーパープロジェクト"）を含む をクローンする他の開発者は、同じリビジョンのすべての サブモジュールを簡単にクローンできます。

linuxカーネルはプロジェクトgitリポジトリのサブモジュールになります。プロジェクトをクローンする人は誰でも、そのサブモジュールを初期化するときに参照するベースラインを決めます。ベースラインを維持するには、リモートのLinuxカーネルブランチからサブモジュールに変更を引き込み、それらをコミットして新しいベースラインをプロジェクトリポジトリにプッシュします。