[Git]commit約定(タイプ:subjectの重要性)


commitはバージョンを決定する操作です.
皆さん.
commitの時どのように伝言しますか?
誰も決めてくれなくても、経験から味わうことができます.
「なぜ」「いつ」の理由は経験上知っているからです
「どうですか」を分かち合いましょう.
次の写真は学習アルゴリズムの記録を提出します.
バージョンを管理する必要はありません.コミットレコードなので問題ありません.
プロジェクトでは状況が異なる
複数のコミットメッセージが積み重ねられた場合
欲しいバージョンに達するためにCOMMITを確認する必要がありますが、情報がそうであれば冷や汗をかきますよね?

どうしよう。


では、commitではどのようにメッセージを送りますか?
もちろん、バージョンを推定するために説明を書く必要があります.
しかし、説明を書く方法があります.
もしあなたが一人で仕事をしていたら、私があなたを認識できればいいです.
コラボレーションまたはリモート・リポジトリで共有している場合は、他のユーザーがそれを見ることができます.
個人的には、一人で仕事をするプロジェクトでも、フォーマットのないメールは悪い習慣だと思います.
その時の気持ち次第で、メッセージの仕組みが変わるかもしれません.
私が作ったのですが、私が読めないような悪口を言う確率が高いです.
冊「clean code」の画像

commit message convention


そのため、世界では「どうするか」に共通の習慣があると推測できる.
ご推測の通り、commit messageにも約束があります

コミットメントメッセージの約束を見てみましょう


https://udacity.github.io/git-styleguide/
commit messageには、次のものが含まれます.
Message structureType:Subject空白行body空白行footer
  • タイプとトピックはtitleと呼ばれ、記入する必要があります.
  • 本文とフッター(必要に応じて)

    type :

  • commitのタイプ
  • を指定します.
  • 7種類あります
  • feat:A new feature
  • fix: A bug fix
  • docs: Changes to documentation
  • style: Formatting, missing semi colons, etc; no code change
  • refactor: Refactoring production code
  • test: Adding tests, refactoring test; no production code change
  • chore: Updating build tasks, package manager configs, etc; no production code change
  • subject :

  • 50文字以下
  • 頭文字大文字
  • 動詞(円形)
  • 句点を引かない
  • body :

  • 、詳細な説明が必要な場合に作成
    なぜ何をするのか(どうするのかではなく...!)を記入しなければなりません.
  • 行あたり75文字以下
  • footer :

  • 期トラッカーIDを指定する必要がある場合は、
  • に記入してください.
    例は次のとおりです.
    「感じはありますか?」

    type:Subjectの重要性


    その中でtitleが一番重要です
    githubから見えるスクリーン
    type:Subjectが表示されます
    いいえ、type:主語しか見えません...!
    cf. 
    1. type 은 첫글자도 소문자로 쓰는건데 대문자로 썻네요...! 
    2. 처음 써본거라 길이에 대한 감과, 어느정도의 정보를 써야하는지에 대한 감이 없었네요...! 
    저도 올바른 개발자 문화에 동참하기 위해 차츰 보완해 나가겠습니다
    Githubに表示される画面、リモート・リポジトリ(Remote Repository)
    commit messageのtype:Subject部分のみ表示
    local repositoryのgit logを表示するにはtype:Subjectセクションのみが表示されます.

    したがって,type:Subject部分はtitleと呼ばれ,最も重要な部分といえる.
    titleは最も直接的で、コミュニケーションの中で最も強い部分でもあります!
    だから適当な長さ、コアの説明を書きます.

    でも…。


    もちろん、組織に参加する慣例がある場合は、組織の慣例に従わなければならない.
    "말 그대로 convention 이니까요...!"
    Pythonのgithub画面
    少し違いますが、Pythonの組織がルール組織を使用してメッセージを送信しているのがわかります.

    gitメッセージに関する良い資料(Gitの全図は約束の原因を示している)


    ハングル翻訳
    https://meetup.toast.com/posts/106オリジナル