gisty を知ったのはもう記憶にもないくらい昔だし、直接勧められたのは Twitter / ゆーけー/赤松 祐希: @wtnabe gistにプロダクトコードとテストコ … なんと3月なので9ヶ月前という体たらくでございますが、ようやく使ってみました < gisty swdyh/gisty - GitHub 必要な準備gisty gemGISTY_DIRgit の config使っている Ruby が参照できる OpenSSL 証明書gisty を使うには clone する場所を環境変数で指定しておく。post するだけでも同時に clone するので GISTY_DIR の指定は必須である。 また、git の config は最終的にこんな形になればよい。

俺は普段こういう運用でやっているが、君はどうか。 社内の trac にドキュメントをかいたので、コピペしておく。git についてはカジュアルにつかってるだけなので、もっとこうしたほうがいいんじゃねえのというのがあればおしえてください。 ブランチ命名規則master 本番の deploy 用。誰かに deploy されてこまるものはいれない。stg ステージングの deploy 用iss(\d+) チケット$1 用の topic branch。master から分岐させるその他、キャンペーン関係など、おいやすくしたい者は別途名前つけてもよし。 stg の運用基本的に、開発はチケットにひもづく topic branch でおこなうので、以下のような作業フローとなる git co master git co -b issXXX # トピックブランチをきる ... # development gi

今の仕事についてつらつらと書く。今漠然と思ってることを書き出しただけなので、そんなに意味のある内容でもないかも。 アジャイル そもそも何をもってアジャイルと言うのか、中々難しいところではある。昨日から読んでる「間違いだらけのソフトウェア・アーキテクチャ」では僕はアジャイル(開発)というのは、できればアジャイル宣言を守るか、守る努力をしているものだけに、その名前を冠してほしいと思っているけど・・・。とある。そういう意味だと改めてうちのチームでもアジャイル宣言を確認するべきかもしれない。 何はともあれ、今うちのチームではCTOのちゃんとアジャイルな開発をしていきたいという想いからいくつかのプラクティスを実践している。イテレーション、プランニングポーカー、バーンダウンチャートなど。まだまだチームとして未熟な為、見積りの精度ややり方が少しうまくいっていない気はするけどこの辺りは徐々に改善されそう。

2012/12/13 追記 zsh 4.3.11 以降の新しい機能を使って改良しました。 -> 「zsh の vcs_info に独自の処理を追加して stash 数とか push していない件数とか何でも表示する - Qiita」 Git を使ってファイルを編集した場合、それをいったんインデックスに追加(add)してその後コミットってのが基本的な流れになる。なんかいろいろやってると、ちゃんと add したのかどうかわかんなくなることがある。 そういうときは status コマンド使えばいいんだけど、以前エントリ書いた zsh の vcs_info の機能を使うといい感じにプロンプトに表示できるようになるので紹介する。 zshrc の書き方 こんな風に zshrc に書いておけば OK。 autoload -Uz add-zsh-hook autoload -Uz colors color

GollumはRuby製のオープンソース・ソフトウェア。最近のWikiエンジンであれば大抵コンテンツの履歴管理機能がついている。独自に実装されることも多いが、手軽に実装するならば既に存在するSCMを利用する方が良いだろう。例えばGitは良い選択肢になる。 表示画面 話は変わりGithubではReadmeファイルなどを配置すると自動的に内容をプロジェクトトップページに配置してくれる機能がある。テキストフォーマットはMarkdownやRDoc、Textileなどが利用できる。この二つを組み合わせたのがGollumだ。 GollumはGitリポジトリ内で使うWikiエンジンだ。Gollumコマンドを実行すると、ポート番号4567でWebサーバが立ち上がる。そしてコンテンツを自由に作成できる。コンテンツは保存を実行するごとにGitリポジトリに追加されるようになっている。 拡張子を追加してアクセスす

こんにちは、SHIMADAです。Gitネタはたろちゃんに先を越されてしまいましたが、自分の環境でも、実際のプロジェクトでGitを実用的に使える状況になってきたので、そのへんについて書こうと思います。 ■ 前提 前提条件として、 1. プロジェクトのためのsvnリポジトリがサーバーに用意されていること 2. リポジトリが PROJECT_NAME/ `- trunk/ `- branches/ `- tags/ というSubversionの標準的なディレクトリ構成となっていること 3. ローカルに最新のgitがインストールされていること が条件となります。 前者が揃っていないという人は、まずSubversionを導入できるように社内での推進をがんばってください。 申請書とUSBメモリがないとコミットできないんだよ……、という人は、残念ながらあきらめてください。 （あれはネタだと信じていますが

yukiです。 空前のGitブームもだいぶ落ち着き、最近はGit記事をあまり見かけなくなりましたが、今日は空気を読まずにGit、それもgit-svnについて利用例を挙げつつご紹介しようと思います。 さらっと紹介されている記事は多いのですが、実際にこう使っている、などの例があまりなかったので、今回利用例を含めてご紹介していけたらと思っているので、もっと便利な使い方があるよ！という方の突っ込みをお待ちしております。 まずgit-svnについてご紹介すると、その名の通りgitとsubversionをつなぐ役割を果たすもので、subversionのリポジトリからgitでcloneして利用出来るというものです。 インストールはyum一発で簡単に入ります。 # yum install git-svn よくある例としては、業務で使うリポジトリはSubversionのまま使い続けているけど、個人

svnとgit両方使うようになりました。するとgitの便利さに感嘆する一方、svnのブランチ操作の面倒臭さが際立ってきました。特に、ブランチ操作ではgitは素晴らしく例えば以下のような例をご覧いただくとその差は一目瞭然かと思います。 ブランチ一覧を得る git branch svn list http://example.com/svn/branches ブランチを作る git branch mybranch svn cp http://example.com/svn/trunk http://example.com/svn/branches/mybranch -m 'create mybranch from trunk' 以上のように、svnはブランチをブランチとして扱っていないためとても面倒なコマンドを打たなくてはなりません。これではとてもsvnのブランチなんて使ってられないのでとっと

Javalobby - The heart of the Java developer community バージョン管理システムにGitやMercurialなどの比較的新しい分散型バージョン管理システムを採用する事例が増えている。もともとOSSプロジェクトで採用するバージョン管理システムは中央集権型のCVSが多かった。しかしCVSは厄介な面もあり、こうした問題を解決した同じく中央集権型のSubversionがCVSの次期候補として注目されていた。 CVSからGitへ、Fedora 13以降 止まらないGit人気、JRubyも移行 - 対抗馬はMercurial Git人気が止まらない、今度はGnome Gitバージョン管理システム採用拡大、Perl 5も移行 7つのバージョン管理システムを知る しかし現在のところ、バージョン管理システムは分散型のMercurialとGitに注目が集まって

This shop will be powered by Are you the store owner? Log in here

git init リポジトリの作成をする。 リポジトリを作りたいディレクトリに移動してコマンドを実行する。 公開リポジトリは bare リポジトリとして作成する。（bare リポジトリは通常 .git 拡張子を付ける） $ git init --bare /home/hoge/project.git git clone <複製元リポジトリのURL> リポジトリの複製をする。 リポジトリを作りたいディレクトリに移動してコマンドを実行する。 公開リポジトリは bare リポジトリとして作成する。（bare リポジトリは通常 .git 拡張子を付ける） $ git clone --bare /home/hoge/project.git git status 変更されたファイルの表示をする。 git-vim コマンド :GitStatus 編集中のファイル・リポジトリの git status を表

和田 卓人(@t_wada) 作『RSpec の入門とその一歩先へ、第2イテレーション』はクリエイティブ・コモンズ 表示 - 継承 4.0 国際 ライセンスで提供されています。 #coffee.rb の写経会に招かれた(というよりは押しかけた?)ので、先日の RSpec チュートリアルの続きを記します。このエントリは写経会に参加しながらのライブ更新でした。 (更新) 第3イテレーションも書きました。続きに興味ある方はご覧下さい 前回終了時点のコードと実行結果 前回終了時点でのコードを以下に記します。 message_filter.rb class MessageFilter def initialize(word) @word = word end def detect?(text) text.include?(@word) end end message_filter_spec.rb r