Clever Geek Handbook

Hg Init：パート3.チームでの作業に慣れる

これは、 Hg Initシリーズの3回目の記事であるJoel Spolsky Mercurial Tutorialです。 前のパーツ：





Mercurialを使用する利点の1つは、1つのコードでチームとして作業できることです。 Mercurialを使用すると、全員が独立して作業でき、加えられた変更を統合できます。



パート3.チームでの作業に慣れる







Mercurialを使用する場合、チームメンバーのコンピューターにある個人リポジトリに加えて、中央リポジトリを設定するのが一般的です。 中央リポジトリは、一種のフリーマーケット、つまり、彼らが出会い、やり取りしたことを交換する場所として見ることができます。











最も簡単な方法は、Mercurialの組み込みWebサーバーを使用して中央リポジトリを作成することです。 必要なのは、 hg init



を使用してリポジトリを作成し、 hg serve



を使用してhg serve



アクセスすることだけです。 デフォルトでは、リポジトリはポート8000​​で使用できます。







hg serve





Webサーバーを起動し、現在のリポジトリをインターネットで利用できるようにします。





サーバーはjoel.example.comで実行されているので 、ブラウザーでjoel.example.com:8000を開くと、サーバーが機能していることがわかりますが、リポジトリは完全に空です。







中央Webサーバーを実行している状態で、個人用に中央リポジトリをサーバーからコンピューターに複製できます。 リポジトリは現在空です。つまり、複製の結果として別の空のリポジトリが取得されます。







hg clone





リポジトリ全体の完全なコピーを作成します。





ここで、有名なワカモレのレシピを書き留めるグアックファイルを作成します。







このファイルをリポジトリに追加してコミットします。 これが最初の公式バージョンになります：







コミットについてコメントを書きます。







ファイルをすばやく編集し、1つの小さな変更を加えて、少なくともリポジトリの変更履歴を少しだけ残します。







そして、変更をコミットします。







今回コミットしたときに、以前は実行しなかった-m



引数を使用したことに注意してください。 これは、コマンドラインでコミットに関するコメントを指定するだけで、エディターは使用しません。



いいですね、何がありますか？ 現在、私は中央リポジトリとこのリポジトリの個人的なクローンを持っています。 2つの変更を加えてコミットしましたが、これらの変更はクローンに保存されます。 これらはまだ中央リポジトリにありません。 したがって、次のようになります。







次に、 hg push



コマンドを使用します。これにより、ローカルから中央のリポジトリに変更がプッシュされます。



hg push





現在のリポジトリから中央のリポジトリに新しい変更をプッシュします。









まあ、素晴らしい。 これが機能しないことは明らかです。 誰もが愚かな変更をプッシュする許可を得て、ある種のWebサーバーを起動することのセキュリティと結果については考えたくありません。 少し我慢してください。誰でも何でもできるようにサーバーを設定します。 サーバー上の.hg \ hgrcファイルを編集する必要があります。







言うまでもなく、これは安全ではありません。 しかし、職場の安全なLANにいて、優れたファイアウォールがあり、ネットワーク内の全員を信頼している場合は、これを行うことができます。 それ以外の場合は、セキュリティ設定について読む必要があります。



さて、サーバーを再起動するときです。







これで、変更をプッシュできるようになります。







うん！ これですべてが次のようになります。







あなたの考えを知っています。 「主よ、ジョエル、これはすべて奇妙です。 リポジトリにファイルではなく 変更が含まれているのはなぜですか？ そのグアックファイルはどこにありますか？」



ええ、それは奇妙です。 しかし、分散バージョン管理も同様です。 リポジトリは、単に大量の変更を保存するだけです。 1つの変更は、部分的に透明な素材のシートのようなものだと想像してください。 そのようなシートのパックがあり、最新の変更が上になるようにそれらを積み重ねて、次にこのパックを上から下に見て、それから-はい、はい、はい！ -ファイルの現在のバージョンが表示されます。 スタックの最上部から一度に1つずつシートを削除すると、ファイルの以前のバージョンがますます表示されます。



ブラウザを使用して、中央リポジトリをもう一度見てみましょう。







まさに期待されていたものがあります。



次に、Roseに電話して、レシピの作成を支援します。 テスターチームのローザ。 誰もがベガスで見られるおばあちゃんの1つに似ていることを確認し、「片腕の盗賊」の前​​に顎を垂らして何時間も座って、切望されたスロットにコインを次々と投げます。 すべての違いは、Roseプログラムがテストしていることです。 彼女にプログラムの新しいバージョンを提供すると、彼女は23のLinuxディストリビューションでテストします。 それぞれ順番に確認してください。 感情を見せずに、不必要な動きをせずに。 Ubuntu Linuxのトルコ語版でドットiが欠落していることを通知するためだけに停止します。 ローズは素晴らしいテストをしますが、私は彼女が時々ゾンビのように振る舞うことを誓います。







Rosaは、 hg clone



コマンドを使用して、リポジトリの完全なコピーを作成しました。 hg clone



は、リポジトリURLとクローンを作成するディレクトリの名前の2つの引数を受け入れます。 ローザは彼女自身のレシピカタログを持っています 。







hg log



を実行すると、ストーリー全体が表示されることに注意してください。 つまり、Rosaは、すでに発生したすべての履歴を含むリポジトリ全体をダウンロードしました。



これで、Roseは変更を加えてリポジトリに反映します。







ここでコミットします。 サーバーがダウンしていても機能することに注意してください。コミットはマシンで完全に実行されます。







ローズが彼女の変更を行っている間に、私も何かをしました。







変更をコミットすると、ログ番号2がRosaとは異なることが示されることが明らかになります。







リポジトリ内のストーリーは異なってきました。







心配する必要はありません。これらの変更をすべてまとめて、チップとハバネロコショウを使ったおいしいおやつを手に入れる方法がまもなくわかります。



Roseは、サーバーに接続せずに機能し続け、必要なだけ変更を加えることができます。 彼女はリポジトリへの変更をコミットまたはロールバックできます。 ただし、変更を他の人と共有することを決定するときが来るでしょう。 彼女はhg outgoing



コマンドを実行し、中央リポジトリへの送信を待機している変更のリストを表示できます。 これらは、 hg push



実行されたときに送信される変更です。







hg outgoing





現在のリポジトリで送信を待っている変更のリストを表示します。





hg outgoing



は、中央リポジトリにない現在のリポジトリ内のすべてのそのような変更の単なるリストです。



さて、ここでローザは彼女の変更を中央リポジトリにプッシュします。







そして今、このようになります：







今日は4杯目のラテを飲みに行った後、ポテトチップスに関する変更をプッシュする準備ができました。







AAAAA !!! エラー！ ああ、ところで、メッセージが表示されますか？ -fスイッチを使用してプッシュを強制する （push -fを使用して強制する）と言うものですか？ これはひどいアドバイスです。 -fスイッチを使用しないでください。 あなたはそれを使用して後悔するでしょう。 ただ私を信じてください。



ローザが何とか変更を押し進めた理由は、ポテトチップスとワカモレがうまく混ざらないためです。 冗談です、冗談です！ 私はあなたがそこにまだ眠りに落ちていないことを確認したかっただけです。



チームが変更を加えたため、チームはエラーで終了しました。つまり、それらを一緒にマージする必要があり、Mercurialはそれを知っています。



まず、まだ統合していない中央リポジトリからすべての変更を削除します。







+1ヘッド（+1ヘッド）についてはちらつきがあります。 これは、3つの変更がきちんとレイアウトされた私のリポジトリが双頭モンスターになったためです。 リポジトリの上部には、2つの異なる変更が危険な場所にあります。 これは次のようなものです。







現在、リポジトリには両方のバージョンがあります。 これが私のものです：







そして、これがRoseバージョンです。







そして、これらのバージョンをマージする必要があります。 幸いなことに、これは簡単です。







見て！ hg merge



チームは、両方の「ヘッド」（リポジトリの上部の変更）を1つにまとめました。 この場合、Rosaと私はファイルのさまざまな部分を変更したため、マージ中に競合は発生せず、すべてがスムーズに進みました。



hg merge





2つの「目標」の合併（関連付け）を生成します。





私はまだコミットする必要があります。 これは重要です。 合併が失敗した場合、いつでもロールバックして再試行できます。 しかし、合併が成功したので、コミットします。 その後、変更を中央リポジトリにプッシュできます。







中央リポジトリは私のものと同じです：







さて、Rosaの変更と私自身の変更がありますが、Rosaにはまだ変更がありません。



ローザに関連するもう1つのポイントがあります。 彼女は医者です。 うん、医者である医者。 それは素晴らしいことではありませんか？ 彼女は山の主な小児科医でした。 シナイはおそらく「この不潔なバカがテスターに​​支払う金額の5倍以上」を受け取った。 なぜ彼女が薬を残したのかは誰にもわかりません。 残りのテスターは、悲劇的なことが起こったと考えています。 彼女には家族もいました。彼女のテーブルにはかわいいプレティーンの写真があります。 しかし、今では彼女は一人暮らしで、私たちは彼女の魂に入りたくありません。



Roseは、変更を取得するために、リポジトリから新しい受信変更をプルする必要があります。







できた さて、あなたには奇妙に思えるかもしれませんが、Roseが新しい変更をリポジトリにプルしたにもかかわらず、 これらの変更は作業ディレクトリにはありません 。







彼女はまだコーンチップで働いています 。 コーンチップ付き！



彼女はリポジトリのどこかに私の最新の変更を加えています...







私の変更が彼女の作業ディレクトリにないというだけです。 これは、彼女がまだ2番目の変更セットを変更しているためです。 これは、 hg parent



コマンドを実行することで確認できます。







hg parent





作業ディレクトリにある一連の変更を表示します。





Mercurialは私たちに親切です。 変更をプルすることは常に安全です。 起こるすべては、他の人によって行われた新鮮な変更を得ることです。 これらの変更は、都合の良いときに後で作業を開始できます。



引数なしのhg up



コマンドは、作業ディレクトリを「ヒント」に導く、つまり、すべての変更を最上部の変更セットに適用することにhg up



ください。 この場合、これは4番目の変更セットです。







これで、Rosaは私たち両方からの変更を含む最新バージョンを見ることができます。



チームで作業する場合、ワークフローは次のようになります。

  1. 長期間これを行っていない場合は、誰もが使用する最新バージョンを選択してください。

    • hg pull
    • Hg up


  2. 変更を加える
  3. 変更のコミット（ローカル）
  4. 他のすべてのユーザーにダンプする適切なコードを取得するまで、手順2〜3を繰り返します。
  5. 共有する準備ができたら、次の操作を行います。

    • 他の人の変更を取得するためのhg pull（もしあれば）
    • hg mergeは、これらの変更をあなたの
    • テスト！ 合併中に何も損なわれないようにするため
    • hg commit（マージ結果を修正するため）
    • hg push






自分でテストする




現時点でできることは次のとおりです。

  1. 中央リポジトリを設定し、チームメンバーにクローンを作成する機能を提供します
  2. 変更を中央リポジトリにプッシュする
  3. 中央リポジトリから変更をプル
  4. 異なる著者からの変更をマージする




ここに続きます：

Hg Init：パート4.バグ修正


More articles:


All Articles