非推奨のリポジトリと非推奨のブランチのバランスを見つける
（この質問は広すぎる可能性があり、確かに「正しい」答えはありません。）
私は会社のためにいくつかの小さな組み込みプロジェクトを書き直しています。既存のコードに飛び込むのではなく、最初からやり直しています。元のコードは研究プロジェクトのために学生によって書かれました、そしてそれが要点を証明した間、それは深いバグを持っていて、専門的な方法で書かれたか、維持されませんでした。
ここに不満はありません、そもそもそれが可能であったことを証明するために彼らに帽子をかぶっています。ただし、元のコードを保存しようとしても意味がないことを意味します。ゼロから始めて、合意された機能リストと設計ドキュメントから構築する方がはるかに優れています。
これらの新しいプロジェクトを立ち上げて実行しているので、これらを会社に戻すためのベストプラクティスは何ですか？したほうがいい
- すべての古いコードを効果的に破壊し、それを私のものに置き換えるコミットを行いますか？
- または、既存のリポジトリをアーカイブして新しいリポジトリを作成する必要がありますか？
＃1の長所：コードをチェックアウトする人は誰でも完全な履歴を取得します。誰かが古い機能を探しているなら、彼らはそれを簡単に見つけることができます。 ＃1の短所：なぜこのデータのgit履歴を調べると思うのですか？元のコーダーは特にgitに精通しておらず、この方法でコードを検索することを考えそうにありません。
＃2の長所：すべてがクリーン＃2の短所：古いアーカイブ物を保管しておくと、問題が発生し、5年後に遭遇したときにその価値が何であるかを知るのは困難です。誰かが誤ってそれを使用するかもしれません。
一般的に言って、私は決してハード削除のものを言うでしょう。これは、新しいリポジトリで行っていることの一種です。 「アーカイブ」は難しいです、そして一般的に人々は「どこかにコピーを保持するがそれの世話をしない」ことを意味します。
特別な場合がありますが、「一般的に」、ソフトウェア製品のバージョン1とバージョン2を一定期間変更するために維持する必要があります。
つまり、2.0をリリースした後にv1.1をリリースする必要がある場合があります。
Gitを使用すると、これが非常に簡単になります。履歴コミットからタグ付けして分岐し、変更を加えてビルドすることができます。コミットを保持している限り。
'neatness'の新しいリポジトリを作成しているだけの場合、アーカイブリポジトリを失うと、足を踏み入れてしまう可能性があります。
私はそれがその古いコードの責任を誰が持っているかにかかっていると思います。
そうでない場合は、先に進んでください。新しい製品を作成しています。別の名前を使用して、新しいリポジトリを新しい言語で使用してください。バージョン2を作成しないでください。
あなたの場合は、リポジトリを保持するか、メンテナンス計画などで適切にアーカイブします。