8. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Committer (コミットを適用した人) 例: 受け取ったパッチを取り込んだ人 ファイルのスナップショット (tree) コミットで変更されたファイルを含むツリー（説明は省略） 1つ前のコミットのリビジョン 例: 4717e3cf182610e9e82940ac45abb0d422a76d77 9. コミットに入ってる情報 リビジョン (SHA-1 ハッシュ) 例: 23cdd334e6e251336ca7dd34e0f6e3ea08b5d0db Author (コミットを作成した人) 例: オープンソースプロジェクトにパッチを送った人 Co
最近はテキスト編集をするときにはちょこちょこVimを使っている。 その際、Vimを使いながら少し前から設定ファイルをいじり始めたが、WindowsとMacとで別のファイルを利用して編集していたため、別マシンで設定した値を他の環境で反映できていなこともよくあった。 そのため今回、Githubを使ってWindowsとMacとで設定ファイル(vimrcとgvimrc)を同期させようと、以下のエントリを参考にチャレンジしてみた。 そろそろしっかりvimを使う。dotfilesのgithub管理とvundleの導入。 - 南極の図書館 そろそろしっかりvimを使う。github+vundleを利用したWindowsとの同期。 - 南極の図書館 このとき若干つまづいたことがあったので、備忘録も兼ねてメモ。 Vundleを導入した際の.gitmodulesファイル 上記エントリのように、今回Github
みなさん、Git使ってますか？僕はまだメインのVCSがSubversionなのもあって、なかなか慣れません。せっかくGitを使っているのに、ちょっと不便なSubversionくらいの位置づけです。でも、同じような理解度の人って多いんじゃないでしょうか。 一方で、最近はGitHub管理のオープンソースプロジェクトが増えてきました。バグレポートを送るにしてもpull request*1が前提のような空気があり、Git初心者には少し敷居が高い印象があります。 そんな僕も先日初pull requestをしてみたんですが、色々な失敗の積み重ねで残念なpull requestになってしまいました。その反省を元に、本稿ではpull requestする際のベストプラクティスを紹介します。これは「Git Workflow」をベースにコマンド例などを加筆したものです。 概要 pull requestする際は、
しっかりvim、2回目。 前回はMacでdotfiles(.vimrcなど)をgithubの管理にし、vimのpluginをvundleで管理するようにした。 そろそろしっかりvimを使う。dotfilesのgithub管理とvundleの導入。 - holyppの日記 今回はWindowsで、前回作った設定ファイルをgithubから持ってくる。 それにより、WindowsでもMacと同じ設定で使えるようになる。 Windowsからgit pushもできるので、同期すると言ったほうが良いかも知れない。 gitが入っていない状態から始めても、慣れれば30分以内に作業が終わるので、興味のある方は是非やってみて欲しい。 github+vundleで、複数PCでの管理が驚くほど楽になる。 目次 ・gitとcurlの導入 ・git cloneとsubmodule update ・リンクの作成 ・Bu
vimを使い始めて暫く経つのだが、なかなか初心者レベルを抜けられない。 そろそろしっかりvimを使ってみようと思う。 聞いたところ、dotfiles(.vimrcなど)はgithubで管理すると便利らしい。 また、vimのpluginはvundleで管理するのがナウいらしい。 今回はこの二つを実際に行ってみる。 なお、dotfilesはWindowsとMacで共有する。 目次 ・vundleとは ・目的と方針 ・dotfilesの管理とvundleの導入 ・vundleを利用したプラグインのインストール vundleとは そもそも、vundleとは何か。 簡単に言うと、vimのpluginを管理するpluginである。 RubyのBundlerに影響を受けたらしい。（個人的にこれがポイント高かった。） 特徴は、pluginを.vimrcで管理すること。 .vimrcに必要な情報を書いておけ
自分でgitのサブコマンド作るとなるとalias作るかgit-hogeみたいなスクリプト作るかだけど .gitconfigとか~/bin/とかにスクリプトが散らばってちょっとめんどくさい*1。 まぁ自分の場合GitHubにほとんど公開してるのであんまり面倒を感じたことないけど。 あとスクリプト作るとなるとWindowsのコマンドプロンプトとかnyaosで動かないのが不便。 msysgitのbashとか使えばいいんだろうけどなんかやだ。普通にバイト先で使ってるけど*2。 *1:ちなみに自分は~/bin/の代わりに前のエントリみたくgittoolsってリポジトリにいれてるので~/bin.d/ってディレクトリにシンボリックリンク貼って自動でPATHに追加するようにしてる *2:gitとvimあれば開発するのに十分だし...
gitとgithub 職場ではsvnで特に困っていないし、gitは難しいと聞いていたため、gitとgithubはずっと敬遠していた。 しかし、そろそろgithubを避けてもいられなくなってきたので（今更）gitの導入とgithubの登録を行った。 githubについては、オフィシャルの説明とチュートリアル（help.github）がとても丁寧なので、想像以上に簡単だった。 ただ、gitそのものは聞いていた通り理解に時間がかかりそう。 サインアップから設定まで https://github.com/ 最上段の「日本語にしますか？」でYesをクリック。右上の「料金・登録」→画面が変わって「無料アカウントの作成」。 ユーザ名、メールアドレス、パスワードのみで登録ができる。 その後は「Set up git」の通りで特に詰まることは無かった。 ・gitのダウンロード（※1） ・sshの設定 ・nam
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
id:repeatedly から無言の圧力を受けたので書きました。 タイトルは釣り。そもそも自分が Git マスターしてないし。突っ込み歓迎。超歓迎。 一応、このエントリだけで一つの Git リポジトリをそれなりに操れるようになることを目指してます。なので、コマンド一つ一つに対する説明じゃなくて、やりたいこと一つ一つに対する説明が中心です。え？それ最速マスターじゃない？きーこーえーなーいー。 あと、他のバージョン管理システム、例えば Subversion や Mercurial が使えることを前提としています。誰か「バージョン管理システム基礎最速マスター」とか書かないの？ インストール Windows と Debian しか分かりませんので、自分のシステムに読み替えて行ってください。あと誰か Mac ください。 インストールも設定も終ってるよ！って方はリポジトリの作成までひとっ飛び。 Wi
はじめに こんにちは川崎です。最近はじめてgitを使う機会がありましたので復習してみます。 このエントリーは私がgitを使い始めたばかりのログを元にして、まとめた内容にしています。 gitをインストール、コマンドを使う準備 gitを使うにはgitのインストールが必要です。使っている環境に合わせてgitをインストールします。 私の環境はmacなのでportsでインストールしました。 $ sudo port -d selfupdate $ sudo port install git-core +gitweb +svn インストールが完了したかどうかはgit --versionコマンドで確認できます。 $ git --version git version 1.7.3 gitのversionが表示されたのでインストールされているようです。準備完了です。 はじめてgitを使うときは gitを使うた
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
最近ホントにRubyの人々の間でgit流行ってますよね。私はdarcsっこなのですが、これだけ周囲で流行られるとさすがに危機感を感じます。しかも最近はgithubやらgitouriousやらのやたらと便利なサイトが出現し、ましてRubyForgeまでもがgitを採用とのことですから、これはもうなんとかしておきたいところです。というわけで、今更ながらgitを覚える口実として、とっても便利なgithubを使ってみることにしました。 http://github.com/ そこでせっかくですからgithubの使い方をメモしておこうと思います。これを読んで皆さんも一緒にgithubで遊びませんか？ そもそもgithubとは何モノ？ github はgitレポジトリを公開してくれるサイトです。出来ることは大体のところ次のような事です。 作者はレポジトリを作成して公開できます 他の人はレポジトリをフォー
途中から難しくなってきてとばし読み気味になったが実用Gitはすばらしい本だ。 入門Gitもすばらしかったがそれにも劣らない（この２冊ほどでは無いかもしれないが入門gitもいい本だ）。 読んでいて感じたのはGitは歴史を書き換えてでもいいコミットを作ることに関心を持っているように思う。 間違えたコミットコメントを修正したいと思うことは誰でもありそうだが、それだけではなくコミットをまとめたり、順番を変えたりすることもGitではできる。さながら歴史をリアルタイムで作り替えているようだ。 そうやって作られたある意味では完璧なコミット履歴を見てみたい気もする。 コミットについて語る場合２つのパースペクティブがある。１つは粒度でもう１つはコメントだ。 コミットの粒度は論理的にまとまった単位であるべきだ。例えば１つのバグ修正で３ファイルいじったなら１コミットであるべきでファイル毎に３回コミットされたら後
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く