gitを操作するためのいくつかのトリック

gitバージョン管理システムに関するチュートリアルを読んでいると、1つのプロパティに気付きました。それらのほとんどは、読者に分散バージョン管理システムのすべての利点を理解させることを目的としています。 このセクションでは、通常、リモートリポジトリ、ブランチ、プッシュ、プールなどについて説明します。



しかし、ツールの使用中に、そのような瞬間が発生します（特に、さまざまな事実、フォーラム、インターネット上の記事で研究されている場合）、それを使用するのに十分な知識をすでに持っているように見えますが、少し泳ぐ瞬間。 そのため、通常の本を取り上げて、最初から最後まで読み始めます。



もちろん、そのようなアプローチは最初から適用する必要があるかもしれません...それはできませんが、最初から適用する必要がありますが、いつものように、いつものように、常に十分な時間、努力、欲求などがありません



しかし、実際にはこの記事はそれについてではありません。 最近発見した2つの素晴らしいgitコマンドについてお話したいと思います。 これはgit blameとgit bisectです

ファイルの概要

コードにある種のバグを見つけると、誰がこれをいつ書いたかがひどく面白くなることがよくあります。 （もちろん、彼が何を考えていたのか、どこでボタンを押したかを知りたいのですが、もちろんgitは無力です）



git blameを使用すると、ファイルの各行がいつ、誰によって最後に編集されたかを確認できます。



次のコマンド



git blame -L 12,22 products.php







表示されます

 ebf9cf99 (vasia 2011-11-16 15:07:52 +0400 260)$templates = $controller->getTemplates(); ebf9cf99 (vasia 2011-11-16 15:07:52 +0400 261) foreach($templates as $value)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

出力には、コミットの簡単なハッシュ、作成者、最終変更日、および実際のコード自体が含まれます。 目的のコミットにすばやく切り替えて、失敗の原因を理解できます。



また、コマンドに-Cオプションを指定すると、最初に追加されたファイルに関係なく、リポジトリのどこから必要なコードフラグメントが出現したかを確認できることに注意してください。



git blame -L 10,19 -C Controller.php

 3351a8dc /logistics/pages/Controller.php (vasia 2012-01-24 15:26:04 +0400 10) 0cb0d219 /orders/pages/Controller.php vasia 2012-01-13 09:51:54 +0400 16)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その場合、これらの変更の作成者があなた自身に他ならないことを発見することは驚くべきことです）

バイナリ検索

話したい2番目の機能は、コミットによるバイナリ検索機能です。 例として以下の状況を挙げます。 プロジェクトでいくつかの機能が壊れており、具体的な問題を理解することはできませんが、前回のリリースではこの機能が正確に機能することは確かです。 そのため、bisectコマンドを使用すると、プロジェクトを指定された数のコミットに簡単にロールバックし、わかりにくいバグが初めて現れるコミットを見つけることができます。



まず、検索メカニズムを開始し、プロジェクトの現在の状態が機能していないという値を設定します

 git bisect start git bisect bad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、プロジェクトの作業状態にロールバックします-履歴に10回コミットします



git bisect good HEAD~10







このバグが現在の状態で現れるかどうかを確認します。 今はすべてがプロジェクトで問題ないので、さらに検索を続けます



git bisect good







このチームは、良いコミットと悪いコミットの間で、プロジェクトの状態を巻き戻します。つまり、過去5回のコミットです。 バグが表示された場合、現在のコミットの前であり、そうでない場合、その後です。 そのような反復のたびに、悪いコミットが見つかるまで距離が半分に減少します（そして最も重要なのは、その作者、残念なことに、もう一度やりました）。



検索が完了したら、リポジトリを元の状態にリセットします



git bisect reset







序文に戻って、私にギタを教えることで、この本は、すべてのeに点在するでしょうが、この本になりました 。 これは最も詳細な説明ではないかもしれませんが、私の意見では、「これを行うことができます」状態から「これを行うことができ、これを行う必要がある理由を理解する」状態への移行には非常に良い選択肢です。 ロシア語への翻訳もあります （完全ではありませんが）。



これに関する私の話を終わらせたいと思います。説明した機能が、gitを発見したばかりの人だけでなく、仕事でも役立つことを願っています。



UPD。

水銀の場合、この機能も存在します。

非難-hg annotate

また、検索用に特別なプラグインがあります-mercurial.selenic.com/wiki/BisectExtension



svnには

svn blame TARGET [@REV]