ソースコードのレビューはシステムの品質を高めるのに大切な作業だ。GoogleやVMWareでも使われており、ブラウザを使って差分を確認してコメントができるようになっている。社内向けには拙作のSubversionソースコードレビューシステムの宍道湖がある（Rails製）。 Git向けソースコードレビューシステム この手のツールはSubversion向けのものが多かったが、Gitでも使いたいならGerritに挑戦してみよう。 今回紹介するオープンソース・ソフトウェアはGerrit、Git向けソースコードレビューシステムだ。 GerritはGoogleが大々的に発表している訳ではないが、Google社員が開発しておりAndroidのオープンソースプロジェクトにおけるソースコードレビューにも利用されている。他のシステム同様に差分を見て、そこにコメントすることが可能だ。 差分を見てコメントする 差分
■ git のユーザマニュアルを iPhone で持ち運ぶ Git ユーザマニュアル と言う素晴らしいドキュメントがありまして、外で暇な時に見れたらいいなーと思ったんですが、1個のでかい HTML ファイルなので iPhone では若干キツいです。適当に分割したファイル作ろうかなーと思っていたら、github 上にリポジトリがあったりしたんで、ちょっと fork なるものを試してみました。 http://github.com/yasuaki/git-manual-jp/tree/master http://github.com/ktakayama/git-manual-jp/tree/master 分割 HTML ファイルの作り方 $ git clone git://github.com/ktakayama/git-manual-jp.git $ cd git-manual-jp/Docu
システム開発を行う上でバージョン管理の必要性はもはや言うまでもないだろう。数年前であればSubversionが主流だったが、最近ではGitが利用されることも増えている。が、Gitにはちょうどいいフロントエンドがなかった。Subversionには有名なTortoiseSVNがあるというのに。 エクスプローラにGit！ このフロントエンドの存在がSubversionの普及に一役も二役も買ったのは間違いない。だがWindowsにもついに実用的なフロントエンドが登場した。 今回紹介するオープンソース・ソフトウェアはGit Extensions、エクスプローラとも統合されるGitフロントエンドだ。 Git Extensionsは管理インタフェースであるGit Extensions、msysGit、KDiffなどを一括でインストールするソフトウェアだ。新しいリポジトリの作成や既存リポジトリのクローンは
gitで、bareな中央reposにpushしたい。 使うプロトコルは: http:// は遅いのでいや git:// はgit-daemon的に認証がちょっとやわそうなのでいまいち いい方法があったら教えてください＞＜ pushする人らはsshアカウントがあるので、git+ssh:// でいいや 複数ユーザがpushするので、パーミッションに気を使わなければならない: 共通のグループ(例:sandbox)に属させて、chown -R root:sandbox sandbox.git; chmod -R g+w sandbox; find sandbox -type d|xargs chmod 2775 すればグループの統一はOK 問題は sandbox.git/objects/ 下とかに新規で作られるディレクトリのパーミッション。 ~/.bashrcでumask 002すればいいんだけど
※ 画面は公式サイトのスクリーンショットより まだ実用的なレベルには達していないが、非常に気になるのでご紹介。 開発の現場ではSubversionのシェアが大きい。これは二つの理由が考えられる。一つは過去に導入し、実績があること。もう一つはTortoiseSVNに匹敵する便利なユーティリティがGitにはないということだ（Windowsに限定されるが）。 コンテクストメニュー だがその時代もついに終焉を迎えそうだ。Gitでもこんな魅力的なフロントエンドが開発されている。 今回紹介するオープンソース・ソフトウェアはTortoiseGit、まさにTortoiseSVNのGit版というべきソフトウェアだ。 TortoiseGitはスクリーンショットを見る限りではTortoiseSVNのアイコンを流用しつつ開発が進められているようだ。コミットのダイアログ、履歴管理などの機能がある。コンテクストメニュ
Blog Search when-present<#else>when-missing. (These only cover the last step of the expression; to cover the whole expression, use parenthesis: (myOptionalVar.foo)!myDefault, (myOptionalVar.foo)?? ---- ---- FTL stack trace ("~" means nesting-related): - Failed at: ${entry.path} [in template "__entry.ftlh" at line 3, column 25] - Reached through: #include "__entry.ftlh" [in template "entry.ftlh" at
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 git-pullで私なりの解釈で aha！が来たのでメモします。 これからは git-pull --rebaseにしよー 下記をそのままという感じなのですがｗ http://www8.atwiki.jp/git_jp/pub/Documentation.ja/user-manual.html#using-git-rebase そういえばトッポさんが言ってた：git-pull --rebaseを使うといいよ git-pullよりgit-pull --rebaseを使うといいよ(ただしという注意(下記太字)があるのでその辺は注意。ほとんどの人は関係ないと思うんだけど。。。) Here's a tip for keeping up
いきなり Git オブジェクトの話からはじまる。オブジェクトの概要に軽く触れてから、それから Git コマンドの説明に移るのだろうと思っていたら、そのまま関係性や参照方法といったオブジェクトの深い話にどんどん落ちて行くのだった。これでGit未経験者はついて来れるのか？この人、正気か？とか心配していたが、一旦オブジェクトを理解したあとで、Git コマンドの話に移った瞬間、今まで漠然としていた Git に対する疑問が全て氷解していることに気付いた。なるほど、確かにオブジェクトの理解は重要だ。 ある程度Gitコマンドは知っていて、ある程度Gitを使えてるけど、時々起きるエラーの意味や復旧方法がわからない、というGit初心者にはぴったりの内容だった。そこから次のレベルに行くにはまさにGitオブジェクトの理解が必須だったのだ。残念ながら参加できなかった、でも興味がある！というGit初心者はYugui
Githubが有名になっていることもあって、SubversionからGitに開発環境を移りつつある。各人でコミットできるというのは素晴らしく、開発スピードが向上するのは間違いないだろう。 インストーラーで簡単にインストール そしてLinuxやMac OSXであれば容易なGit開発環境の構築もWindowsでは面倒なイメージがあった。だがこれを使えばWindowsユーザでも簡単にGitが使い始められる。 今回紹介するオープンソース・ソフトウェアはmsysGit、Windows用Gitだ。 公式な方法として、WindowsでGitを使うにはCygwinを利用するというのがデフォルトになっている。だがCygwinが予め入っている人は良いとしても、GitのためにCygwinを入れるのが面倒に感じていた。 ヘルプ msysGitはWindows用のGit環境をインストーラー一つでGitコマンドをはじ
社内勉強会でgit入門をやった。(参考資料をダウンロード )。 最近の開発でgitを使っているので、そのファーストインプレッションみたいなものである。マニュアルについては、日本語訳もあるので参考にしてほしい。 分散コード管理システムということで従来の集中コード管理システムとその使い勝手が相当違うように感じる。 基本的な使い方は、リモートにあるリポジトリをローカルにコピーして、そのコマンドをgit cloneというのだが、そのレポジトリに対してチェックアウト、チェックインを繰り返し最後にリモートのリポジトリにコミットするという感じである。 基本的には、集中型とそう違わないのであるが、精神的には随分違うという感じがする。 まず、変更はローカルのリポジトリにずんずん行なうという点。ローカルのレポジトリにずんずん行なうので、その時点でリモートにアクセスできなくてもいい。ノートパソコンにレポジトリを
昨日会社のブログ（git入門/ユメのチカラ）gitの話をしたが、その続き。(資料はこちら) 開発は基本的にはリモートのレポジトリをローカルにコピーして、そのコピー（ブランチ）に対して変更を行い、ローカルにコミットを繰り返す。 ローカルなブランチに対するコミットがずんずん増えていくわけであるが、それと並行してリモート（マスタ）もどんどん変更されていく。ローカルな変更とオリジナルな変更をいつの時点かで同期をとらないといけない。ローカルな変更はいわば、オリジナル対する機能追加であったり機能変更であったり、あるいは単純なバグフィックスであったりするわけであるが、開発期間が長ければ長いほど、ローカルな開発期間中にオリジナルが相当量変更されることになる。 最終的にオリジナルにマージするには、並行開発期間中のローカルな変更を矛盾なくオリジナルに統合する必要がある。 ローカルなブランチ1をZの時点で作りそ
晴天の価値 2月中旬に出張で千葉へ行った。5日間の滞在中はずっと快晴で、気温は20℃に迫る春のような暖かさだった。仕事は朝から晩まで現場を走り回る過酷なもので、身体的にも精神的にも追い込まれた。毎朝、京葉線から見える美しい景色を眺めて正気を保っていた。太平洋へ燦々と…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
