Conventional Commits
Conventional Commits 人間と機械が読みやすく、意味のあるコミットメッセージにするための仕様 Conventional Commits 1.0.0-beta.4 概要 Conventional Commitsの仕様は、コミットメッセージのための軽量の規約です。 明示的なコミット履歴を作成するための簡単なルールを提供します、この規則に従うことで自動化ツールの導入を簡単にします。 この規約はSemVerと組み合わせることで、コミットメッセージへ機能、修正、重大な変更を入れることで、さらに詳細な説明を可能にします。 コミットメッセージは次のような形にする必要があります 原文： <type>[optional scope]: <description> [optional body] [optional footer] 訳： <型>[任意 範囲]: <説明> [任意 本文] [任
GPG鍵を作って運用し、Git(hub)やMercurialで自分が書いたコードに署名をする - kuenishi's blog
自分が書いたコードに署名をしておくことはプログラマの常識であり基本動作です（かくいう私もメールは署名してないけど…）。なので私も一人前のプログラマになるべく、自分が書いたコードに署名をするようにしてみた。 GPG 鍵を作ったり準備したり GnuPGのインストール@MacOS $ sudo port install gnupg 鍵をつくります。有効期限は2年間。もし秘密鍵が漏れた場合でも、2年経てばほとぼりが冷める。 $ gpg --gen-key gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent p
git subtreeの練習
Gitのサブモジュールでは面倒そうな、頻繁に更新される別のリポジトリを取り込む方法としてサブツリーマージを行うラッパーであるgit subtreeコマンドを使う練習を始めた。どちらかというと「参照する」要素の強いサブモジュールに対して、サブツリーは「切り分ける」や「取り込む」という感じなんじゃないかと理解している。全般的に間違ってそうで怖い。 「切り分ける」、つまりリポジトリのサブディレクトリを別のリポジトリにしたい場合は、単純なケースだと親にあたる方で.gitignoreや.git/info/excludeを使ってサブディレクトリを除外してやれば良い。でもこの場合、両方のリポジトリで関連した変更がある時にそれぞれのリポジトリでコミットしてやらないとならないので面倒くさい。 「取り込む」場合はサブモジュールが基本なわけだけど、他で作業して戻ってきてたりする必要があるし、サブモジュールの更新
インデントコミットで真犯人がわからなくなった場合の git blame
config_param :queued_chunk_flush_interval, :time, :default => 1 を追加したコミットがどれかを探したいとします。 しかし、git blame を見るとこんなかんじに、インデントコミットによってほぼ全ての履歴が上塗りされていてどれだかわからない、みたいな状況にどうやって真犯人を探そうかという話です。 1. git blame -w を使う インデントコミットを無視したいだけであれば git blame の -w オプションが使える。-w は比較の際に whitespace を無視してくれるオプション。git diff にもあるよね。 $ git blame -w lib/fluent/output.rb ... (省略) 14d01c71 (Masahiro Nakagawa 2013-03-27 03:56:51 +0900 1
Git で不要になったリモートブランチを削除する - koogawa blog
こんなブランチ構成だとする。 $ git branch -a * master ios7 remotes/origin/HEAD -> origin/master remotes/origin/ios7 remotes/origin/master ios7のブランチを消したい。 まずはローカルブランチを削除 $ git branch -d ios7 Deleted branch ios7 (was 57c1b0b). リモートブランチも削除 $ git push origin :ios7 To https://xxx.git - [deleted] ios7 確認 $ git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/master ちゃんと消えた！ push で消すのとか、:hoge で指定
Git にパッチを送って取り込まれた話
Git の挙動に変なところを見つけたので、パッチを作って Git のメーリングリストに投げてみたところ、何度かのレビューを経て、無事に取り込まれた。 Git に貢献したい人とか、オープンソース開発の流れに興味がある人もいるだろうから、作業の流れを書いておくことにする。 1. バグを発見する 何はともあれ、修正したいところを見つけるところから。 先日、git difftool --dir-diff が便利すぎて泣きそうです という記事を書いたが、difftool --dir-diff の挙動を調べているうちに、一時ファイル書き戻し条件が変なことに気づいた。 手元のバージョンが古いのかとも思ったが、master ブランチでも再現したので、ちょっくら深入りしてみた。git difftool は Perl スクリプトだったので、ソースコードに print を追加しつつ挙動を探っていった。しばらく調
Event Types & Payloads | GitHub Developer Guide
About webhook events and payloads You can create webhooks that subscribe to the events listed on this page. To limit the number of HTTP requests to your server, you should only subscribe to the specific events that you plan on handling. For more information, see "Creating webhooks." Each webhook event on this page includes a description of the webhook properties for that event. If the event has mu
Git のコミットのタイムスタンプには author date と committer date の 2 種類があるという話 - ひだまりソケットは壊れない
普段から git rebase や git commit --amend をよく使っており、それらのコマンドはコミットのタイムスタンプを変更しないものだと思っていたのですが、実はコミットのタイムスタンプを変更していることに気付いて驚いたという話。 Git のコミットがもつ 2 種類のタイムスタンプ 特に何もオプションを付けずに git log すると、以下のように Author と Date が表示されます。 $ git log commit d447eeeb49d04e79b257e7abe6e633541d5e1c52 Author: nobuoka <...@...> Date: Thu Jan 31 20:45:47 2013 +0900 Prepare test tools (mocha and qunit)で、git rebase や git commit --amend で過
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
gitでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
gitリポジトリを特定のcommitバージョンまで戻す方法 - AorBorF
git-revertかgit-resetを使う 両者の違いは以下の通り git-revert ある特定リビジョン（過去にcommitしたバージョン）に戻すパッチを自動生成してコミットする git-reset ある特定リビジョン（ryに戻す（戻したリビジョン以降を無かったことにする） もし複数の人共同作業していて共有リポジトリを変更する場合はgit-resetを行うとまれにひどいことになるので極力git-revertを使った方がいいかも 作業の流れ git-logでどこまで戻すか決める（あとSHAをコピーする） % git log commit 46cdec49ae85012327b663531e569d77bf09b1b2 Author: amacou <amacou.abf@gmail.com> Date: Sat Jan 17 22:53:55 2009 +0900 test comm
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - airblade/vim-gitgutter: A Vim plugin which shows git diff markers in the sign column and stages/previews/undoes hunks and partial hunks.
How can I browse Git Logs without Tig?
GitHub - lolcommits/lolcommits: :camera: git-based selfies for software developers
hypergit.vim git vim plugin (HD)
http://blog.yuku-t.com/entry/20110427/1303868482