Gitのコミットメッセージの書き方 | POSTD
(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳： プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest
GitHub : ノマドなエンジニア達とRubyをスケールさせる | Yakst
GitHubの技術ディレクターが語る、GitHubのインフラの特徴と、社員の6割がリモート勤務という社風、Hubotを使った協力的かつ新しい働き方。 Sam Lambertは、2013年にGitHubの最初のデータベース管理者として入社し、現在はGitHubの技術ディレクターを務めています。このインタビューで彼は、今や1000万以上のユーザと2500万以上のプロジェクトを誇るサービスが、比較的シンプルな技術的スタックの上でどのようにスケールし続けてきたのかを考察しています。また、自作のパワフルなチャットボットであるHubotを使ってコラボレーションしつつ、従業員の約6割がリモートで働いているという、GitHubの大規模なオフィスレスな仕事環境についても触れています。 SCALE: 私としては、GitHubはテクノロジーのユーザーというよりは主にテクノロジーの提供者であると思っていますが、そ
グーグルのバグ予測アルゴリズムを実装したツール「bugspots」、オープンソースで公開
ソースコードのなかでバグが多いのは、より高頻度に、かつ最近になって集中的に直している部分。これが、グーグルで採用された「バグ予測アルゴリズム」であることを、先月の記事「グーグルはコードの品質向上のため「バグ予測アルゴリズム」を採用している」で紹介しました。 そのバグ予測アルゴリズムを実装したツール「bugspots」がオープンソースとして公開されています。 gitのレポジトリを分析 bugspotsはRubyで記述されており、gitのレポジトリから履歴を読み込んで分析し、どのモジュールにバグが含まれている確率が高いかを示してくれます。 以下のようにインストールして実行（説明ページから引用）。 $> gem install bugspots $> git bugspots /path/to/repo $> git bugspots . # (in current git directory)
Git活用法 ー コードはいつも1行ごとにドキュメント化されている | POSTD
コードには1行ごとに隠しドキュメントがあります。 次のコードスニペットの4行目を書いた人は、何か理由があってDOMノードの clientLeft プロパティにアクセスしたのでしょうが、結果的に何もしていません。これはかなり不可解です。なぜこうしたのか、あなたは説明できますか？ 今後、この呼び出しを変更したり削除したりしても安全でしょうか？ // ... if (duration > 0) this.bind(endEvent, wrappedCallback) this.get(0).clientLeft this.css(cssValues) 私ではなく他の人があなたにこのコードを見せたとして、誰がこの行を記述したのか、どんな理由があったのか、このままの状態にしなければいけないのか、あなたはおそらく説明できないでしょう。ただし、プロジェクトを進めているときは大抵の場合、バージョン管理シス
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
Visual Studio 2013 Update 3 で CodeLens が Git に対応して凄く便利になった話 - しばやん雑記
かなり今更な感じですが、仕事中に Visual Studio 2013 Update 3 で追加された CodeLens の Git 対応について話に上がったので書いておきます。 Code Lens for Git in Visual Studio 2013 Ultimate Update 3 – Microsoft DevOps Blog CodeLens for Git improvements in Visual Studio 2013 Ultimate Update 3 RC – Microsoft DevOps Blog CodeLens はクラス定義やメソッド定義の部分に表示されるアレです。Update 2 までは参照数ぐらいしか表示されていませんでしたが、Update 3 からクラスやメソッド単位での変更数やコミットログの確認が出来るようになりました。 誰によって何日前にコミ
Codebrag·Subversion/Git対応のコードレビューシステム MOONGIFT
コードレビューしてますか？ チームのコード品質を向上し、ひいてはシステム品質の向上を目指すためにはコードレビューが欠かせません。工業製品のように一定の品質を担保する技術がない以上、チーム全体でコード品質をあげていくのが最もいい方法ではないでしょうか。 単純に書いたコードを見せるだけでなく、Web上で確認、コメントできるようにすればより優れたコードレビューができるようになると思います。そこで使ってみたいのがCodebragです。 ログインします。 ログイン後。左にレビュー待ち一覧が並んでいます。 項目を選択すると差分が表示されます。 コード中にコメントできます。この辺りはGitHub風ですね。 ハートマークでいいねもできます。 Codebragの特徴としてはGIt/Subversionをサポートしているということがあります。バージョン管理システムの問題なので、GitHubやBitBucket
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログチームの開発フローとGitHub