Webサイトの公開管理方法について

Question

###前提・実現したいこと
更新回数の多いウェブサイトのファイル管理方法について教えて下さい。

###発生している問題・エラーメッセージ
現在使用しているファイルの管理方法は更新したいファイルを「xxx_公開する日付.html」というリネームをしてFTP経由でテストサーバにアップロードし、本番サーバにアップする際に公開する日付をとって「xxx.html」にリネームして公開しています。
これらの作業を複数人で手動でやっているためミスが多いので辞めたいです。
gitを使うという案が出ていますが、前例がないこととgit使用経験がない人が多いため導入が難しいです。また、gitを利用することで日付の異なる日に公開する同一のファイルが複数ある場合は容易になりますでしょうか？

###試したこと
なし

###補足情報(言語/FW/ツール等のバージョンなど)
より詳細な情報

Answer 1

gitじゃなくてもいいですが、バージョン管理ソフトを使いましょう。
バージョン管理ソフトの操作に不慣れな場合、最初はGUIがわかりやすいものがいいでしょうね。

個人的なお勧めとしては、
Windows環境ならMercurialのGUIクライアントTortoiseHgをお勧めします。
Gitと同じ分散バージョン管理ですが、幾分シンプル(Bareリポジトリも不要)なのと、
TortoiseHgをインストールするだけで使え、GUIがよくできているのでお勧め。
デメリットは

• GitHubで管理できない
• Gitに移るときブランチ/Pull/Revertなどの差異にとまどう
• Git程有名じゃない

あたりでしょうか。

GitならGitKrakenかSourceTreeがGUIはわかりやすいですかね。
特にGitKrakenはNode-GitなのでGitクライアントを入れる必要もないと思いますし。
問題は、ユーザー登録（無料です）と最初にインターネット通信が必要なので環境を選びます。
※ ファイルはローカルで管理できます。ユーザー登録の確認に通信が発生します。

画像などのリソースが多いと思うので、SVN(SubVersion)でもいいかなとは思いますが
ブランチがわかりにくい(元来の機能というよりは trunk/branches/tagsを作っとくというほとんど運用ベースなので)気がします。

---

gitを利用することで日付の異なる日に公開する同一のファイルが複数ある場合は容易になりますでしょうか？

今、とても適当にやってみました。画像はTortoiseHgですが、Gitでも同様の事は出来ます。

こんな感じにブランチを使って時に分岐し、時に合流し、こんな更新ツリーができあがっていくイメージです。
default(Gitだとmaster)はリリースしたファイルのみおいておく。
developブランチで開発を進めますが、リリース日毎にブランチ(ForRelease1001/ForRelease1002)を切っておくこともできます。
各々のブランチで更新作業を行うので、同一ファイルに更新が入るときに便利です。
マージ（ブランチの合流）をするとき少し気を付ける(どっちの修正を残すか等)必要がありますが、失敗してすぐならそのマージを削除できるのでやり直せばいいだけです。
画像には含めませんでしたが、使い始めにユーザー名を設定しておくので誰が更新したかもわかります。

---

gitを使うという案が出ていますが、前例がないこととgit使用経験がない人が多いため導入が難しいです

改善は徐々にやっていけばよいので、いきなり全員完璧に使い出すことは目指さず、今よりもよくするために、
まずは最終管理しているファイルを誰か2，3人がバージョン管理ソフトで管理するという運用をスタートしても良いと思います。

バージョン管理ソフトを使えば

• 間違えて書き換えてしまっても前のバージョンに戻せる
• 更新内容の差分が見れる（一般にはテキストファイルの比較。画像などは比較ツールを導入すれば可能かも）

という事はできるので、だめでもすぐにやり直せる環境を用意できるのは大きいと思います。
ブランチも最初はわからなければブランチを使わず、コミットとリビジョンの移動だけ覚えて使い始めるだけでもいいでしょう。
徐々に覚えていけばいいと思います。

MercurialやGitはフォルダ(.hg/.gitを含むフォルダ）を丸ごとコピーしてもバックアップになります。不安なコマンドを試してみたいときは物理的なバックアップをしてから行えばいいでしょう。
（ホントはせっかく分散バージョン管理なんだからCloneしてねと言われるところですが、最初は安心が欲しいと思うので）

また個人的なお勧めですが、diffのツールはWinMergeにすると便利だと思います。

Comments

[退会済みユーザー]

回答ありがとうございます。
git以外のバージョン管理ソフトが色々とあるんですね。おすすめされているTortoiseHgで試してみます。

[flied_onion]

それでは、日本語Windows環境での最初に設定しておいた方が良いことを書いておきます。

インストール後、Explorer上で右クリック＞ユーザー設定

コミット：
ユーザー名に 「User Name <メールアドレス>」 の形式で入力
メールアドレスはユーザーの区別等に使われます。社内でしか使わないなら@以降は適当でも大丈夫。

エクステンション：
※ 必須以外は気が向いたら試す程度で。
win32mbcs － Winで日本語ファイル名(マルチバイト文字)に対応するため(日本語環境なら必須)
strip － コミットした変更をMercurialの管理から削除する
(コミットしてなかったことにする)。
注意はいるが、まだpushしてないコミットを削除できるので便利(任意)
mq ー 紹介記事で出てくることがある便利機能(任意)
rebase ー 紹介記事で出てくることがある便利機能(任意)

以上です。

単純な使い方は、作業対象のフォルダで(ファイルは既にあっても良い)
1. 右クリック＞TortoiseHg＞ここにリポジトリを作成＞「作成」
2. ファイル(htmlとか)をそのディレクトリで普通に作成・編集
3. 右クリック＞Hgワークベンチ
4. コミット表示に切り替え(メニュー下に並んでいるボタンの 緑のチェックマーク(✓ ))
5. コミットしたいファイルにチェック
6. コミットメッセージの入力(右側中段に適当にテキストを入力)
7. 「コミット」ボタンを押す。
8. 「管理下に無いファイルを追加しますか？」が出たら「追加」
--- 最初のコミット（リビジョンの登録）完了

--- ファイルに変更が入るとき
9. ファイルを何か変更するか新しいファイルを追加
10. Hgワークベンチのコミットウィンドウを開く
変更/追加したファイルが見えてなければ
ファイル一覧の右上の更新ボタン押す
11. ファイル選択してメッセージ入れてコミット

--- 前の状態に移動
これまでの作業で Hgワークベンチのグラフで五角形が縦に3つならんでいる。
13. 最初にコミットした時に戻る
リビジョン 0 の五角形を右クリックして Update ＞ [更新]
ファイルの内容が戻っている事を確認
14. ２番目にコミットした時に戻る
リビジョン 1 の五角形を右クリックして Update ＞ [更新]

※ 一番上の五角形は現在作業中のファイルたち（まだコミットしてない）の状態です。
※ コミットしたあと、ファイルを編集したけどまだコミットしてないもの(つまり今のディレクトリの状態)
※ 一番上にあるのは「（将来）コミットしたらそれが最新となるから」ですね。

あとは上記 9,10,11を繰り返すだけです。
（これぐらいだと、Gitでもステージというコミット予約場があるという点以外同じです。）
一人作業（or１カ所でだけ管理）ならこれだけでも十分。

慣れたらPush、CloneとPull、ブランチを覚えると良いでしょう。
その次はマージ。そこまで覚えれば複数人作業するのに十分でしょう。

最後に、Mercurial(Hg)もGitもコミットしたものの変更・削除はできますが、Push(共有とか公開とか考えてください)してしまった分は、共有先と差が生まれて(矛盾して)しまうから通常は禁止されていると覚えておいてください。（そういう場面では警告がでるとおもいます）

長々と失礼しました。

[flied_onion]

↑ 補足：エクステンションはチェックつけるだけで有効化されます。全てのTortoiseHg再起動してと言われたら、ワークベンチなどのTortoiseHgのウィンドウをいったんすべて閉じるだけです。PCの再起動はいりません。

[退会済みユーザー]

ご丁寧に説明いただきありがとうございます。
単純な使い方まではなんとか覚えました。画像のような感じでブランチを作ることができないです。どういった手順で作成されましたでしょうか？

[flied_onion]

Mercurialではブランチは、コミット時に作成します。
コミットメッセージを入力する欄の左上に 「ブランチ: default」というのが表示されていると思いますが、そこをクリックして、「新しくブランチを開始する」にブランチの名前を入れてコミットすれば、そのコミットから新しいブランチになります。

私は慣例的にブランチ作成のコミットは、何もファイルを選択しない状態でコミットメッセージだけ入れて、「ブランチを作成した」だけのコミットにしてます。
どうしてそうするようにしたかソースは忘れましたけど、何かで見たんですよね。ご参考までに。

[flied_onion]

ブランチを作ったら今度はマージですね。
マージはグラフ上のマージしたいリビジョン(五角形)を右クリックして「ローカルにマージ」を選びます。
マージの方向(defaultとブランチAとあって、ブランチAをdefaultにマージするのか、defaultをブランチAにマージするのか）に気を付けてください。
ローカルにマージは、今いるブランチに、選択したブランチ(か分岐したコミット)をマージします。なので先にブランチで起きた変更を取り込みたい側のブランチに移動しておく必要があります。

[flied_onion]

マージするとコンフリクト（衝突）が起こることがあります。
今のブランチとブランチ先で同じファイルが変更されていて、且つ、機械的に両方取り込むことができない(全く同じ行を修正したなど)時です。

Mercurialは差分の積み重ねで管理しているので、ある程度長い行を持つテキストに対して、別の行へ修正していた場合はうまいこと両方生かしてくれます(20行ぐらいのテキストにdefaultで3行目に1行追加、ブランチAで10行目に1行追加した場合、大体の場合は22行に勝手にしてくれます。どちらのブランチでも3行目に追加していたとき、どちらを上にすればいいか判断できないので手動で解決するように求めてきます。)
サンプルで試すような2，3行のテキストだとコンフリクトは起きやすいかもしれません。

コンフリクトが起きたときの解決が最初は一番難しいかもしれませんね。

[flied_onion]

先に上げたstripエクステンションを有効にしている場合、リビジョンを右クリックして「履歴を修正＞除外(strip)」というのが出てきます。
マージで困ったらとりあえずそのマージをコミットしてしまって、完全に失敗だったらその合流したリビジョンを stripしてしまってやり直すのも手です。

注意してほしいのは、stripするとほんとにそのコミット(途中のリビジョンならそれ以降のコミット)は消えます。（本当は少しの間残ってますが、消えてしまうと思っておいた方が良いでしょう）

※ clone、push,pullを始めるとstripですごい消してしまっても他の場所にclone(複製)が残っているので、自分の作業が消える以上の被害はなかったりします。「分散」バージョン管理の利点です。

[flied_onion]

最後に２つ（長々とすいません）、小ネタと言いますか
コミット後、ファイルの修正を始めたが、やっぱり最初から(前回のコミット直後から)やり直したい場合があると思います。
そういう場合は、ワークベンチの変更ファイル一覧で、ファイルを右クリックして「復旧」＞「変更を破棄」とします。

もう一つは、ワークベンチのリポジトリ一覧(左側のリポジトリ一覧。表示されてなければ 表示＞リポジトリ一覧を表示 ）のリポジトリの上で右クリック＞「フォルダを開く」で、そのリポジトリのフォルダがエクスプローラで開きます。
たまに便利です。

[退会済みユーザー]

回答いただきありがとうございます。
ブランチを画像のように作成することができました！
ご紹介いただいた拡張機能はまだ使いこなせそうにありませんが試してみます。stripは便利ですね。
マージする際はコンフリクトに注意ということですね。

リポジトリの作成単位についてすみませんが、質問させてください。
リポジトリを作成する場合は案件ごとに作成するのがいいのか、それともウェブサイトごとに作成するものなのでしょうか？