ローカルホスト + Mercurial でソース管理を操作する基本ロジック

Question

私は Mercurial に関してはかなり初心者で、実際にはソース管理も初めてです。

localhost (~/mamp/htdocs) にプロジェクトがあります。全て地元で働きたい。私が混乱している点があります:

htdocs とは別のパスにリポジトリを保持する必要があると思うので、「/reps/」フォルダーを作成し、その下にプロジェクトごとにフォルダーを作成し、htdocs プロジェクトフォルダーからすべてのファイルを reps にコピーします。

例えば;プロジェクト01

からファイルをコピーする ~/mamp/htdocs/project01/ に /reps/project01/

ただし、ファイルの変更などのためにローカルホスト（htdocs）で作業します。では、これらの変更をどのように関連付ければよいでしょうか /reps/?

明らかに、ソース管理に関する非常に明白な点が欠けています。スタートを間違えたのでしょうか？

オンラインで見つけたチュートリアルはどれも、何らかの基礎知識が必要だと思います。それらのどれも、意味がゼロ点からは何も言えません。:/

Answer 1

最も簡単な方法は、ファイルを編集する場合です。 ~/mamp/htdocs/project01/ (実稼働サーバーに変更をデプロイする前に変更をテストできる、ある種のステージング領域があれば良いという意見にも私は同意しますが、おそらく、それはまさにあなたのマシンがステージング領域なので、すべて問題ありません:- )) は次のことを行います。

1. Mercurial をインストールする
2. cd ~/mamp/htdocs/project01/
3. hg init
4. hg add *.html subdir *.css (管理したいものは何でも)
5. hg commit -m"initial version"

終わった後 hg init, にリポジトリがあります。 .hg 下のディレクトリ ~/mamp/htdocs/project01/ ！hg ではこれを (少なくとも) 回避することはできません。project01 にソースがある場合は、project01 にリポジトリが必要です。ファイルを変更するたびに、それをコミットして、何を行ったかをシステムに伝えるログ メッセージを与えるだけでバージョン管理の恩恵を受けることができるので、これで十分です。

• <edit> a.html
• hg status (現在変更されているファイルが表示されます)
• hg diff (保存したバージョンとの違いを説明します)
• hg commit -m"what-has-changed-message" (新しいバージョンを保存します)

別の場所 (/reps など) に別のリポジトリを持つ必要がない場合でも、 をしたい, たとえば、バックアップされたゾーンにデータを置く場合は、$HOME にあるゾーンのクローンを作成するだけです。

• cd /reps
• hg clone /home/name/mamp/htdocs/project01/ project01

どっちが入るのか /reps/project01 あなたが行ったことの正確なコピー:すべての変更とすべてのログ メッセージ。今、そうすれば、いつでも "hg commit" プライマリ リポジトリに変更を保存するには、次のことも行う必要があります。 "cd /reps/project01" そして "hg pull" 同期を維持したい場合は、変更を /reps に転送します。

十分にシンプルであることを願っています..

Answer 2

がある 多くの異なるアプローチ/方法. 。私の仕事のやり方は次のとおりです。

1. 発達： ファイルを「開発環境」にチェックアウト（mercurials の場合はクローン）して作業し、コミット/プッシュなどを行います。同じ場所で。

2. 次の段階: ユーザーテスト、実稼働、または次の段階の準備ができたと思われる場合は、コードを

   2a.パッケージ (最新ファイルの単純な zip である可能性があります) または

   2b.それらを次の段階のディレクトリにチェックアウトします。

3. その他の用途: 主な使用シナリオに慣れてきたら、他のシナリオを検討する必要があります。 リビジョン管理の使用例 タグ付け, 分岐する そして 結合する

Answer 3

通常、VCS (バージョン管理システム) とそのファイルは実稼働 Web サーバー環境とは別に保管する必要があります (htdocs について言及していることから、これについて質問しているのではないかと推測されます)。

多くの (少なくとも古い) Web システムには、ソース システムからマテリアルをコピーするステージング領域があり、2 番目の (一般公開されていない) Web サーバーを使用して注意深くチェックできます。コードが正しいと確信できたら、それを実稼働環境に移行できます。

このシナリオには 3 つの領域があります。

• VCS などによる作業 (開発) 領域。おそらくさらに別の Web サーバー経由でアクセスできる可能性があります)。
• ステージング領域 (VCS なし、パブリック アクセスなし。テストと検証)。
• 実稼働エリア (VCS なし、パブリック アクセス)。

これら 3 つを混同しているように聞こえますが、これは私の限られた経験ではよくあるシナリオです。ステージング領域を使用しないことに決めた場合でも、開発システムと運用システムを分離する必要があります。また、作業領域にはVCS（Mercurial）が使用されています。