企業向けLinuxカーネル開発のためのGitワークフロー

Question

私はLinuxを使って組み込みシステムを構築する会社で働いています。歴史的に私たちは常にCVSを使ってカーネルの作業を保存してきました。私たちは私たちのためにLinuxを調整する

非プロプライエタリのハードウェアドライバ

ランダムyukkyハックを使用のLinuxの各ビットのための独自のハードウェア

ランダム修正のための

• ドライバー：私たちのカーネルはのコレクションになってしまいますアプリケーション

古いバージョンのカーネルを新しいバージョンにリベースしたり、古いCVSワークフローをチェンジセットに基づいて修正したりする段階にあります。明らかな選択肢はgitです。

私は賢明なワークフローを考えるのに苦労しています。 CVSリポジトリを私たちのカーネルの1つにエクスポートし、適切なベースのLinusカーネルの上に一連のチェンジセットを持っています。ここからどこに行くのですか？

すべての開発者が変更をコミットする中央リポジトリを用意したいと思います。変更セットを新しいベースカーネルリビジョンに移動し、新しいセントラルブランチの上で開発を実行するためにリベースを使用するのは安全ですか？

アップストリームに適した変更を簡単に切り離すためのワークフローを得るためのボーナスポイント。私は、小さな（または小さな）一般的に有用な変更のコレクションを常に前進させることにうんざりしています。

Answer 1

integrating upstream branchesのローカルブランチへのリベースは、ローカルブランチの履歴が書き換えられているので、そのローカルブランチをプッシュしないと提供されます。たとえば"git workflow and rebase vs merge questions"を参照してください。

デベロッパーのGitリポジトリに専用の「パブリック」ブランチ（プッシュされることを意図しています）を専用にして、merge/cherry-pickにプッシュするようにしてください。
潜在的に、いくつかのパブリックブランチが共存できます（必要に応じて、カーネルバージョンごとに1つずつ保守/修正する）。

中央リポジトリは、そこにプッシュされたすべての開発者ブランチを統合する（すなわち、プルする）ように設定できます。

さらに、マージワークフローと公開トピックについては、"git releases management"も参照してください。