今やバージョン管理ツールとして圧倒的な人気を集める「Git」ですが、Linuxカーネル開発のために作られたという経緯もあり、使いこなすにはかりの経験値が必要となります。 この問題を解決するために、Googleのソフトウェアエンジニアによって、新しいバージョン管理システム「Jujutsu」の開発が進められています。 Jujutsuの素晴らしさを紹介する記事「jj init 」によると、Jujutsuは過去のバージョン管理システムの問題点やメリットを分析して作られていて、Googleの既存のバージョン管理システムを置き換える勢いがあるとのこと。 JujutsuはmacOSでは、brew install jjを実行するだけで使用することができ、バックエンドとしてGitを使用しているため、採用にコストがかからないというメリットもあるそうです。 公式サイトでは、Jujutsuの特徴がリストアップされ
以下は、私がよく交わす会話の一例です。 人物A：FacebookやGoogleは、巨大なモノリシックリポジトリ（モノレポ）を使っているんだってよ。 私：みたいだね。あれは本当に便利だと思う。 人物A：僕に言わせれば最悪の愚行さ。全てのコードを単一のリポジトリに入れるのがヒドイ考えだと、FacebookやGoogleはなぜ思わないんだろうか。 私：FacebookやGoogleのエンジニアたちも小さなリポジトリには精通しているだろうけど（ 濱野純（Junio Hamano） 氏はGoogle勤務だし）、単一の大きなリポジトリの方が、きっと”ある理由”で好みなんだよ。 人物A：なるほどね。僕としては、まだちょっと違和感はあるけど、モノレポが使われる理由は分かったような気がするよ。 “ある理由”はかなり長いので、同じ会話を何度も繰り返さなくていいように、ここに書き留めておこうと思います。 シンプ
ここ2年ぐらいで俺が働いた現場はみんなgitを採用している。就職エージェントと面談するときもgit経験の有無をよく訊かれるし、今ではVSSやCVSどころか、SVNですら時代遅れになってきて、SVNを使っている現場は「レベルが低い」「保守的・旧態依然」という雰囲気すら感じる。 俺としては4-5年前からgit(GitHub)を使っているし、gitを使うこと自体に抵抗はない。一通りの基本操作はできるし、人並みにはできると言っても差し支えはない。 …が、正直gitの良さがあまり見えてこない。 もし俺が中規模以上のプロジェクトのリリースを本格的に管理する側であれば全然違った感想を持ったかもしれない。でも一人の開発者として、せいぜい10人程度のプロジェクトで利用する限り、「gitで良かった」という状況があまり思い当たらない。 ではgitの何が気に食わないのか書いていきたい。 ①gitは馬鹿には難しい
はじめに もうだいぶ前に、当時主流だったバージョン管理システムである、CVSを研究して開発に使用したことがあります。 周りに知っている人がいなかったので、ネットで調べたり、本を買ってきて読んで勉強したりましたが、最初のうちは、ぜんぜん分からなくて、かなり苦労しました。 今回、Gitについて調べていて、やはり同じように、はじめは、ぜんぜん分からない状態が続きました。 CVSの時も、今回のGitの時も、「ううん、僕にはバージョン管理を理解する才能が欠落しているのだろうか？ もうやめちゃおうか」とも思ったのですが、「えいくそ！」と何とかがんばって続けて、 最終的には理解できました。 この２つのバージョン管理システムの研究で苦労した経験から、 なぜ最初は全然理解できなかったのか、その理由が分かりました。 皆さんがコンピュータのソフトで分からないときは「こんなことがしたい」と思いながら ヘルプを見た
チェコTMate Softwareは9月24日、SubversionからGitへのマイグレーションを容易にするツール「SubGit 1.0」を公開した。SubversionリポジトリとGitリポジトリを双方向にレプリケーションする機能を持ち、既存のSubversion環境を変更なしにGitからアクセス可能にするという。 SubGitはJavaで実装されたツールで、SubversionレポジトリをGitリポジトリにマイグレーションする機能を持つ。また、SubversionとGitを併用するための同期機能も備えている。Gitには同様の機能である「Git-Svn」が含まれているが、これと比べた優位点として、レポジトリのクローンが不要な点、Gitレポジトリに対してコミットでき両者間の変換は最小限で済む点、SubversionとGitの両方の機能をすべて利用できる点、さまざまなツールを利用できる点な
2009年6月12日に、僕は分散バージョン管理システムMercurialについて短い記事を書いて、そこで次のような言ってます。 実は僕は、分散バージョン管理という発想と仕掛けを最初はまったく理解できず、「エエーッ？なんだそれ」「そんなんでうまくいくのかよ？」とかグダグダ言っていたのですが、いったん使い始めればラクチンラクチン。 要するに、最初は誤解に基づき否定的だったってことね。僕と同じような誤解をする人がいるような気はしたのですが、あまりうまく解説できそうにないので*1： 「四の五の言ってないで、使ってミソ」ってことです。 最近になって、ジョエル・スポルスキ（Joel Spolsky / 青木靖 訳）の「分散バージョン管理で間違いないって、ベイビー」という記事を目にしました。2010年3月17日に書かれた記事です。 なんと、あのジョエル・スポルスキも最初は誤解に基づき否定的だったらしいで
InfoQに分散バージョン管理の可能性の記事があったのでメモ。 ラフなメモ書き。 【元ネタ】 InfoQ: エンタープライズ分野での分散バージョン管理システム (引用開始) DVCSは速度を重視して設計されている。新しい実装方式、新しい技術、苦労した獲得した知識の結集であり、前世代のSCMよりも高速に動作する。ローカルにリポジトリを持てるから速いというだけでなく、従来のSCMと同様の条件でも速い。また、ブランチ作成も得意でマージ機能も優れている。90年代後半から2000年代前半ではブランチ作成とマージは"悪"だった。その当時の主流のバージョン管理システムのブランチ作成機能とマージ機能が貧弱だったからだ。処理が遅く、エラーが頻発していた。その結果、若い開発者はブランチ/マージ嫌いとして育ってしまった。DVCSは高速に動作するブランチ作成機能と本当に使えるマージトラッキング機能を実装した。30
以前gitで一度行った変更をなかったことにする方法4つを紹介しましたが、 日常的に git を使用していると他にも様々な 「なかったことにしたい」「元に戻したい」 という状況に遭遇します。 そのひとつひとつについて対処方法を紹介していきます。 目次 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いてみた。でももう要らない。問題2: トピックブランチをマージしたけど実はまだ不完全だった。マージをやり直したい。問題3: リリース後に発覚したバグ。原因は30日前に自分が行ったコミットだった。なかったことにしたい。問題4: 新しいコミットしようとして間違えてgit commit –amendで書き換えてしまった。元に戻したい。問題5: 色々作業していたら作業ディレクトリの内容が混沌としてきた。一度綺麗な状態にしたい。問題6: 作業ディレクトリにゴミファイルが溜まってきた。一度綺麗
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
最近、twitter 上で subversion 連携に関する質問に答えるために、convert エクステンション(標準同梱)とか、hgsubversion エクステンションのソースを確認しまくったので、折角だから Mercurial と Subversion の連携に関してまとめてみた。 結論から先に書いておくと、これまで twitter 上では: Mercurial ⇒ Subversion への成果反映が必要であれば、選択肢は hgsubversion エクステンションの一択 という回答をしていたのだけれど、色々考えてみるに: 『hg コマンド経由での svn リポジトリへの反映』に拘らなければ、実は convert エクステンションの方が便利じゃねぇ？ というのが現在の僕の印象。 但し、Mercurial の convert エクステンションは、認証処理周りの実装が無い。そのため、
git先日、msysGit（Git for Windows）がいよいよ公式に UTF-8 をサポート！ という記事で「UTF-8 対応のコードがコミットされた」ことをお伝えしましたが、ついに、UTF-8 対応の新バージョン、msysGit 1.7.10 がリリースされました。いよいよ Windows でも日本語ファイル名を扱えるようになったので、「git では "詳細設計所仕様書.xlsx" をコミットできないんでしょ？」とブーブーいってた人を説得できる材料はそろいました!!!!それを記念して、この記事では UTF-8 対応の msysGit 1.7.10 を試してみた ブーブーいう人を黙らせるための「GUI で git する Windows 向けツール」まとめの2本立てでお送りしたいと思います。UTF-8 対応の msysGit 1.7.10 を試してみたさっそく Google Code
tbaggery - A Note About Git Commit Messages A successful Git branching model » nvie.com Commit Often, Perfect Later, Publish Once—Git Best Practices だいたいこれらに書いてあることを考えている。 基本的にGit Successful Branch Modelで運用する。git-flowを入れて使っているけど、手でやってもそんなに面倒ではないし好きなようにしたらよさそう。 Subversionを個人で使っていたころはブランチはよくわからないけど恐しいものだったけど、Gitを使いはじめてだいぶ親しめるようになった。 文字通り、ブランチ、枝である。気軽に扱えるということは理解の助けにもなる。 コミットの単位 論理的に最小限度のコミットをつくる。「こう
SCM-ManagerThe easiest way to share and manage your Git, Mercurial and Subversion repositoriesGetting started SourceCode ManagementSCM-Manager comes out of the box with support for Git, Mercurial and Subversion. All three types can be managed the same way over one interface. Easy InstallationSCM-Manager can be easily installed on the platform of your choice. We are trying to make the installation
しばらくTDDBCで聞いたネタを雑感を交えつつ復習的にちょっとずつ書いて行ってみようと思う。 そういうわけでぐぐれば他で書いてあること多めです。あと網羅的には書かないです。ｇｄｇｄです。 三本柱とは 和田さんが考える三本柱は以下の通り。 バージョン管理 テスティング 自動化 バージョン管理 TDDのイベントだったので深くつっこみしなかったけど和田さんの考えでは最重要とのこと。 テストや自動化はなくてもなんとかなるが、バージョン管理はないと死亡確定。 「セーブなしでRPGクリアとか無理ゲーじゃないですか」みたいなことを言っていた覚えが。 雑感 未だそんな無理ゲーに挑んでる現場も少なくないような気がします。 ところでこれは後々の懇親会で聞いたことだけど、Subversion等を経ずにGitを使う分散バージョン管理ネイティブが出て来始めているようだ。 個人的には初めて分散バージョン管理システムを
Redmine上からSubversion,Git,Mercurialのリポジトリ作成ができ、公開したリポジトリにプロジェクトに所属したユーザであれば、Redmineのユーザアカウントでアクセスできるようになります。 Subversion,GitなどのツールやRedmineとアジャイル開発、継続的インテグレーションに便利な各種プラグインに加え、今回の連携設定などをまとめてインストールできるALMiniumというものがあります。 前提 OSがCentOS Apacheをインストール済み （# yum install httpd） Apacheの実行ユーザ名とグループ名はapache Subversionとmod_dav_svnモジュールがインストール済み （# yum install subversion mod_dav_svn） Gitインストール済み(# yum install git)
社長におねだりしたらベイスターズ買ってくれないかなぁ。どうもこんにちは nakamura です。 シーブレインでは今も昔もソース管理に Subversion を使い続けていますが、最近は協力会社さんとのやり取りなどで何かと Git にさわる機会が増えてきました。最初はチンプンカンプンでしたが、ようやく何となく基本的な部分が分かってきたので、Subversion ユーザ的な目線でちょこっと説明してみたいと思います。 コマンド例 初期設定 Git ではユーザ毎の設定内容も git コマンドで操作します。とりあえずいつも以下のような感じで設定してます。diff に使うコマンドとかも指定できるみたいですね。 # 名前 git config --global user.name "Tadashi Nakamura" # メールアドレス git config --global user.email n
ちょっと面白いものを見つけたので紹介。 DVCSといえばMercurialやGitが有名だ。 BitbucketやGitHubのお陰でDVCSをインストールするだけで個人でも簡単にBTSを利用できるようになった。 しかし、仕事で使っていると外部のリポジトリにpushできないこともある。 そういった場合はTracやRedmineなど本格的なBTSを導入する必要があるだろう。 ただ、ちょっとしたプロダクトを作るのにわざわざBTSをインストールするのは面倒だと感じることもある。 そんなときにちょっと使ってみたいDVCSがあった。それがveracityだ。 これはなに？ 2010年ごろにリリースされたDVCS。以下のような特徴を持つ。InfoQでも紹介されていたようだ。 Apache License v2 Mac、Windowsで利用可能 CおよびJavaScriptで記述されており、拡張機能をJ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く