ここで説明されているものと同様のパブリック/プライベートのハイブリッドワークフローを使用して、GitHubでオープンソースプロジェクトを管理しようとしています：https：//stackoverflow.com/a/30352360/204023
基本的に、これは、GitHubのfork関係なしに、相互にミラーリングする2つのリポジトリが存在するプロセスを説明しています。これにより、標準のgitリモートリポジトリを使用してブランチ間で変更をプッシュ/プルしたり、パブリックGitHubプルリクエストを使用してプライベートな変更をマスターブランチにマージしたりできます。まさに私が達成しようとしていること。
プライベートコミット履歴を維持しながら、機密データが含まれている場合にPUBLICコミット履歴を切り捨てたいという追加の要件が1つあります。
新しいプロジェクトを初期化--depth 1すると違法であることが判明しました。浅いクローンで新しいリポジトリを初期化することはできません。! [remote rejected] master -> master (shallow update not allowed)
コミット履歴を切り捨てるために私が見つけた解決策には、まったく新しいリポジトリの作成が含まれますが、リポジトリの新しいコピーを使用すると、パブリックコピーとプライベートコピーの間でプッシュ/プルできなくなります。
Gitのリポジトリに歴史があるコミット。コミットには、ファイルとリンケージの両方が含まれます。各コミットには、すべてのファイルの完全なスナップショットと、その親のハッシュIDが含まれます。各ブランチ名には最新のコミットのハッシュID（単数）が格納され、Gitは最後から始めて、一度に1つの親を逆方向に処理することで履歴を見つけます。
各コミットのハッシュIDは、親ハッシュを含むそのコミットの内容の暗号化チェックサムであるため、最後のコミットのハッシュIDは、そのコミットからすべてのコミットまでさかのぼって形成された履歴内のすべてのコミットのハッシュIDに依存します。他の到達可能なコミット。（技術用語では、これはマークルツリーの形式です。）
これらすべての意味するところは、リポジトリDAGの短いバージョンをパブリックに保ち、長いバージョン（短いコミットと追加されたコミット）をプライベートバージョンとして保持することは可能ですが、一部の履歴コミットを省略したパブリックバージョンを作成することはできません。他の人を維持しながら。また、代わりに、並列グラフ、つまり独立したDAGを使用することもできます。1つはパブリック履歴を含み、もう1つはプライベート履歴を含みます。Gitサブモジュールを介してこれを行う場合、個人情報を公開しないことを合理的に確信できますが、それは強い構造的制約を課します。パブリックなものはすべてサブディレクトリでなければなりません。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加