gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
GitHubで署名されたコミットにバッジが表示されるようになったので設定してみる - Qiita
まずはこちらの画像をご覧ください。 GitHubのコミット履歴ですが、コミットのSHAの左に見慣れないものが表示されていますね。 クリックするとこのような情報が表示されます。 実は、2016/4/6からGitHubはGPGによりデジタル署名されたコミットやタグにバッジを表示するようになりました。 この記事はその設定ガイドです。私の環境はWindowsですが、すべてコマンドラインとブラウザ上での操作なのでMacやLinuxでも同じように行えます。 1. GPGのインストール Git for Windowsを使っている場合は、GPGが同梱されているため追加のインストールは不要です。 それ以外の方はパッケージマネージャを使ってインストールするか、こちらからツールをダウンロードします。トップにはソースコードのリンクが掲載されており、バイナリのダウンロードリンクは下のほうにあります。 画面の指示に従
特定のコミットが含まれるGitHub Pull Requestを開く
今日たまたまあるコミットが含まれているGitHubのPull Requestをサクッと探したい事案が発生した。というのも自分が以前書いたコードがどうしてこうなっているのかというのを知りたかったんだけど、commit messageだけじゃよくわからんかった(〜を実装したみたいなことを英語で書いてあっただけ)。 Pull Requestは割と丁寧に説明を書いているのできっとPull Requestのdescriptionを見ればわかりそうという感じはしたのだけれどパッとそれを開く手段がわからず、色々ググったりtwitterで教えてもらったりした結果下のようなfunctionをzshrcに書いた。 function find-pr() { local parent=$2||'master' git log $1..$2 --merges --ancestry-path --reverse --
レビューしやすいPRの作り方 - 大きいPRを複数に分割する - - Qiita
こんにちは、freee でエンジニアをしている @nasa4w です。 この記事は freee Engineers Advent Calendar の10日目です。 今回は大きな機能を複数のPRに分割する話をします。 freeeでも絶賛模索中の取り組みなので現在進行形の話ですm(_ _)m まとめ - 今回作ったブランチとPR - 長くなってしまったので結論をさきに置いておきます。PRを複数に分割する場合のゴールはこんな感じ。 Why?（なぜこうしたか） こうすることで、常に work ブランチを使って動作確認ができる レビューする PR を２つに分割できる view の PR と logic の PR レビュー指摘の反映は、topic_view, topic_logic ブランチに commit すればOK work ブランチにはこの2つのブランチを merge しなおすだけでOK PR
gitとプルリクエストに関して思うことまとめ - Qiita
※この記事は元々「Gitのこれやめて！リスト」として2015年11月に投稿したものを改訂したものです。 この記事について 私が個人的にgitとプルリクエストについて、「こうして欲しい」とか「これはやらないで！！」とか思っていることをまとめたものです。 元々は2015年に私がコードレビューをしてる時に気になったことを、あまり推敲もせず思うがままに書いた記事でした。今改めて読み返すと稚拙な文章なのと、他に思うところとがあったりしたので、改めて書き直しました。いいね貰ってるのに書き直すのに若干後ろめたさがあるのですが、よりいい内容にできればと思います。 コミットログがきれいだとレビューしやすい 一人で開発するときはgit使っててもブランチ切らないし、プルリクもださないしで、コミットログも"First Commit"の次が"Second Commit"とかでも支障はないです。しかし、チームで開発す
GitベースのコードリーディングTips - クックパッド開発者ブログ
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
Qiita 記事中のコード片をダウンロードするツール - 詩と創作・思索のひろば
Qiita に書かれた記事、とくにシェルスクリプトに関するものはローカルに保存して実行できる便利な「おみやげ」が含まれているものも少なくない。そして多くの場合そのソースは当該記事そのものであって、Gist にアップロードしています、というようなものはあまり見ないように思う。そういったものをじゃあ利用しようか、と思ったときにコピペしてエディタを開いて保存して……などとするのは癪なので、そのためのツールを書いた。 https://github.com/motemen/qiita-dl インストール % go get github.com/motemen/qiita-dl 使い方 たとえば git commit --fixup で fixup する対象を peco/fzf で選べるスクリプト書いた - Qiita 中の "git-fixup" を保存したい場合、 % qiita-dl -x -d
git commit --fixup とは何か - 詩と創作・思索のひろば
git commit --fixup というオプションの存在を最近知って調べた。 ヘルプとリリースノートより "git commit" learned the --fixup and --squash options to help later invocation of interactive rebase. Git v1.7.4 Release Notes --fixup=<commit> Construct a commit message for use with rebase --autosquash. The commit message will be the subject line from the specified commit with a prefix of "fixup! ". See git-rebase(1) for details. 1.7.4 から入って
テストファーストなGitワークフローについて - kazuhoのメモ置き場
Gitのワークフローに関する話題が、また盛り上がっているようなので、僕が好んで使っているワークフローについて書きます。 対象としているソフトウェアは、GitHubやGitHub Enterprise等を使って開発されている、リリースブランチを切らずにmasterにリリースタグを打っていくだけで十分な程度の、ウェブサービス（の部品）やオープンソースプロジェクトです。 まず、以下の２点を原則として考えています。 origin masterを壊さない origin masterの（1st parentをたどるツリー）にテストを通らないcommitを入れないよう努めます 変更の主題を常に明確にする 前者の理由は、masterをいつでもリリース可能な品質に保つためと(←12:44追記)git bisectするときに困らないようにするため。そして、これらの原則から、以下のようなワークフローで作業するこ
提言: コミットメッセージの一行目には要求仕様を書け - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? これは Git (や Subversion などのバージョン管理システム) にコミットする時により良いコミットメッセージを書くための提言です。この提言は特にメッセージの一行目だけを対象とします。せめて最も重要な一行目だけでも良いメッセージを書いて欲しいからです。提言をズバリ一言で表すと 一行目には要求仕様を書け です。 背景 プロジェクトによっていろいろ慣習の差はあるものの、一般的には「コミットメッセージの一行目は変更内容の要約を簡潔に書け」とされます。特に Git は、各コミットメッセージの一行目だけを取り出してそれを一覧表示するなど
開発フロー研修 @ Wantedly - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサ
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
Yelp: git hookのためのマルチ言語対応パッケージマネジャ - ワザノバ | wazanova
http://engineeringblog.yelp.com/2014/08/announcing-pre-commit-yelps-multi-language-package-manager-for-pre-commit-hooks.html 1 comment | 0 points | by WazanovaNews ■ comment by Jshiike | 約2時間前 Yelpでは、コードレビュー前にgit hookを利用してコードのチェックをしていますが、 プロジェクトごとにhookのbashスクリプトをコピペ/修正するのが面倒。 lintツールなどを利用するには、プロジェクトで使っている開発言語以外の言語用のパッケージマネジャーでインストールしなくてはいけないケースがある。 nodeのプロジェクトで scss-lint（Rubyで書かれている。）を利用する際、プロジェク
JekyllとAlfred Workflow
ブログをJekyllに移行してから軽くなったりしたのはいいのですが、 Wordpress + marsedit(ブログエディタ)等に作らべて不便な箇所は幾つかありました。 具体的には以下のような部分です。 ブログエディタの定番がない 好きなエディタを使えるがこれだというのが見つからない 記事一覧とエディタが一緒になってて欲しい 記事一覧の検索して編集とかしたい 画像のアップロードが面倒くさい わざわざ画像フォルダにコピーして、git addしないといけない これらを少しづつ改善して、今はAlfred Workflowを使って上記をカバーしています。 全体像 今のAlfred Workflowの全体像は以下のような感じです。 全文検索 git commit git push 画像アップロード という感じの作ってあります。 git系のは正直あんまり使ってないですが、一応作った感じです。 以下か
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ブランチの切り替えをしなくてよくなるコマンド git worktree がすごい！ - Qiita
git commit時に英語でメッセージ書くためのヒントを表示する - Qiita
クラウド破産しないように git-secrets を使う - Qiita
GitHub - Moncader/rejs
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
git 同一リポジトリ内でプラットフォームごとにリモートブランチを切って管理する - Qiita
