分散SCMを使いたい！と思う今日この頃。 仕事ではSVN（Subversion）を使っているのだが、ちょっとしたお試し編集をするためにブランチを作ることに抵抗がある。ブランチは欲しい、大きめな変更をコミット無しで行いたくない、やはり少しずつコミットして進めていきたい。しかし、変更が全て記録されてしまうのがいただけない。ログが残るのは良いことなのだが、本当に使うかどうか未知数な実験的プログラミングのログまで残したくない。使うと決まってから初めて残すようにしたいのだ。 すまん、これまで一緒に仕事をしてきた人々よ。俺はこれまで「ログが残って困ることがなんかある？いらなきゃ無視すればいいだけなんだから、気にするな。ブランチでもなんでもバンバン作ってしまえ！」とうそぶいてきているわけだが…ハッタリかましてました！本当は俺も抵抗があるのだ。 そこで、分散SCMだ。さらにいうと、SVKがいまひとつ気に入

GitHubにリポジトリを置いてる人はみんなプルリクエストを待っています。けどプルリクエスト用にフォークした自分のリポジトリを保守する方法が途中でわからなくなって...という人が案外多いんじゃないかなと思ったり。なので、ちょっとメモ置いときます。って、人のためみたいな言い方ですが、まあ自分用のメモです。 まずこうしたほうがいいという原則。masterブランチはフォーク元から変更せず、かならず自分用のブランチを作る。これは、masterを作業の同期用に置いておくためです。 自分のブランチでコミットしたあと、フォーク元のmasterが進んでないかのチェックは必ずすること。 もし進んでいたら自分のmasterに元作者のコミットを取り込んで自分のGitHubでのフォークが最新と同期してる状態にしましょう。で、元作者のコミットログを確認して何が起こったのかを理解しましょう。 $ git checko

会社で利用するソースコードのバージョン管理システムをgithubに移行しつつあります。 gitは以前から個人で利用していたのでブランチ管理のメリットや気の利いたマージなどはもう知っていたのですが githubで同時に複数人で開発をする、という状況は初めてだったので感じたことを残しておきます。 導入 まず当然なのですが開発スピードは上がってます。 これはgithubというよりgitの分散リポジトリの仕組みが大きいです。svnでsvk使うと効率が良いのと同じことです。 そこで問題になるのが各開発者のリポジトリ間をどうやってマージさせていくのか、って所なんですが masterからリリース用のブランチを切ってそこにpull requestを投げて他の開発者に確認してもらってからマージする、という流れで今は運用しています。 投げられた側が確認してマージをコミットするので責任は一蓮托生としてます。 人

新サービスが続々登場してアツい！ 「GitHub」とは 皆さんは「GitHub」を活用しているでしょうか？ 「GitHub」（ギットハブ）はソースコード管理用の分散型バージョン管理システム「Git」を使ったホスティングサービスです。 Gitの特徴は、作業用として自分のコンピュータ上にあるローカルリポジトリがあれば、ネットワークに接続できない状態だったとしても、ソースコードの更新や、履歴を調べたりできる点にあります。その特徴はGitHubにも生かされていて、オープンソースとして公開中の既存のコードを分岐（fork）して、新しいプロジェクトとして開発できます。 また、自分が手元のローカル環境でバグ修正したり、拡張したソースコードを本家のオープンソースプロジェクトに取り込んで（pull）もらうことも手軽にお願いできます。 さらに、READMEテキストファイル（README.md）などを独特のマー

こんにちは。 タイトルの通りなんですが、Capistrano みんなつかってるよねー。 ってことで独自のデプロイシステムをもってなくてさすがにFTPでUPはしてませんって人は結構使ってるもんだと思ってるんですけど、Capistrano ってなんかデフォルト各サーバで vcs の update 的なことをするか、ローカルにソースツリーを用意してやる場合に使えるのは scp で、なんかエコじゃないよねと言う話で、いちいちソースツリー全部配布されてたら転送量も時間もかかってしょうがないので、まーrsyncがいいんだよね、ということで、そんな時は capistrano_rsync_with_remote_cache (なげえよ) を使えばいいよね！ってお話です。 *1 luisparravicini/capistrano_rsync_with_remote_cache · GitHub このご時世

社長におねだりしたらベイスターズ買ってくれないかなぁ。どうもこんにちは nakamura です。 シーブレインでは今も昔もソース管理に Subversion を使い続けていますが、最近は協力会社さんとのやり取りなどで何かと Git にさわる機会が増えてきました。最初はチンプンカンプンでしたが、ようやく何となく基本的な部分が分かってきたので、Subversion ユーザ的な目線でちょこっと説明してみたいと思います。 コマンド例 初期設定 Git ではユーザ毎の設定内容も git コマンドで操作します。とりあえずいつも以下のような感じで設定してます。diff に使うコマンドとかも指定できるみたいですね。 # 名前 git config --global user.name "Tadashi Nakamura" # メールアドレス git config --global user.email n

「Git」使ってますか？ 近年、分散バージョン管理システム「Git」が急速にシェアを伸ばしています。筆者は、チケットシステムやバージョン管理の勉強会などを開催したりしていますが、Gitユーザーがかなり増えてきていると感じます。 しかしながら、そのような勉強会でアンケートを取ってみると、実案件では半分以上の人がSubversionを利用しており、Gitの導入はまだまだ進んでいません。移行コストが掛かったり、プロジェクトマネージャ層への知名度がまだまだ低いというのもありますが、理由の1つとして、ユーザー管理が煩雑であったり、アクセス制御に関する情報が不足しているということもあると思います。 そういうわけで本稿では、Gitリポジトリのユーザー管理やアクセス制御を簡単に行う「Gitolite」を紹介します。 なお、本稿ではGitの利用方法については紹介しませんので、Git自身の使い方については改め

Answer: We currently have 33 physical servers at Rackspace: * 2 database (mysql, redis) * 6 frontend (rails, resque) * 18 file server (9 pairs: masters serve git data, slaves run memcache) * 2 search * 3 xen (load balancer, ci, pages, service hooks, etc) * 2 staging

こんにちは、中川です。 Gitを使い始めてから、Subversionを使う機会がめっきり減ったこの頃です。 Gitだとローカルだけで簡単に使い始められるのもいいですが、気軽につくれるbranchや、mergeのしやすさがたまりませんね。 インストール直後の状態でも普通に利用できますが、 ちょっとした設定でさらに使いやすくなる方法をご紹介したいと思います。 ※今回ご紹介する内容はいずれも私のMacBook上での動作確認となり、Windows環境は考慮していませんがご容赦ください。 ■ユーザー名とE-mailアドレスの設定 まずは、最初にユーザ名と、メールアドレスを設定してしまいましょう。 $ git config --global user.name "yoshiki" $ git config --global user.email "yoshiki@example.com"

The document contains a series of dates from 2011-6-22 repeated many times. Between some of the dates are short phrases such as "Don't Repeat Yourself" and "Convention over Configuration". The overall document does not appear to have a clear purpose and consists primarily of a date repeated with occasional unrelated text fragments.Read less

CentOSのyumにはbash-completionがないので、ソースからインストールした。 Bash-Completion から、最新のソースをダウンロードしてインストール。 $ tar xjvf bash-completion-2.0.tar.bz2 $ cd bash-completion-2.0 $ ./configure $ make $ sudo make install ~/.bashrc # Use bash-completion, if available [[ $PS1 && -f /usr/local/share/bash-completion/bash_completion ]] && \ . /usr/local/share/bash-completion/bash_completion Gitのbash_completionは、Gitのソースの/contrib

こんにちは、インフラやってる sotarok です。最近、社内でも「sotarok は そーたろっくと読む」という誤解が広がっていましたので改めて自己紹介しますと、sotarok と書いて「そーたろー」または「そーたろー・けー」と読みます。ロックしてないのでよろしくお願いします。 今日は、Git の話です。 GREE ではずっと Subversion を使っているという話を、以前開発環境の話をしたときに少し触れたことがあります。Subversion での運用方法も、GREE では割と面白い運用をしているのでその話もどこかでしたいのですが、まあ、それは今回は置いておきましょう。どこかで聞いてください。 GREE もその昔 CVS から Subversion に移ったのですが、時代は流れるもので、いよいよ Git 化という流れがきています。Subversion と Git の違いを今更あえて挙