問題タブ [revision-history]

バージョン管理システムへのオンラインインターフェイスを使用することは、コードの最新バージョンの公開された場所を取得するための優れた方法です。たとえば、ここにLaTeXパッケージがあります（変更が実際に機能することが確認されるたびにCTANにリリースされます）。

http://github.com/wspr/pstool/tree/master

パッケージ自体は単一のファイル（この場合はpstool.tex）から派生し、処理されると、ドキュメント、readme、インストーラーファイル、およびLaTeXで使用されるパッケージを構成する実際のファイルが生成されます。

このようなものをダウンロードしたいユーザーが簡単に利用できるように、上記のすべての派生ファイルとマスターファイルpstool.texをリポジトリ自体に含めます。これは、パッケージファイルpstool.styがマスターファイルの生成されたサブセットであるため、コミットするたびに2倍の数の変更があることを意味します。

これはバージョン管理の変質ですか？

@ Jon Limjapは良い点を挙げました：

バージョン管理をダウンロードサーバーとして使用する代わりに、生成されたファイルをダウンロード用に別の場所に公開する別の方法はありますか？

この場合、それが問題の核心です。はい、パッケージのリリースされたバージョンは他の場所から入手できます。したがって、生成されていないファイルのみをバージョン管理する方が実際には理にかなっています。

一方、@ Madirのコメントは次のとおりです。

現実的で繰り返される利便性は、舞台裏で負担されるコストを上回ります。

また、ユーザーがバグを見つけてすぐに修正した場合、ユーザーはリポジトリに移動して、「インストール」手順を実行せずに作業を続行するために必要なファイルを取得できるという点でも適切です。

そして、これは私の特定のプロジェクトセットのより重要なユースケースだと思います。

個人的な資料やメールなどを保存するための広いスペースを提供する無料のオンラインサービスはたくさんあります。しかし、変更履歴を保持するコードをホストできる場所はありますか？

Google CodeやSourceForgeは、他の人にとって具体的で有用なプロジェクトを作成する必要があるため、理想的な場所ではないかもしれません。一方、私が欲しいのは、有用だと思うが他の人には役に立たないと思うあらゆる種類のコードを保持する場所です。

Killswitchcollective.com の古い記事 (2009 年 6 月 30 日) には、次の入力と出力があります。

OS/X で Gitk や Gitx を使用せずに、ターミナルでコミットのツリーのようなビューを取得する方法に興味があります。

ターミナルでコミットのツリーのようなビューを取得するにはどうすればよいですか?

Subversion では、 TortoiseSVNを使用してファイルの履歴/ログを表示できました。

Gitでこれを行うにはどうすればよいですか?

特定のファイルの履歴レコードと、異なるバージョンを比較する機能を探しているだけです。

svnから来て、gitに慣れ始めたばかりです。

ブランチがgitで削除されると、履歴から削除されますか？

svnでは、削除操作を元に戻す（逆マージ）ことで、ブランチを簡単に回復できます。svnでのすべての削除と同様に、ブランチが実際に削除されることはなく、現在のツリーから削除されるだけです。

ブランチが実際にgitの履歴から削除された場合、そのブランチからマージされた変更はどうなりますか？それらは保持されていますか？

Ruby on Railsを使用して StackOverflow の質問の改訂履歴と同じシステムを実装する場合、それを達成するために何をする必要がありますか? ユーザーが投稿したコンテンツを他の人が更新できる wiki のように機能するサイトを作成しています。これらの変更の履歴を追跡できるようにする必要がありますが、これを実装する方法に精通していません。

解決：

簡単に言えば、これが機能する方法は、変更を追跡するために追加のテーブルを作成することです。テーブルの各行には、レコードが変更される前に存在していたデータ (または変更されたデータのみ) の「スナップショット」があります。

ほとんどの作業をすでに完了している Ruby Gem がいくつかあります。これは、バージョン管理/リビジョン履歴を扱う gemのリストです。Paper Trailは現在、これを行うための最も人気のある gem のようです。Ryan Bates が RailsCast を記録し、Paper Trail の使用方法の概要を説明しています。

仕事では SVN を使用していますが、個人的なプロジェクトでは Git を使用することにしました。それで、昨日 Git をインストールしましたが、Git に相当するリビジョン番号は何だろうと思います。

バージョン 3.0.8 に取り組んでおり、すべてのバグ修正には、このバグ修正について話すときに使用できる独自のリビジョン番号があるとします。では、Git のコードに 3.0.8 のタグを付けると、リビジョン番号やその他のより詳細な種類の識別として何を使用できるでしょうか? ハッシュは人間にとってあまりユーザーフレンドリーではないことがわかりました。

私は自分の歴史をこぼしたので、それにいくつかの変更を加えたいと思っています。問題は、関連のない 2 つの変更を含むコミットがあり、このコミットがローカル (プッシュされていない) 履歴の他の変更に囲まれていることです。

このコミットをプッシュする前に分割したいのですが、私が見ているガイドのほとんどは、最新のコミットまたはコミットされていないローカル変更の分割に関係しています。それ以来、私のコミットを「やり直す」必要なく、歴史に少し埋もれているコミットに対してこれを行うことは可能ですか?

アプリケーションで (作業中に) 例外がスローされたときに、誰を「責める」べきかを特定する方法を作ろうとしています。もちろん、それは私が引き起こしている可能性がありますが、私はそれを受け入れることができます:)。しかし、これを行うには、例外の行で最後に誰が変更を行ったかを確認できるように、TFS のファイルの履歴が必要です。もちろん、誤った変更が挿入された例外の行に常にあるとは限らないため、おそらく同じファイルへの変更と、最後に最近行われたチェックインも確認する必要があります。これをどのように解決するかはわかりませんが、これに対する既存の解​​決策があるかどうか、最初にコミュニティに確認したいと思いますか? 私はまだ TFS API の経験がないので、何が可能で何が不可能かを判断する方法がありません。これを未処理の例外ハンドラーでアプリに統合すると思います。例外の候補が見つかったら、メールで通知する必要があります。その過程で、特定の例外がイントラネット上のユーザーによってスローされた回数、誰が、いつ、どのようにスローしたかなどをログに記録すると便利です。これにより、多くの時間 (およびお金) を節約できます。

次のエイリアスがあります。

これを で実行すると|wc -l、プッシュされていないコミットが 394 個あることがわかります。この番号を使用して実行しますgit diff somecommitid HEAD~394。これは次のエラーで失敗します。

奇妙なことに、それは 358 番まで正しく動作します。別のクローンでは、478 個のコミットがあり、git コマンドを含むgit showHEAD~411 まで動作し、その後失敗します。手がかりはありますか？Debian Linux で git 1.7.5.2 を使用しています。