命名スタイルのコミット

多くの開発ポイントに関する多くの情報があります。 コメントの書き方、クラスの命名方法、メソッド、使用するパターンなど など しかし、多くの人が何かを改善する可能性についてさえ考えていない1つの領域があります-これはコミットを書いています。



なぜこれが必要なのでしょうか？ 時間と神経を節約するために、これ以上でもそれ以下でもありません。 これについては後ほど説明しますが、ここでは、コミットが一般的にどのように呼び出されるかを検討します。

一般的なスタイル

GitHubで同じコミットを実行すると、コミットを作成するためのかなり多数のオプションが表示されます。 執筆に関する主な推奨事項は次のとおりです。

対処方法+どのエンティティ+詳細（オプション）

コミットの一般的なスタイルを見つけて、それに固執するようにしてください。 私自身は、自分が何をしているかを最初に示したときに、このスタイルが便利だと感じました。 たとえば、 add



ます。 その後、アクションを実行していることを示します。 たとえば、 ui-bootstrap.js dependency



。 ほとんどの場合、そのような記録は十分すぎるほどです。 説明的な碑文がある場合は、別の大きなエントリに入れる方がよいでしょう。これについては後で説明します。 レコードが小さいが非常に必要な場合は、コミットに直接追加できます。 しかし、この碑文が本当に必要なのか、それとも不必要な注意を引くのかをもう一度考えた方が良いでしょう。



次のようになります。

 dependency for managing ui-bootstrap.js components was added here on 18.06.2013 by olegafx
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、より良い：

 add ui-bootstrap.js dependency
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コミットの大きな投稿

それで、大きなメッセージをどうするか？ もちろん、書いてください。 たとえば、コミットによって以前の機能が中断され、非常にクールでシンプルな新しい機能に置き換えられるというメッセージを含む重要な情報になる場合があります。 これは大規模なプロジェクトでも発生するため、再び機能させる方法を人々に伝えることが非常に重要です。



最も簡単な方法は、コミットのメインメッセージの下に空の行を追加し、そこにすでに情報を入力し始めることです。 ちなみに、本当にしたいのであれば、ここでは過去形で既に動詞を書くことができます。 例：

 replace twitter-bootstrap.css with pure.css Made UI much cleaner. BREAKING CHANGE. You need to use new class-names for grid-related elements.
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

小文字でメッセージを書く

最初の単語を大文字で書く特別な理由はありません。 少し読みやすくなりました。



次のようになります。

 Add ui-bootstrap.js dependency ADD ui-bootstrap.js dependency
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、より良い：

 add ui-bootstrap.js dependency
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

過去形を使用しないでください

シンプルなほど良い。 経過時間は、メッセージの読み取りが複雑すぎます。 Gitにアクセスしていると想像してください。「Git、追加」、「Git、削除」など。



次のようになります。

 added ui-bootstrap.js dependency
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、より良い：

 add ui-bootstrap.js dependency
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

余分な句読点を削除します

たとえば、メッセージの最後にピリオドが必要なのはなぜですか？ 完成したことは明らかです。 同じことがセミコロンにも当てはまります。



次のようになります。

 add ui-bootstrap.js dependency;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、より良い：

 add ui-bootstrap.js dependency
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ロシア語

コミットでロシア語を使用するのは恥ずべきことではありません。 しかし、このコードがロシア語を話す人々にのみ興味深いものであると確信している場合にのみ、これを行う必要があります。 たとえば、すべてのStas Mikhailovファンのマップを指すVKのスクリプトがあります。 明らかに、これは外国人にはほとんど関心がありません。 そして、ロシア人にとっても、正直に言うと。

送信する前にブラシがコミットする

ローカルリポジトリ内のすべてのコミットには、好きな名前を付けることができます。 「temp commit 1」が一部の機能の最初の動作バージョンであり、「temp commit 2」が修正およびリファクタリングされたバージョンであることを覚えておくのが簡単な場合は、誰もあなたをscらないでください。 しかし。 巨大なしかし。 送信する前に、可能な限り最善の方法でコミットをお寄せください。 ほとんどの場合、優れたコマンドは次のことを行います。

 git rebase -i
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを使用すると、適切な形式のすべてのルールに従って、コミットを正しい順序で並べ、結合し、名前を変更できます。 非常に強力で便利なコマンドですが、やりすぎないでください。そうしないと、いくつかの新しい機能の最終バージョンのコードが、最初のバグのあるバージョンのコードによってブロックされる可能性があります。 既にコードをリモートリポジトリに送信している場合は、リベースを使用しない方が良いです。そうしないと、悪化します。

お気に入りのスタイルを見つけてください。

AngularJSプロジェクトで見つけました。 コミットに関する別のドキュメントもあります。 上記で説明したすべてのポイントは、このドキュメントにあります。 それは素晴らしいことです。 なぜなら、私はこれらの瞬間をさまざまなソース、私自身の経験から自分自身で探す必要がありましたが、ここではすべてがすでに1つの場所にあり、良いシンプルな言語で書かれています。 要点を簡単に検討してください。

コミットのタイプを指定する

事前定義されたタイプがいくつかあります。

• 機能-新しいアプリケーションレベルの機能を追加するときに使用
• 修正-重大なバグを修正した場合
• docs-ドキュメントに関連するすべて
• スタイル-タイプミスを修正し、フォーマットを修正
• refactor-アプリケーションコードのリファクタリング
• テスト-テストに関連するすべて
• 日課-定期的なコードのメンテナンス

これらのタイプは、アプリケーションの作成時に簡単に区別できるとは限らないため（リファクタリングや雑用など）、独自のタイプを思いつくことができます。

スコープを指定する

コミットのタイプの直後に、スペースなしで、コミットが適用される領域を括弧内に示します。 その後、標準のコミットを作成します。



たとえば、モジュールスコープがあります。

 refactor(audio-controls) use common library for all controls
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはファイルの範囲：

 chore(Gruntfile.js) add watch task
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは何のためですか？

記事の冒頭で述べたように、時間と神経を節約するために！ 次の操作を簡素化することにより：

• 変更リスト（CHANGELOG.mdなど）の自動生成。 完全に形成されていなくても、少なくとも少しの修正の開始点があります。
• すべてが壊れた場所を探すときに不適切なコミットを無視する（たとえば、 git bisect
  
  
  
  を使用する）;ドキュメント、テスト、コードスタイルなどを改善するコミット すぐにスキップできます。 オーディオ制御モジュールが破損している場合、このモジュールがスコープで指定されているメッセージのみが表示されます。
• より豊かで理解しやすいプロジェクトの歴史。

おわりに

まだ退屈していないことを願っています。 プロジェクトで適切なコミット命名スタイルを使用してみてください。 他の人はあなたにとても感謝しています。



それだけです あなたのプロジェクトから命名の興味深い例があれば、コメントでそれらを見て喜んでいるでしょう。 テキスト内のすべてのエラーをプライベートメッセージに送信できます。



素敵なコーディングを！