Sorry. This site has been closed. Please use the Search for commit messages on GitHub instead. The original source code is available at minamijoyo/commit-m.
皆さんお元気ですか?LINEサーバー開発室でサーバ開発を担当している崔珉秀と申します。 この記事ではLINEのサーバーの開発とリリースプロセスについて述べたいと思います。 LINEの開発者はどんな形で開発しているのか、サービスに変更事項をどのように適用しているのか、お互い協力してより良い開発環境を得るためにどんな努力をしているのかをお伝えする機会になったらいいなと思います。 ここで述べるリリースプロセスは、LINEのサーバ開発の流れとソース管理システムの運用方法、そして本番環境に変更事項を適用するまでの過程です。 LINEのServer Applicationはその役割とシステムの構成によって複数のServer Applicationに分かれて構成されています。 例えばNetwork通信及びProtocolなどを担当するApplication、messagingやsocial graph
皆さん、tigコマンドを活用していますか? tigは、コンソール上で使えるgitブラウザです。実はずっと、ただのきれいなgit logだと思っていたのですが、本当はそんなことはありません。かなり使えるやつなのです。 インストール ソースコード: https://github.com/jonas/tig インストール方法: https://github.com/jonas/tig/blob/master/INSTALL.adoc この辺りを参考にしてみてください。詳細は割愛します。 基本の使い方 この状態の差分を扱っていきます。いつものこれだとこんな感じ。 git logが素敵にビジュアライズされてます。この画面をmain viewといいます。 ここでエンターを押すと、下半分に差分の詳細(diff view)が表示されます。 下矢印で、Unstaged changesの差分を見てみるとこんな
ちょいネタです。ちょうどGitで特定コミットのファイルだけをzipで納品する必要があったので。 git:特定コミットのファイル一式を抽出&zip保存。ワンクリックで。 | ラスタッタPぃやぁ をとても参考にさせていただきましたが、ちょっと変更したのでメモ代わりに書いておきます。 こんなコミットログがあったとして、 $ git log --oneline --graph * c000004 コミット4 * c000003 コミット3 * c000002 コミット2 * c000001 コミット1 「コミット2からコミット3まで変更ファイルだけをください」と言われたら、以下のようにすればOKです。 $ git archive --format=zip c000003 `git diff c000003..c000001 --name-only` -o ~/Desktop/c000003.zip
差分ファイルで納品、あるある。 WEBの場合、差分でもらうと楽なのもわかるし。 けどgitからやるときにSHA-1コピーして、貼付けて、またコピーして、また貼付けて・・・ っていうのは正直飽きた。ワンクリで行きたい。 見つけた中で近いのはこれ。 git archive --format=zip HEAD `git diff master --name-only` -o archive.zip diffで最新コミットの変更分(?)をzipに落とすっぽい。 ↓ これでSHA1に置き換えてやってみるも、どうもうまくいかない。 git archive --format=zip HEAD `git diff $SHA --name-only` -o archive.zip ↓ そりゃdiffだからだろうってことでshowを試す。 git archive --format=zip HEAD
gitでは様々な方法でコミットログを書き換えることができます。 その一例として誤ったブランチに対して行った変更を正しいブランチへ移す方法を紹介します。 問題 これまで「新機能Xを追加する」という設定で以下のトピックについて解説していました: gitでコミットの順序を入れ替えるgitで複数のコミットを1つにまとめるgitで1つのコミットを複数のコミットに分割する これにはまず としてこの作業用のトピックブランチを作成してそちらで作業を行うのが普通です。 しかし git branch を実行したところで安心してしまい、 git checkout を忘れて全く違うブランチで作業を行ってしまう というミスは時々やってしまいます (git checkout -b という方法もありますがここではそれも忘れていたとしましょう)。 例えば以下のような状況だったとしましょう: $ git branch ma
An interactive Git visualization tool to educate and challenge!
例えば、以下のようなコミット履歴があるとします。 A---B---C---D masterここで git rebase -i HEAD~3 をして、 コミットB を E に書き換えたくなったとします。このとき、rebase -i によって履歴を書き換えてしまうと、以下のようにリポジトリからB〜Dのコミットは消滅してしまうと思っている人も居るのではないでしょうか。 A---E---C'---D' master確かに、Gitがこのような動作をするのであれば、rebase後に元の状態へ戻すことは到底困難であるように見えます。しかし、正確に書けば、実際のレポジトリの状態は以下のようになります。 E---C'---D' master / A---B---C---D実はコミットA〜Dの一連のコミットは手つかずで残っており、「master」というラベル*1が新たな枝に付け替えられただけなのです。よって、
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら: http://nvie.com/posts/a-successful-git-branching-model/ (翻訳の公開と画像の利用は本人より許諾済みです) このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト(仕事でもプライベートでも)で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー(説明は省略) 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
こんにちは、中川です。 Gitを使い始めてから、Subversionを使う機会がめっきり減ったこの頃です。 Gitだとローカルだけで簡単に使い始められるのもいいですが、気軽につくれるbranchや、mergeのしやすさがたまりませんね。 インストール直後の状態でも普通に利用できますが、 ちょっとした設定でさらに使いやすくなる方法をご紹介したいと思います。 ※今回ご紹介する内容はいずれも私のMacBook上での動作確認となり、Windows環境は考慮していませんがご容赦ください。 ■ユーザー名とE-mailアドレスの設定 まずは、最初にユーザ名と、メールアドレスを設定してしまいましょう。 $ git config --global user.name "yoshiki" $ git config --global user.email "yoshiki@example.com"
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く