Commitizenを使ってgitのコミットメッセージをしっかり書こう | DevelopersIO
はじめに gitのコミットメッセージを記述するとき、内容について悩むことが度々あります。 簡潔に要点をまとめて書きたいけどいちいち記述が面倒だったり、チームで書き方がバラバラだったり・・・ そして結局「fix bug」のひとことだけメッセージを記述するだけになったりします。 この記事ではそんなコミットメッセージを少しでも簡単に有用にするためのツールを紹介します。 Commitizen? コミットメッセージを簡単・簡潔に記述したいときに使えるのがCommitizenです。 Commitizenはインタラクティブにコミットメッセージを作成できるツールで、 このコミットのタイプ スコープ コミットのサマリー コミットの詳細 などについて対話的に記述していくことで、適切なコミットメッセージを作成できます。 ? Select the type of change that you're commit
git-updateがクソ便利 - くりにっき
git-sync にインスパイヤされて作りました qiita.com ソースコード gist.github.com モチベーション 例えばトピックブランチで作業してて、リポジトリのmasterが更新されたから最新のmasterを取り込んでrebaseするってことよくやると思うのですが、その時にいちいち git checkout master git pull --ff git checkout topic_branch git rebase master みたいなことをやるのが大変なのでサブコマンドにしました。 *1 3ヶ月くらい使ってるけど割と開発が捗ってます。 ~/.gitconfig のaliasにも up = update で登録してるので、1時間に1回くらいは g up 叩いてるんじゃないかなｗ https://github.com/sue445/dotfiles/blob/65
アクセスキーのコミットを抑止できて安全便利な awslabs/git-secrets - kakakakakku blog
GitHub で awslabs のリポジトリを眺めてたら git-secrets という便利なツール（シェルで実装されてる）を発見した． どんなものかを簡単に説明すると，アクセスキーなどを誤ってコミットすることを Git の hooks を使って未然に防ぐツールで，誤って GitHub に push してしまったために，AWS を不正利用されてしまった，みたいな事故もたまに聞くし，そういうのを防ぐことができる．非常に良かったので，一部のリポジトリに git-secrets を設定した． github.com インストール make install でも良いけど，Mac なら brew が使える． $ brew install git-secrets インストールすると git secrets コマンドが使えるようになった． $ git secrets usage: git secrets
なぜ git rebase をやめるべきか - Frasco
Git での開発を数年間経験した後、徐々に日々の仕事の一部として、より高度な Git コマンドを使うようになりました。私は Git rebase を見つけてすぐにそれを毎日の仕事に使いました。リベースに精通している人は、どれだけ強力で魅力的なツールであるのか知っているでしょう。しかし、リベースには、初めてリベースを触ったときにはわからなかったのですが、いくつかの課題があることに気が付きました。これを説明する前に、マージとリベースの違いをおさらいしておきましょう。 最初に、feature ブランチを master にマージする例を考えてみましょう。マージすることにより、新しいマージコミット g を作成します。下のコミットグラフではマージした際に何が起こるのかを説明しています。また、開発が盛んなリポジトリでよく見かける「線路」のようなグラフになっているのが見て取れるでしょう。 マージの例 ある
git-hyper-blame のセットアップ方法と使い方
任意のコミットを無視して git blame してくれるやつ。いわゆるメガコ ミットを無視した blame をしたいときに使える。 なぜかセットアップにひどくハマったのでメモ。 セットアップ方法# git clone してくる $ git clone https://github.com/google/proto-quic.git 以下のように、パスの通ったディレクトリに git-hyper-blame という 名前のシンボリックリンクを作る。git のサブコマンド hyper-blame が 利用可能になる $ ln -s ~/src/github.com/google/proto-quic/depot_tools/git_hyper_blame.py ~/bin/git-hyper-blame ※ Python は macOS Sierra 付属の /usr/bin/python (P
AWSアクセスキーをgitに誤って登録しないようにする | DevelopersIO
はじめに Gitはとても便利ですが、GitHub上で不適切に公開されている秘密鍵を使ってAWSに不正アクセスする事例が発生 というようにAWSアクセスキー、シークレットキーを誤って登録してしまうととても恐いことになります。利用者側で気をつけられるようにGitのフックをつくってみましたので報告します。 Git フックとは? Gitにはフックというなにかの操作の前後にスクリプトを実行できるような仕組みがあります。これを使うことにします。コミットの前に気づければよいのでpre-commitを使うことにします。サンプルファイルが .git/hooks/pre-commit.sampleにありますが、今回はシンプルにしたいので、.git/hooks/pre-commitをスクラッチで作ります。 アクセスキー混入防止フック とてもシンプルです。git diffをしてその中に KEYという行があり、さら
新人さんにより良いコミットメッセージを書いてもらうための対話式スクリプト - Qiita
作ったもの コミット時に対話式で質問を表示させるものをつくりました。 ↓こんな感じ↓ 回答の内容をつなげたものがコミットメッセージになります。 質問リストは別のファイルで自由に設定できるので、 チーム内でコミットメッセージへ書いて欲しい内容をゆるく共有したい場合に。 How to use スクリプト本体はこちら #!/bin/sh set -e # core.editorに設定したいもの # merge,rebaseなどの時に起動する CORE_EDITOR=vi # commitじゃなかった場合(mergeとかrebaseとか)の場合はCORE_EDITORに渡す if [[ ! "$1" = *COMMIT_EDITMSG ]]; then $CORE_EDITOR $1 exit 0 fi CURRENT_DIR=$(cd $(dirname $0); pwd) MSGLIST_FI
Git Undo
Tell me if you recognize this scenario: you’re in the middle of rewriting your local commits when you suddenly realize that you have gone too far and, after one too many rebases, you are left with a history that looks nothing like the way you wanted. No? Well, I certainly do. And when that happens, I wish I could just CTRL+Z my way back to where I started. Of course, it’s never that simple — not e
git-reviewer 書いた - その手の平は尻もつかめるさ
code review の reviewer 選出をする時，pull request の内容をざっと眺めてから「この部分だから XX さんかな」とか「あそこのコードは YY さんが詳しいだろう」とか，そういう感じで選ぶことが多くて，つまりは勘と経験で選びがちになってしまう．これについては常々いくばくかの危うさを感じていた． そもそも，「reviewer として誰が最適か」という知識はプロジェクトに長く関わっている人でなければ知りにくいものであり，いわば属人的な知識のひとつだと思っている．プロジェクトからそういった長老的な人がいなくなってしまったら，最適な code review を実施できなくなってしまう可能性がある． 従って，やはり技術で解決ということになる． Facebook が作っている mention-bot という GitHub の bot として動作するやつがあって，これは p
git branch の結果を時間順にソート: git branch --sort=-authordate - Islands in the byte stream
id:kazuho さんと「gitのbranchを消すべきか否か」という話をしていて、ぼくの「ローカルにせよリモートにせよbranchが増えすぎると目的のブランチを見つけられない」という意見に対して次のエントリを教えてもらったのでした。 git branch の結果を時間順にソート - kazuhoのメモ置き場 一理あるかもしれないと思ってこれをgitに組み込むためにgitのソースコードを眺めていたら、実はもうできるということを知りました。それがこれ: # 新しいのが下 git branch --sort=authordate # 新しいのが上 git branch --sort=-authordate このソートに使えるフィールドは、 git branch --help を引くと "The keys supported are the same as those in git for-e
git blameによるSRP（単一責任原則）の定量化 - どこでも見れるメモ帳
はじめに ソースコードを静的解析することでSRP（単一責任原則）を定量的に算出します．*1 svn blameによるSRP算出*2を参考に、git blameによる算出をshで行ってみました． このSRP値が最大のモジュールが王様モジュールに相当します． # 単一責務性の違反指数（SRP） # SRP＝R＋U＋((L/100)－5) # R：修正リビジョンのユニーク数 # U：修正ユーザのユニーク数 # L：モジュールのライン数 function get_SRP() { local target_filepath=$1 echo $(( \ $(git --no-pager blame --line-porcelain $target_filepath | sed -n 's/^summary //p' | sort | uniq -c | sort -rn | wc -l) + \ $(
git push --force でなく git push --force-with-lease を使う - valid,invalid
前に社内チャットで流れてて初めて知った。 他人の変更を上書きするおそれのある git push --force でなく、最後に fetch したタイミング以降に他人が push していたら失敗する git push --force-with-lease を使う方が良い。 --force considered harmful; understanding git's --force-with-lease - Atlassian Developers Quipper では GitHub flow のような開発フローを採用している。 各開発者が feature branch を作成し、master / develop branch へ pull request を作る流れだ。 他人と修正箇所が重なってコンフリクトした際には rebase が必要で、 rebase 後の内容を push する際には
gitコマンド派閥 - 弥生開発者ブログ
Misoca開発チームのmzpです。 開発チームでgitコマンドの使い方について話したら、それぞれ使い方が微妙に違っていることが分かりました。せっかくなので、それぞれの人に、なぜその使い方をしているか聞いてみました。 一時的に変更を退避させる方法 作業を中断するときにするとき、作業中の内容を退避させる方法です。 git stash派 git stash で退避させる派です。 そして再開するときは、 git stash pop で退避させた内容を適用します。 使っている理由は「コミットする内容はキレイに保ちたいので、作業中の内容はコミットしたくない」でした。 適当にコミットする派 適当な内容でコミットし、あとで cherry-pick するなり、 rebase するなりする派です。 使っている理由は「退避した内容をリモートのブランチにpushしたいので、普通にコミットしている」でした。 pu
僕のチームのGitの開発フロー - Mitsuyuki.Shiiba
を考えてみる。 Git Flow nvie.com やってみたことある。良いんだけど、僕の環境だと、もうちょっとシンプルにやれそうかなって思った。 Github Flow scottchacon.com これはシンプルだな。なんだけど、シンプルすぎてちょっと違うかな。 ということで、ちょうどいいくらいのを考えてみたい 今の僕の開発にとって、ちょうどいいくらいのを考えてみたいなーって。じゃあ、今の僕のやってる開発ってどんなん？ってところから。 チーム エンジニア5,6人くらい。 Feature, Story, Task Featureと呼ばれるものがあって、これは2,3ヶ月分の規模で。この単位でリリースする。 Featureは複数のStoryで構成されていて、Storyは4,5日くらいで完了する。から、1 Featureは10から15Storyくらいってことか。 Storyは複数のTaskを
CI ビルド URL を開く ciopen コマンド - Qiita
元ネタは Quipper の CTO (@tomo) が社内向けにシェアした zsh コマンド。別途 hub をインストールしてください。 https://hub.github.com/ # 使い方: # 1. 以下を .bashrc などにコピペして保存 -> 端末・シェル再起動または .bashrc 再読み込み # 2. Git リポジトリを clone したディレクトリに移動 -> Pull Request と紐付いているブランチを checkout # 3. $ ciopen [COMMIT] # $ ciopen head # $ ciopen head^ # $ ciopen head~2 ciopen() { commit=$1 result=$(hub ci-status -v $commit) if [ $? == 3 ]; then echo $result else
GitベースのコードリーディングTips - クックパッド開発者ブログ
こんにちは、投稿推進部の森川 (@morishin127) です。 エンジニアが既存のプロダクトの開発に携わる際、他人の書いたソースコードを読み解くところから始まります。過去に書かれたコードの意図を理解することは自分が書いたものでもしばしば難しく、他人が書いたものならなおさらです。この記事では過去に書かれたコードを理解するための工夫についてお話したいと思います。 なお、この記事ではプロダクトのソースコードはgitおよびGitHubのPull Requestを利用して開発が進められていることを前提としています。 特定の行から関連するPull Requestページを開く クックパッドのソースコードには概してコメントがあまり書かれておらず、見ただけでは理解しづらいような特殊な方法をとっている場合のみコメントを書いている印象です。基本的に実装に関する説明はソースコード中ではなく、GitHubのPu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - muesli/gitomatic: A tool to monitor git repositories and automatically pull & push changes
http://blog.inouetakuya.info/entry/20120826/1345979787
GitHub - jayphelps/git-blame-someone-else: Blame someone else for your bad code.
クラウド破産しないように git-secrets を使う - Qiita
