(特に Git 併用ユーザには是非読んでおいて欲しい) Mercurial における『ブランチ』の概念 〜 その１ - 彷徨えるフジワラ
ここ暫く、Twitter や ML 等で、Mercurial の『ブランチ』に関する質問 (特に Git の『ブランチ』との対比) に答える機会が度々あったので、Mercurial における『ブランチ』の概念に関してまとめてみた。 実のところ、SCMBootCamp in Nagoya #1 での、稲田氏 (id:methane) の基調講演資料における Mercurial のブランチに関する説明 (30ページ目) を見て: 別途口頭での説明が無いと、初学者や他のツールからの移行者にとっては、誤解を招きやすいのではなかろうか？ と思ったのが、このエントリを書く元々の動機だったのだけれど、書き上げるのにかれこれ３ヶ月以上を要してしまったというのは、反省することしきり。 っつーか、ここ暫くは本家に (議論の叩き台としてリジェクト覚悟で) パッチ提案したりと、色々アレだったんで、その辺は勘弁して
Mercurialでのブランチ
Life with Web Browser Engine (Gecko, WebKit and etc), Mobile and etc. まぁ、自分がMercurialユーザーだったらvim-jpの記事を読んで間違いに気づくはずだ。 まず、Mercurialでのブランチというのはどういうものが理解すべき。Mercurialでは、ブランチというのは、一種のtagとheadsの総称でしかない。gitだとローカルブランチとリモートブランチという概念があって、ブランチをpushするときには、特別な方法を取る必要があるけど、mercurialの場合は通常のpushに自分で作ったブランチが含まれてしまう (もちろんheadsが合わなければリジェクトされるし、明示的にブランチへのpushを使う必要もある)。 だから、多数での開発をしてる際に自分のコードを管理するためにブランチを作るのはよくない。Mer
Mercurialでアレを元に戻す108の方法 | Webシステム開発／教育ソリューションのタイムインターメディア
前回[@kana1さん](http://twitter.com/kana1)による[「gitでアレをもとに戻す108の方法」](/tech/git-undo-999)が大反響で世間はやはりgit使いが多いのかと再認識しました。 私も普段はgitを使っていますが、お仕事ではMercurialを仕事で使っているのでのっかって書き連ねてみましょう。 ### 問題1: ライブラリの新機能を試すためにあれこれ適当なコードを書いていくつかコミットした。でももういらない さて初っぱなから行き詰まりそうです。基本的にMercurialは「コミットを積み重ねたものを後から編集する」ことに弱いのです。 MQを使って解決してみましょう。 $ hg update -r {revision} $ hg qimport -r {revision+1}:tip $ hg qpop –all $ hg qseries |
Mercurialでのブランチの使い方がわかりました - soutaroブログ
ちょっと前に友人から入門Gitを安く譲ってもらったんですけど，そっちも読みつつ，結局いつもはMercurialを使っています．2年くらい前に，Subversionから移行して，そのままなんですよね．基本的にはGitに移行したいんです．でも，そもそも私がバージョン管理システムに求めるのは，複数の計算機で作業するときにちゃんと同期してくれることと，履歴を取っておいてくれることくらいなんで，GitとかMercurialみたいな大袈裟な機能は要らないのかもしれない． 入門Git 作者: 濱野純(Junio C Hamano)出版社/メーカー: 秀和システム発売日: 2009/09/19メディア: 単行本購入: 31人 クリック: 736回この商品を含むブログ (158件) を見る と言いつつ，入門Gitを読んで思ったのは，とりあえずブランチをちゃんと使ってみようということでした．ブランチのユースケ
Mercurialの使い方（ブランチ編）
changesetにタグをつける $ hg tag Version-1.0 ワーキングディレクトリをVersion-1.0の状態に戻す $ hg up -r Version-1.0 このバージョンに修正を加えてcommitすると新しいheadができる。 このheadにVersion-1.1というタグをつける $ hg tag -r . Version-1.1 Version-1.0から行った二つの変更（新規＆バグフィックス）をマージする $ hg merge ベターなのは、stableリポジトリとdevリポジトリを分ける方法（以下の14はリリースタグを付けたchangeset） $ hg clone -r 14 recipes recipes-stable $ hg clone recipes-stable recipes-dev stableではリリースしたバージョンを管理（バグフィック
ブランチの作成 - Clipboard
Mercurial でブランチを作るときのメモ。 所作 # 適当にコミットしていき version 1 をリリース $ hg init repo $ cd repo $ touch hoge.txt $ hg addremove $ hg ci -m 'released initial version 1' # version 1 ブランチを作成した後 default に戻る $ hg branch 'version 1' $ hg ci -m 'added version 1 branch' $ hg update -C default # 適当にコミットしていき version 2 をリリース $ emacs hoge.txt $ hg ci -m 'released version 2' # version 2 ブランチを作成した後 default に戻る $ hg branch '
MercurialとGitのブランチの違い - wyukawa's diary
MercurialのブランチというのがどういうものでしかもそれがGitと同じなのかどうかもいままでよくわからなかった。 その辺のモヤモヤがこれを読んで理解できた（気がする）。 experimentalworks » Blog Archive » Mercurial bookmarks A Guide to Branching in Mercurial / Steve Losh まずMercurialでは以下の4種類のブランチがある。 リポジトリをcloneしてつくるブランチ hg bookmarkで作るブランチ hg branchで作る名前付きブランチ 名無しブランチ リポジトリをcloneしてつくるブランチは hg clone test-project test-project-feature-branch というように単純にcloneして新機能を開発してあとでマージなりリベースなりする
A successful Git branching model を翻訳しました
Vincent Driessenさんの "A successful Git branching model" を翻訳しました。 元記事はこちら： http://nvie.com/posts/a-successful-git-branching-model/ （翻訳の公開と画像の利用は本人より許諾済みです） このブランチモデルの導入を補助してくれる、git-flowというGit用プラグインがあるそうです。 翻訳の間違い等があれば遠慮なくご指摘ください。 A successful Git branching model この記事では、私のいくつかのプロジェクト（仕事でもプライベートでも）で約一年ほど導入して、とてもうまくいくことがわかった開発モデルを紹介する。しばらく前からこれについて書くつもりだったんだが、今まですっかりその時間を見つけられずにいた。ここでは私のプロジェクトの詳細については書
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
