Mercurial 対 Git：なぜ Mercurial を選ぶのか？ - Atlassian Japan
ここで見たように、Git は、Subversion ユーザーにその CLI に早く慣れてもらうようにするということをあまり考慮していません。 新しいコマンドを入力するために指を再度トレーニングすることによりこの問題を回避することはできますが、それでもシステムを移行する上での障害の一つになるでしょう。その上、Subversion ユーザーにとってフレンドリーで、かつ、強力で美しいインターフェースをもった Mercurial があるので、Git がなくても問題はありません。 履歴が安全な Mercurial Mercurial の哲学は、 “履歴は永久的で神聖である” ということです。Mercurial のコアには、履歴を変更できるコマンドがたった一つだけあります。hg rollback です。このコマンドは直前のプルやコミットを “取り消し” ますが、それより前のものには一切触れません。 G
Git 対 Mercurial：なぜ Git を選ぶのか？ - Atlassian Japan
今回は Atlassian の開発者である Charles O’Farrell によるゲストブログです。チームが DVCS として Git を選択する理由について説明します。Charles はコーディングをほとんど DVCS 上で行い、また ClearCase から Git へユーザーを移行させる作業を行ってきました。 前回の記事では、分散バージョン管理システムとしてチームがなぜ Mercurial を選択するのかについて考えてみました。今回は、分散バージョン管理システム (DVCS) として なぜ Git が有力な選択肢であるのかについて考えてみましょう。 1970 年の黎明期から、ギークたちはどちらが善でどちらが悪かという血なまぐさい論争を長い間行ってきました。それが Vim と Emacs との間の戦いです。最近では、それとは別のツールセットについて、ギークたちは本来の仕事そっちのけ
１分でわかる、GitとSubversionにおけるブランチの違い · DQNEO日記
Subversionにおけるブランチとは、ディレクトリのことである。 Subversionにおいては、ブランチとは単なるディレクトリに過ぎません。 Subversionではよく下記のようなツリー構造にすることが推奨されます。 project - trunk - branches - foo - bar ブランチfooやブランチbarは、たいていtrunkディレクトリをコピーして作ります。 「ブランチを作成する」という行為は「ディレクトリをコピーすること」と操作的には同じであり、１コミットとして扱われます。 $ svn cp svn://path/trunk svn://path/branches/foo -m "make branch" 「ブランチの名前変更」も「ディレクトリのリネーム」と同じ操作であり、やはり１コミットして扱われます。 $ svn mv svn://path/branch
SVNのブランチは貧弱なのか - wyukawa's diary
もう8月ですね。暑いですね。W杯はスペインの優勝で幕を閉じました。 僕は7月からやばそうなプロジェクトに入りました。僕の7月の残業時間は60ですが、100オーバーの人も少なくないようです。夜中の11時過ぎても人がいっぱいいるのはやっぱ変ですよね。 来年の3月まで続くのにこの状況です。自分も含めて心身壊す人が出ないことを祈ります。 さてそんな状況ではありますが、興味深いエントリがありました。 分散型バージョン管理システムは実際の開発現場でどれだけ普及するか？ - 現場のためのソフトウェア開発プロセス - たかのり日記 エントリの内容には割と同意です。 僕自身も含めてですが、いままで見てきた感じでいうとSVNを使いこなしてかつ構成管理を意識できる開発者は多くないのが現実です。 ありがちなのはこんな感じ。 コミット漏れによるコンパイルエラー 他の人の変更内容を誤って上書き 自分が作業しているEc
Gitに潜む光と闇 | gihyo.jp
今年に入ってから、急速にGitが注目を浴びています。Google Trendsを見ると、Subversion、Mercurialなどに比べると圧倒的にGitの人気が高いのがわかります（図1）。 図1 Google TrendsによるGit（青）、Mercurial（赤）、Subversion（橙）の検索数 しかしながら、Gitを利用する人の意見は2つに分かれています。 A．わかりにくい B．すごく便利だ なぜこのようなに印象が二分されてしまうのでしょうか? 本稿では、「Gitに潜む光と闇」と称してこれらの意見に対して考察していくことにします。 Gitはわかりにくい? Gitがわかりにくいと思う人は、どうしてそう感じるのでしょうか。そのあたりのおおよその事情は下記のようなことだと考えられます。 （1）Subversionとコマンド体系が少し違う バージョン管理ツールとして、Su
Gitについて書いておく
※ 本記事の内容は「僕の個人的な考え」であって、正解とは限りません。予めご了承ください。あと、長いです。 能書き ここ半年ぐらい、僕のまわりでは「Gitに移行しようぜー」的な波が押し寄せてきてる。前職の職場も、今の職場も、大学時代の友達も。一方僕は、学生時代(3年前ぐらい？)にたまたま偶然Gitに首突っ込んだので、もう既にGitがないと生きていけない体になってしまっているという立場。ということで、Gitについて思うところを僕なりに一回文章にしてみようと思う。 ここに書くのはGit入門ではなく、「Gitの基本コマンドは覚えて使えるけど、どうやったらGitっぽくつかえるか、Gitの恩恵を得られるか掴みきれてない」ぐらいの習熟度の方に参考になるような内容の予定。もちろんここに書いてあることに従えと言いたいわけではないので、違う意見の場合はぜひコメントなど頂ければ幸いですし、Git勉強中の方は1つ
仕事で使ってる巨大SVNレポジトリをGithubに移管するためにやったことまとめ · DQNEO日記
動機 Subversionで困ってない ぶっちゃけSubversionで全然困っていませんでした。 コードレビューはちゃんとやっていたし、マージ・ブランチングも自作シェルスクリプトのおかげてスムーズにやれていました。 よく「Gitはマージが賢い、ブランチ作成が一瞬でできる」とかいわれますが、Subversionだってちゃんと使えばコンフリクトなんかめったに起きないし、ブランチ管理・マージだって全然めんどくさくない。 特にver1.7からはサーバもクライアントも大幅に高速化されたし、.svnディレクトリが.gitみたいに１個になったし、rebaseみたいなことだってできる。(sync merge & reintegrate) ただ、世の中が一斉にGitにシフトしている中でいつまでもSubversionを使っててよいのかという不安がありました。 また、月から金までSubversionにどっぷり
Git と Mercurial が Subversion より優れている点 - tcha.org
2010 年 2 月 1 日 For home projects, can Mercurial or Git (or other DVCS) provide more advantages over Subversion? - Stack Overflow より、抄訳。 この記事は Git と Subversion の比較だけど、ここで言っていることは全て Mercurial にもあてはまる。 リポジトリの初期化: git: git init subversion: svnadmin create /path/to/repo svn import http://long.url.to/repo yourwork rm -R yourwork svn checkout http://long.url.to/repo yourwork うぁー、めんどくせー!! リポジトリとメタデータ: git
自分が公開しているOSSにPullRequestが来たときに起こったことすべて - M_Ishikawa
ここのところなにかといえばGruntのことばかりでGREE Advent CalendarでもネタGruntプラグイン作って晒してみたりして遊んでます。 そんなところ、自分で作って仕事でも使っていて公開しているGruntプラグイン grunt-md5filename に突然PullRequestが来たんです！！！ それはそれはもう感動で胸がいっぱいになりました。自分の作ったのを使ってくれている誰かがいる、それだけでも十分幸せなことなのに開発に参加してくれるという、この上ない喜びを味わせていただくことができました。僕をここまで育ててくれた両親に感謝したいと思います。生きててよかった！ 記念にスクリーンショット撮りまくったので自慢させて僕と同じように初めてプルリク来た方の参考になればと思います。 あ、これは Git Advent Calendar 2013 18日目の記事になります。なのでいち
社内にGITを持ち込むために上の人を納得させるセリフ集 - Qiita
Gitアドベントカレンダー10日目です。 10日目で区切りもいいので少しネタ臭い内容を。 攻め文句 「継続的リリースを支える運用フローに、gitflowは最適」 現場でgitを押す理由としては、ほんとにコレに付きます。学習コストを差し置いてでも導入したい、という点にまずコレが挙がるんじゃないでしょうか? 機能ブランチとチケット駆動開発の流れ、それにSVNのチェリーピックを露骨に危険&手間とアピールしていけばgitの重要性は認識してもらえるはず。 「世界中で採用されているgithubで、ソーシャルライクな社内開発コミュニケーションを」 お金に余裕のあるところでは、是非ともgithub enterpriseを検討してもらいましょう。開発はコミュニケーション命、的な話でコミュニケーションの重要性を説くといいと思います。 開発者としても、Web上でソーシャル的にコードレビューなどを行えるのは非常に
Gitを使い始めて1ヶ月が経った - ぱせらんメモ
もうそろそろSubversionだけじゃいかんだろうと思ってGitを使い始めて1ヶ月が経った。 試しにいじってみることは何度かあったんだけど、本格的に運用を始めたのは今回が初めて。仕事とプライベートで使ってる。 とはいえいきなりリポジトリをGitに変えられるわけもないので、git-svnで連携するスタイルで使っている。 むしろgit-svnでしか使ったことがないので、普通のpush/pullとかやったことないという……ｗ 今の自分の使い方 これが正しいのかどうかわからないけど、今はこんな感じのワークフローになっている。 git svn cloneは既に終わってるとして、 とりあえずリモートの更新内容をローカルに取り込む。 $ git svn rebase feature1ブランチを作って作業する。 $ git checkout -b feature1 ……feature1の作業 他メンバー
「Pull Request」 はオープンソースに限らず使える優れた開発フローだ - 肉とビールとパンケーキ by @sotarok
チーム開発において、「チケット/Issue」「TDD」「コードレビュー」など、ソースコードの変更に対する効果的な開発フローについてよく考えるのだけど、なんにしてもこのあたりは非常に課題が多く、各社各コミュニティで色々なやり方が模索されているポイントだと思う。 で、まぁご多分に漏れず僕もよく考えるわけだけど、現状その過程で Pull Request こそが非常に効果的なのではないか、と思うので、ちょっとまとめてみようかと思う。 もちろん、言うまでもないようなことだよ、という人もいるかもしれないけど、そういう人がたくさんいると、非常に喜ばしいことだね。 Pull Request とは GitHub でこう呼ばれているので、こう呼ぶことにするが、ここでは、複数のリポジトリ/ブランチ間でのオープンな patch のやりとりのことだと考える。 あと、自分が使っているのが Git なので、ここでは G
git addの取り消しと、コミット済みのファイルを除外する方法 - kanonji’s diary
git addを取り消す $ git reset HEAD foo.txt git add で編集内容が index に追加*1されます。 間違えて index に追加した場合に、このコマンドで取り消しができます。 $ git add foo.txt $ git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: foo.txt # $ git reset HEAD foo.txt Unstaged changes after reset: M foo.txt $ git status # On branch master # Changed but not updated: # (use "git add <file
git のリモートリポジトリを構築する - trial and error
最近、でもないかもしれないけど、ソースコード管理に git を使うようになりました。 あまり、ソースコード管理する場面を個人的には感じられず、今まであまり使ったことなかったのですが、使ってみると非常に便利ですね。 ちなみに、僕は svn も cvs も、ほんの少ししか触ったことなくて、そのおかげか？ git の導入は非常にスムーズでした。 僕は、家と大学と、いろいろなところでちょこちょこ開発してます。なので、リモートリポジトリがあると非常に便利です。 今までは、github を使っていました。が、github はお金払わないと private なリポジトリは作成できないのです。 あまり、public にしたくないようなものを開発したいときもあるので、今回は家のサーバーにリモートリポジトリを構築してみました。 忘れそうなので、軽く手順を。 まず、サーバーに git のリポジトリを作成しましょ
always testing: gitとJenkinsの連携(Windows7/64bit)
2011-03-28 gitとJenkinsの連携(Windows7/64bit) 絶対忘れそう（次にセットアップする際に同じ過ちを繰り返す可能性が高い）ので、メモる。 http://jenkins-ci.org/ Windows版のNative Packageを落としてインストール。 http://code.google.com/p/msysgit/ msysgitのFull Installerを落としてインストール。 ちなみに、この際、Windowsの環境変数PATHに、cygwinという文字列が含まれていると問題ありなので要注意（これで一日無駄にした）。 Jenkinsでジョブを作る。 Hudson氏の頃は、ジョブのワークスペースは、C:\Users\Hoge\.hudson\jobs\JobHogeに作られていたが、Jenkins氏はC:\Program Files
Git のおさらい - 今日も適当ダイアリー
8/21（日）にタイレルシステムズさんに会場提供いただいて行われた TDDBC Tokyo 1.7 for PHP に参加してきました。 参加登録に出遅れ補欠だったのですが、@shishi4tw さんから、 LT してくださる方を 1 名補欠の方の中から募集します。LT してくださる方は LT 枠として、本編にも参加していただけるようにします。題材は広く PHP や TDD に関することなら何でも良い、つまり、開発に関することなら何でも良い、とします。 との言葉をいただき、参加したかったので、LT表明をして参加させていただけることになりました。 そこで、「Gitのおさらい」というLTをしてきましたので、その内容をまとめておきます。 なお、勉強会本編の感想は別記事でアップする予定です。 下にあるスライドと併せてお読みください Git 「ぎっと」と読みます バージョン管理システムの一つ CVS
git - 簡単ガイド
アッド & コミット 変更されたファイルを選択します。 git add <filename> git add * を実行するとIndexに追加されます。 これは基本的な作業の一つです。 変更を実際に適用するには git commit -m "Commit message" を実行します。 変更がHEADに入りましたが、 リモートリポジトリには未だ入っていません。 変更のプッシュ この時点で、変更がローカルリポジトリのHEADに適用されました。この変更をリモートリポジトリに適用するには git push origin master を実行し、masterの代わりに適用のブランチ名を入れます。 もし既存リポジトリをクローンせずに使用した場合 git remote add origin <server> を実行すると、リモートリポジトリを登録する事が可能です。 これで変更を特定なリモートリポジト
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blogger
http://unicus.jp/skmk/archives/41
Perlゼミ(サンプルコードPerl入門)