gitにおけるコミットログ/メッセージ例文集100
私はコミットログの書き方に悩む英語の苦手な人間である。実際、似たような人は世の中に結構いるようで、頻出単語を集計したりまとめたものは既にあって役に立つのだけれど、これらはあくまで単語の話であり、具体的な文を構成する過程でやっぱり困る部分がかなりあった。 要するに、どういう時にどういう文が使われているのか、ということを示した例文集が欲しいのである。ググると他にも「例文集があればいいのに」みたいな声はあるくせして、しかし誰も作ろうとしない。何なんだお前ら。それじゃ私が楽できないじゃないか。 仕方なく自分でまとめたので、増田に垂れ流しておく。 はじめにここで挙げているコミットログは全て実際のコミットログからの転載である。当然ながら各コミットログの著作権はそれぞれの書き手にある。いずれも各英文でググれば出てくるし、フェアユースの範囲なら許してくれるだろうと考え名前とプロジェクト名は割愛したが、ここ
「Gitポケットリファレンス」を活用してカーネルソースを読んでみよう！ - めもめも
Gitポケットリファレンス 作者: 岡本隆史,武田健太郎,相良幸範出版社/メーカー: 技術評論社発売日: 2012/07/10メディア: 単行本（ソフトカバー）購入: 7人 クリック: 103回この商品を含むブログ (26件) を見る こちらの書籍を著者様より献本いただきました。ありがとうございます！ 本書は、GitHubなどの既存の共有リポジトリの使用を前提として、これから開発に参加しようという読者を想定しているため、「どういうシーンでどのgitコマンドを使えばいいのか」が明確で、わかりやすい構成になっています。実用面にフォーカスしたGitの解説書としては、今のところベストな1冊ではないでしょうか。 ところで・・・・ ちなみに私の場合は、ソースコードを書く時間よりは、読む時間の方がずっと長いのですが、実は「ソースを読むツール」としてもGitは有用です。 Gitリポジトリにはソースコードの
Gitの10年間: Gitの生みの親 Linus Torvalds のインタビュー
10 年前の今週、Linux カーネル コミュニティは困難な問題に直面しました。すなわち、バージョン管理システム BitKeeper を使うことができなくなり、他のソフトウェア構成管理 (SCM) システムも分散システムのニーズを満たすことができませんでした。Linux の生みの親 Linus Torvalds は自らこの困難に立ち向かい、週末をはさむ 10 日間くらいの間雲隠れし、翌週には Git を持って登場しました。今日、Git は何千というプロジェクトで利用されており、プログラマーの間に新しいレベルのソーシャル コーディング形態をもたらしました。 この記念すべきマイルストーンを祝うために私たちは Linus に Git の舞台裏やこのプロジェクトに対する彼の考え、またこのプロジェクトがソフトウェア開発に与えた影響について話してもらいました。本記事は彼のコメントです。この質疑応答に続
git-annex
git-annex allows managing large files with git, without storing the file contents in git. It can sync, backup, and archive your data, offline and online. Checksums and encryption keep your data safe and secure. Bring the power and distributed nature of git to bear on your large files with git-annex. git-annex is designed for git users who love the command line. For everyone else, the git-annex ass
GitHub、Gitで画像や動画など大容量ファイルを扱える「Git LFS」（Git Large File Storage）正式リリース
GitHub、Gitで画像や動画など大容量ファイルを扱える「Git LFS」（Git Large File Storage）正式リリース GitHubは10月1日（日本時間10月2日早朝）、サンフランシスコで同社初の大型プライベートイベント「GitHub Universe」を開催しています。 その基調講演にて同社CEOのChris Wanstrath氏は、画像や動画、音声といった大容量のファイルをGitワークフローで扱えるGitエクステンション「Git LFS」（Git Large File Storage）の正式提供を発表しました。 Gitはそもそもテキストファイルのコードを扱うことを前提にして差分や圧縮などの操作を行うように作られているため、デザイナやクリエイタなどが扱う画像や動画のような大容量ファイルの扱いは苦手でした。 Git LFSはGitの中に大容量ファイルへのテキストポインタ
Git - Gitオブジェクト
1. 使い始める 1.1 バージョン管理に関して 1.2 Git略史 1.3 Gitの基本 1.4 コマンドライン 1.5 Gitのインストール 1.6 最初のGitの構成 1.7 ヘルプを見る 1.8 まとめ 2. Git の基本 2.1 Git リポジトリの取得 2.2 変更内容のリポジトリへの記録 2.3 コミット履歴の閲覧 2.4 作業のやり直し 2.5 リモートでの作業 2.6 タグ 2.7 Git エイリアス 2.8 まとめ 3. Git のブランチ機能 3.1 ブランチとは 3.2 ブランチとマージの基本 3.3 ブランチの管理 3.4 ブランチでの作業の流れ 3.5 リモートブランチ 3.6 リベース 3.7 まとめ 4. Gitサーバー 4.1 プロトコル 4.2 サーバー用の Git の取得 4.3 SSH 公開鍵の作成 4.4 サーバーのセットアップ 4.5 Git
ネイティブと働いて分かった英語コミットメッセージの頻出動詞10つ
ウッ ここで詰まる事は往々にしてあります. 特に急いでる時の煩わしさは甚だしいです. どうせならそれっぽい英語を使いたいのでOSSや同僚のコミットメージの語彙の出現確率を調べてみましたら、 もちろんfeatureによってコミットメッセージの付け方など数多あるものの、一定の頻出パターンは見い出せたので筆を取りました. （英語勉強しないと..） 方法 github.com/rails/railsのコミットメッセージ内における各動詞の出現確率を求め、 またOSSと仕事でのコミットメッセージの趣向も変わってくる事も勘案するため、 （仕事でDeprecateとか滅多に使わんし） 同僚に聞きつつ10つあげてみた. 以下列挙 （例は実際の同僚やOSS上でのコミットメッセージです.） Add *A to *B AをBに加える
gitのコミットの歴史を改変する(git rebase) 1 / 2 · けんごのお屋敷
git には rebase というとても便利なコマンドがあります。その中でも特に便利なのが -i または --interactive オプションです。便利なのですがよく忘れるのでまとめもかねてこの記事で詳しく紹介します。 前提 この記事では説明のために以下のようなコミット状態である前提で話を始めます。よくあるコミットの流れです。 git rebase -i -i は --interactive とあるように、対話的に rebase が実行できるコマンドです。これでなにが出来るかというと コミットメッセージを編集する コミットをまとめる コミットを分割する コミットの順番を移動させる コミットを削除する など、いろんなことが出来ます。基本的な構文は [kengo@tkengo-mac] $ git rebase -i <commit> これだけ。 <commit> には特定のコミットを指定し
Gitのつくりかた | メルカリエンジニアリング
はじめまして。サーバサイドエンジニアの @DQNEO です。 今日はGitのつくりかたをご紹介します。 C言語学習教材としてのGit Gitと同じものをゼロから作って何の意味があるのか？と思いますよね。 私がこの再発明をやり始めた動機は「C言語を書けるようになりたい」でした。 実際に途中までやってみたところ、 C言語がチョットデキるようになった Gitの内部構造に詳しくなった というメリットが得られました。 C言語を勉強する題材は、テトリスとかWebサーバとか他にいくらでもあるのですが、Gitを実装してみるのはかなりおすすめです。理由は下記の通りです。 内部構造が意外と単純 (ローカルで動かす分には)ネットワークの知識が不要 普段使っているツールで外部仕様がわかっているので、やるべきことが明確 余談ですが、本家Gitのソースコードを参考にしようと思って読んでいたら、Linus Tovals
Gitコミットメッセージの7大原則 - rochefort's blog
タイトルは大げさです。割と当たり前の話です。 ハードディスクの整理中にRailscastsのメモが出てきまして 懐かしいなぁ、 Ryan Bates(@rbates)さん 元気かなぁと Twitterを覗いてみたところ How to write a Git commit message: http://t.co/D31dVh1lks— Ryan Bates (@rbates) 2015, 7月 28 なかなか興味深い記事をtweetされていました。 Git の commit messageに 規律をもたらそうぜ、ってのは どうやら日本人だけじゃないようです。 元記事( How to Write a Git Commit Message ) Introduction 著者の過去と現在のcommit logを対比しています。 一貫して、この緑と赤の対比が見やすいので、記事も読みやすいです。 ま
Gitのオブジェクトモデル(The Git Object Model翻訳)
Git Community Book から、1章2節の The Git Object Model を翻訳。ライセンスは、 GPLv2 。 多くのGit解説本と違い、まずGitの内部モデル解説から入るという、おもしろい構成の本です。人によっては、このほうがわかり易いかもしれません。Gitは差分データを管理していると誤解されることがたまにありますが、それは誤りであるということがこれを読めばわかります。 SHA プロジェクトの履歴を表すのに必要な情報は、いずれも、40桁の「オブジェクト名」で参照されるファイルに格納されている。オブジェクト名は、このような形をしている: 6ff87c4664981e4397625791c8ea3bbb5f2279a3 このような40文字の文字列は、Gitのあらゆる場面で見られる。どの場面で出てくるものであれ、その名前は、オブジェクトの内容のSHA1ハッシュを取るこ
git pull と git pull --rebase の違いって？図を交えて説明します！ | KRAY Inc
はじめに こんにちは、クレイの亀井です。ここ最近一気に気温が上がりましたね。顔に重点的に汗をかくタイプの私には憂鬱な季節がやってまいりました さて、今月正式リリースしました(！) DocBase プロジェクトではクレイ外部のデザイナーの方と一緒に開発しています。SourceTree で Git を使っている方で、軽いデザイン修正などは弊社の Rails プロジェクトに直接手を加えてプルリクエストを送ってくれます。 こちらのデザイナーさんに「プルリクエストを送る際は、作業ブランチで git pull --rebase origin master してから送ってもらえますか？」とお願いすると「pull はわかるんですけど、この --rebase ってなんですか？これつけると何が変わるんですか？」と質問がきたのです。 作業ブランチで git pull --rebase origin master
【翻訳】Gitをボトムアップから理解する
John Wiegleyさんの "Git from the bottom up" を翻訳しました。 元PDFはこちらからダウンロードできます： http://newartisans.com/2008/04/git-from-the-bottom-up/ 元記事のライセンスがクリエイティブコモンズのBY-SAであったため、この翻訳もBY-SAとなります。 ライセンスを守って自由にご利用ください。（詳しくは記事内の最初にも書いてあります） 翻訳ミスの指摘や改善の提案等があればブログコメントやTwitter(@oshow)などで遠慮なくどうぞ。 Git をボトムアップから理解する Wed, 2 Dec 2009 by John Wiegley 私が Git を理解しようと調査した時、高級なコマンドの視点から眺めるよりボトムアップ式に理解することが役立った。そしてボトムアップ視点で見る Git が
gitでマージの事前に衝突するかどうか確認する
gitを使っていて、特定のブランチとマージしたら衝突が起きないかどうか知りたい場合があります。例えば、プロジェクトチームで共有しているリポジトリにコミットをプッシュする前に、現在作業中のブランチがmasterブランチと衝突を起こさないか確認しておきたい、なんて場合です。 そんな時は、mergeコマンドの —no-commit オプションで master をマージしてコミットせずに止めてみればいいです。あとで簡単に元に戻せます。（本来確かめたい向きとは逆向きのマージですが、衝突の確認をするだけなら結果は同じですから問題ありません。） [user@host]% git merge master --no-commit Auto-merging /some/file/path Automatic merge went well; stopped before committing as requ
.gitconfigに設定してるaliasなどのまとめ - ( ꒪⌓꒪) ゆるよろ日記
22:56 @thinca さんからの指摘を追記 @yuroyoro あとお節介ですが、n個前とdiffなら HEAD^ より HEAD~ の方がいいと思いますよ。両者では若干意味が違います。~なら HEAD~3 と数字が書けるのも利点です。あと個人的にはwhatchangedよりlog --statの方が見やすくて好きです。 2010-10-08 22:30:52 via Tween to @yuroyoro @yuroyoro URL このgitconfigの記事に関して質問なのですが、core.excludesfile は $HOME で動きますか?以前試した時ダメで、~/ なら動いたのでこちらを使ってるんですが。 2010-10-08 22:20:49 via Tween to @yuroyoro 「そんな.gitconfigで大丈夫か?」 そんなわけで、仕事でもモリンモリンにgi
「すごいGit楽しく学ぼう」を公開しました - mixi engineer blog
こんにちは、toma です。 つい先日、新卒エンジニア向けに Git 研修を行いました。 その時の研修資料「すごいGit楽しく学ぼう」を Speaker Deck にて公開しました！ 「すごいGit楽しく学ぼう」は、Git に触ったことがないという方でも、Git を使ったチーム開発に参加できることを目指して作成しています。 実際にミクシィでは、ほとんどの部署で GitHub や GHE を利用しており、Pull-Request を活用してチーム開発を進めています。 Git の習得は、ミクシィで開発を行っていく上で必須のスキルであるため、新卒研修として毎年実施されています。 資料の目次 とりあえず使ってみよう！ コミットとブランチについて正しく理解しよう 歴史を取り込む 落穂拾い Git のコマンドをひと通り使ってみた後、Gitの仕組みについてひとつずつ学んでいくという構成になっています！
俺のオレオレgit-flow | おそらくはそれさえも平凡な日々
背景 一昨年末くらいにgit-flowを採用していた 良いんだけど、結構めんどくさいなーと思うところがあった 去年頭の新規開発からはgithub-flowを採用(と言うかごく普通のGit運用) masterのテスト通ったらjenkinsさんが開発サーバー反映してくれて捗る ただ本番をそれで運用するわけにもいかない リリースタイミングとかある masterはデザイナーやME(=gitに不慣れな人たち)がカジュアルに画像やテンプレをpushできる(それで構わない) git-flowとgithub-flowの中間くらいのフローで運用することに git-flowの気に入ってる点とそうじゃない点 気に入っている点 並列ブランチを走らせるというのは良い(git-flowの場合、masterとdevelop) hotfixが便利 めんどくさい所 releaseブランチ毎回作る必要性をあまり感じない バー
GitHubクローンのGitLabを５分でインストールした - アルパカDiary Pro
※2015/6/22 最新版の手順に更新 ※2015/1/7 アップグレードについての記事を書きました http://d.hatena.ne.jp/toritori0318/20150106/1420558625 ※2014/5/24 補足記事書きました http://d.hatena.ne.jp/toritori0318/20140524/1400955383 で､お決まりのパターンでOSSに流れて､ GitLabとかやってみたんだけど､むっちゃムズいのねあれ｡ まともにインストールできん｡ http://d.hatena.ne.jp/rela1470/20140520 「GitLab インストール」 でググるとたいていまともにインストールしようとしている記事が見つかって なにこれ使うまで面倒すぎ！ ってなりますよね。かつての自分もそうでした。 しかし最近のGitLabはRPMが提供され
2014年、春のGit事情 - fujimuradaisuke's blog
なんとなく最近どんな感じでGitを使っているか、適当にリストアップしてみた。 よく使うやつ git status git status --branch --short にしている。変更されたファイルが出る。とりあえず何をしたかざっくり把握する用。sにエイリアスしている。一日100回くらい実行しているのではないか。 git diff 特にオプションは指定していない。何をしたかしっかり把握する用。dにエイリアスしている。一日50回くらい実行しているのではないか。 git grep バージョン管理しているファイルから渡した単語を含む行を検索、表示。関数の検索などあらゆる場面で超便利。オプションは --line-number --show-function --color --heading --break がオススメ。 git ls-files バージョン管理しているファイルのファイルパスを表
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
