長々続いたこのシリーズも、今回で一応終了。 最終回の今回は、『名前付きブランチ』に関する、ちょっと踏み込んだ話題を扱う。 普通に運用する場合には、それほど必要となる局面は無いかも知れないけれど、知っていればちょっとは便利になるかもしれない事柄などを。 以下、各回で説明する主なトピック: その１： 名前無しブランチ その２： 名前付きブランチ その３： ブックマーク その４： 構造的ブランチ その５： 名前付きブランチ運用で必要なトピック その６： 名前付きブランチに関するちょっと踏み込んだ話（本エントリ） 構造制約を持たない名前付きブランチ その２でも述べたように、『名前付き』ブランチは、各リビジョン毎に持っている『ブランチ名』属性を元にした、一種のリビジョングループと言える。 情報管理上、『ブックマーク』や Git の『ブランチ』のように、単一の名称に対して『ヘッド』が一つ、といった制約
3選とか言ってますが大した内容ではございません＞＜ すみませんすみません＞＜ ■１：gitのbranchは跡形もなく消せる ほとんど常識ですが、以下のコマンドでgitのbranchは消せます。git branch -Dこのコマンドを実行すれば、たとえHEADに対してマージされていなくてもそのままブランチを消すことができます。ということで、ちょっとしたテストコードなどはブランチを切ってそこで実験し、後からブランチごとたたき落とす運用が可能です。 余談ですが、gitのbranchはSubversionと使い勝手や実装が似ている感じがします。Subversionのbranchもタダのディレクトリコピーなので、好き勝手に作って消してが可能ですから。 ■２：Mercurialのbranchは基本消せない、「未使用」か「クローズ」にはできる 問題はここから。Mercurialのbranchは、基本的に
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
前回[@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は、Merucurial拡張という拡張モジュールを使って、Merucrialの挙動をいろいろ拡張できるようになっています。 デフォルトのままだと使いにくいので、Mercurialを使う上で便利にしてくれる拡張を設定しておきましょう。 デフォルトでバンドルされているMercurial拡張は、Using Mercurial Extensionsにまとめられています。 今回はGit使いがMercurial使いに転職するときに、Gitで実現できたことをMercurialで実現するための、組み込み拡張、および、サードパーティ製の拡張について紹介します。 色づけしよう ブランチの確認、diff、パッチ等々、色づけされていないとつらいです。 というわけでGit同様に色づけしましょう。 Color Extensionはすでにバンドルされているので、.hgrcに次の記述を加えましょう。 こ
ソフトウェア開発のプロジェクトでバージョン管理システムに何を採用すればいいのか迷っていませんか？ いくつかのケースを想定して採用すべきバージョン管理システムを挙げさせてください。 この記事の前半ではバージョン管理システムを使うことで得られる多大なメリットについて書きます。 そして記事の後半ではいくつかのケースに応じたウェブベースのバージョン管理ホスティングサービスを挙げています。 この記事は「Mercurial Advent Calendar 2011」１8日目担当の@tksnが書かせていただきました。前日は@worarsさんの「Mercurial入門！」でした。 バージョン管理システムって何に使えるの？ ファイルやその集合であれば何にでも使えます。つまりデジタルデータならなんでも管理できます。たとえば次のようなものを扱うプロジェクトで使われています。 ソフトウェア ウェブサイト 論文・小
このページは CommunicatingChanges の翻訳です。 Mercurialには変更を取り交すための3つの異なる方法があり、それぞれ有用な場面が異なります: push/pull/clone - リポジトリ間で直接変更を取り交す import/export - 変更点をパッチとして生成し、取り込む bundle/unbandle - 変更点をMercurialの内部フォーマットで取り交す push/pull/clone これは開発者間でチェンジセットを交換するための通常の方法です。高速かつ容易で、ほとんどの環境において利用可能です。 $ hg clone hg work requesting all changes adding changesets adding manifests adding file changes added 1218 changesets with 2
Mercurial is a modern, open source, distributed version control system, and a compelling upgrade from older systems like Subversion. In this user-friendly, six-part tutorial, Joel Spolsky teaches you the key concepts. Also, Fog Creek offers free monthly webinars that go over the basics of Mercurial.
『Mercurial の使い方のチュートリアル』を一読しておけば、日常作業に困る事は無いと思います。しかし、たまにはリポジトリに間違ったコミットをしてしまうものですし、最初は誰でも間違いがちです。そこで間違えたときに打つべきコマンドの覚え書きとして、以下のコマンド入力例を公開します。 ワーキングツリーにカレント・ディレクトリを移動している状態を前提にした操作例なので注意してください。また、各コマンドの詳細なオプションは hg help [コマンド] を見て確認してください。なお、Mercurialはバージョン1.7.3で動作確認しています。 編集を取り消し、あるチェンジセットの状態に戻す コミットをやり直す、コミット・メッセージを変更する チェンジセットを消す チェンジセットを打ち消す チェンジセットを変更する 複数のチェンジセットを一つにまとめる 履歴をさかのぼって特定のファイルを削除す
Mercurial の使い方のチュートリアル このチュートリアルは Mercurial の使い方を紹介します。 SCM ソフトウェアを使うにあたっての特定の予備知識は必要ありません。 あらかじめ Mercurial を理解する を見ておくとよいでしょう はじめに このチュートリアルを読み終われば、次のことが分かるでしょう: Mercurial を使うのに必要な基本的な考えとコマンド ソフトウェアプロジェクトに貢献する際の Mercurial の簡単な使い方 Mercurial のマニュアルページ hg(1) と hgrc(5) に目を通すことを強くお勧めします。 マニュアルページは リリース tarball にも doc/hg.1.html と doc/hgrc.5.html として含まれています。 コマンドラインで hg help <command> とタイプしても良いでしょう。 チュー
前説 DjangoでWebアプリを開発していて自分はJavaScript部分を担当しています。 で、サーバ側を動かさないと開発できないのは辛いので、 サーバサイドで生成されたHTMLとJSONをwgetして、js/dummy/とかに配置し、 各種URLの参照を書き換えてローカルでJavaScriptだけもりもり実装できるようにしました。 サーバサイドの実装に先行してJavaScriptの実装を進めていたため、 プロジェクト全体(django-apps)と独立してバージョン管理したかったため、 static配下だけが入ったdjango-staticというリポジトリを作成し、 そちらで開発を進めていきました。 今回の話は、プロジェクト全体(django-apps)とJavaScript&CSSだけ(django-static)の 二つのリポジトリの同期をとって運用していく話です。 準備 hg
渋日記@shibu.jp 渋川よしきの日記です。ソフトウェア開発とか、ライフハックを中心に記事を書いていきます。 9/29の水曜日に、Atlassian社がBitbucketを買収するというニュースがありました。これにより、今まで有料だったようなサービスが無料で提供されるようになりました。買収したのは、Jiraなどの開発ツールで有名な会社です。とはいえ、Python界隈の人以外にはあまり注目されてこなかったサイトだとは思うので、BitBucketを紹介します。僕はソースコード管理ではメインで使っています。 買収されたBitbucketって何ですか？ Bitbucketは何者か？一言で言えば、Mercurial版のgithubです。以上。 これで分かる方はここの説明はすっとばしてくれて構いません。いわゆる、プロジェクトのホスティングサービスの一つです。ソフトウェア開発に必要な仕組みが備わって
Dropbox が 50 GB プラント 100 GB プランが出てきましたね。愛用どころか Dropbox (S3) に依存しまくりです。 さて、普段開発してるときのリポジトリは mercurial なのですが、Dropbox の上にリポジトリを置いて開発すると保存するたびに履歴が発生するので嬉しくないなぁと思っていたのですが、ローカルで push すればいいという事に気付きました。 spam_main_local のようなリポジトリがローカルにあって、そこで普段を開発して、あるていど落ち着いたら push します。push 先は Dropbox です。spam_main_dropbox というリポジトリを Dropbox 上に作っておいてそこに push します。Dropbox から bitbucket 等の外のリポジトリに定期的に push するといった具合です。こうすることで Dr
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
