git-notesでコミットにメモをつける - アジャイルSEの憂鬱
2020年に「コミットログは良くならない」というのを悟ったので、現実的な解決案である「git-notesでメモを残す」について記事を書いておきます。 前回の記事 sinsoku.hatenablog.com git-notes 詳細は git notes --help を読んでください。 概要は以下の通りです。 コミットログとは別にメモを残せる コミットはそのままなのでshaは変わらない shaが変わらないのでCIの再実行が起きない 他人のコミットにメモをつけられる 他人に作業を依頼する必要がない メモもリモートにプッシュできる 過去のコミットにメモを残せる 使い方 メモを書く git notes edit <sha> でメモを書くと、git log のときに一緒に表示される。 $ git notes edit d2cdf0b $ git log -1 d2cdf0b commit d2c
作業ログと履歴をシンプルに共有できる furoshiki ってツールを書いた - 詩と創作・思索のひろば
おはようございます。この記事ははてなエンジニアアドベントカレンダー2017の25日目の記事です。昨日は id:alpicola さんによる 社内で機械学習ハッカソンを開催しました でした。 サービスのデプロイをはじめとして、チーム内の開発者が共通して担当すべき業務というのはさまざまに存在し、基本的に定型化されているものですが、開発者が手元で実行するなど自動化までは行えていないような場合、以下のような点が問題になります。 作業履歴が共有されない 同様に作業中に意図しない不具合が生じた場合、エラーログが実行した環境にしか残らない それぞれ、デプロイのタイミングを Mackerel や Slack に投稿して共有する、Gist にエラー時のログを貼るなど、チームに合わせた方法が存在していることと思います。また作業環境を同一にするため、チームにデプロイサーバを用意して作業はそこで行う、という方法も
コミットメッセージの書き方
コミットメッセージにはどのような情報を残すべきだろうか？はじめにこの記事ではGitのコミットメッセージの重要性と良いコミットメッセージの書き方を説明します。いままで良いコミットメッセージについて考えてこなかったかたも一度立ち止まって考えてみてくれると嬉しいです。 対象読者GitやGitHubを業務で使っている人「良いコミットメッセージ」をあまり意識しない人目次Gitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？コミットメッセージの書き方の1例を紹介まとめGitを使ったソフトウェア開発で、なぜコミットメッセージが重要なのか？ソフトウェア開発において、良いコードとはどんなコードでしょうか？ 私は「 他人が読みやすく、理解しやすいコード」だと考えています。ソフトウェアにバグは必ず出ます。そのバグを修正する時間を最短にできるような、読みやすい、理解しやすいコードが良いコードだと思
tigでコミットログ見てるときに「このコミットが含まれたプルリクに飛びたい」と思うときがあるので見れるようにした - パルカワ2
@hisaichi5518 .tigrc とかで設定して、閲覧している commit をキーボードショートカットで開けるようにしておけば、commit のページに Pull Request へのリンクが含まれていそう— ホームページビルダー (@r7kamura) 2017年2月7日 ツイッターでボソっと言ったら、良い感じのアドバイスをもらったので、雑に会社のGHEだけ対応するかと思って対応した。 hub インストールして .tigrc に以下を追加して、コミットログ見てるときに shift+pを押せば、コミットページに飛ぶので、そこからプルリクへ遷移出来る。 bind generic P @sh -c 'hub browse -- commit/%(commit)'直接プルリクに遷移したいと思って頑張ろうとしたけど、複数プルリクがあるとかめんどくてこれが一番かなと思った。 追記: git
【翻訳】Gitのコミットメッセージに関する注意点
Tim Popeさんの "A Note About Git Commit Messages" を翻訳しました。 元記事はこちら： http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html （翻訳の公開は本人より許諾済みです） 翻訳の間違い等があればブログコメントやTwitter(@oshow)などで遠慮無くご指摘ください。 Gitのコミットメッセージ に関する注意点 良い形式のコミットメッセージを書くということについて、時間を取って説こうと思う。私が考えるに、コミットメッセージ形式に関するベストプラクティスは、Git を素晴らしくしてくれる小さなディティールの一つだ。rails.git への最初のコミットのいくつかは、（折り返しのない）長文による多様なコミットメッセージを含んでおり、なぜこれがはっきり言ってお粗
われわれは、いかにして変更点を追うか
われわれは、いかにして変更点を追うか ChangeLog/Issueを追う技術 自己紹介 azu @azu_re Web scratch, JSer.info アジェンダ 変更点を ChangeLogで知る Issue/Pull Requestで知る Commitで知る アジェンダ 変更点を Commitに書く Issue/Pull Requestを扱う ChangeLogにまとめる 変更点を追う :mouse: ChangeLogの追い方 ChangeLogを追うにはまずChangeLogの更新に気づく事が必要 GitHubでライブラリのリリースを見ていくためのツールや方法に書いた 更新検知の仕組みや補助ツールについて リポジトリのWatch => azu/github-reader タイムライン => azu/github-reader Star => starseeker GitHu
Gitのコミットメッセージの書き方 - Qiita
Gitのコミットメッセージの書き方 自分なりにまとめてみました。Git歴浅いので、意見募集中です。 （2014年12月17日追記） 想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。 （2022年1月4日追記） 最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則 以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目 ：空行 3行目以降：変更した理由（内容、詳細） 日本語でも英語でもOKですが、リポジトリで統一してください。 1行目 コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約 コミット種別 以下の中から適切な種別を選びます。 （多すぎても悩むので
GitのCommit中のAuthor名およびCommitter名を変える - idesaku blog
ローカルで持っているGitリポジトリをGitHubにpushしてしまいたいなぁ、と思ったのだが、pushする直前にAuthorおよびCommitterとして自分の本名を使っていることに気づいた。そういえば、Gitを使い始めたころはuser.nameに正直に本名を入れていたなぁ…。 そのままでも大した問題はないのだが、ネット上ではidesakuで通すことにしているので、こいつらを修正した。その際、あまり使わないコマンドを使ったので、作業ログなど残してみる。 さて、どうすればよいか。すぐに思いついたのは、git-rebaseを使うことである。 ところで、Gitは全てのコミットにAuthorとCommitterの二つの名前を記録している。これは、オープンソース分野でよくある「パッチを書いた人(Author)と、それをリポジトリにコミットした人(Committer)が違う」ケースに対応するための措
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
gitのコミットの記法 - Fixstars Tech Blog /proc/cpuinfo
How to Write a Git Commit Message