どうも、無料WordPressテーマ「4536」を個人で開発しているシェフです。
WordPressテーマに限らず、何らかの開発をする上で「管理」は必要不可欠ですが、よくある管理の方法として「日付をファイル名に付与して保存する」というものがあると思います。
- 2019年1月1日に修正したファイルなら「file_ver20190101」
- 2020年8月25日に修正したファイルなら「file_ver20200825」
後は、それをローカルフォルダなりオンラインストレージなりに保存しておけば特段問題なく管理ができます。
…が、このやり方には致命的な問題（欠陥）があります。
それは、不要なファイルまで保存（アップロード）しなければいけないことと、修正箇所（履歴）がわかりづらいことです。
その他にも色々と問題はありますが、この2点はチーム開発はもちろんのこと、個人開発においても致命的な問題と言えます。
ただ、そういった問題を解決してくれる便利なツールがあります。
それが今回ご紹介する「GitHub（ギットハブ）」です。
（GitHubはソースコードやプロジェクトのバージョンを管理する最も有名なツールで、現在はMicrosoftの傘下）
実は、僕もこれまでGitHubのメリットをよく理解してなくて、使い始めたのはつい最近なんですが、これは開発者にとってマストなサービスなんだと強く実感しました。
正直、慣れるまで少し時間がかかると思いますが、導入手順や使い方などを1から紹介するのでぜひ使ってみてください。管理が劇的に楽になるはずです。
※今回はWordPressテーマをGitHubで管理するまでの手順ですが、WordPressプラグインやその他のファイルに関してもやり方は同じです。
GitHubでアカウントとリポジトリを作成する
まずはGitHubのアカウントを作成します。
次に、GitHub上に「リポジトリ」というファイルを管理するスペースを作ります。パソコンでいうフォルダみたいなものですね。
「New」のボタン、もしくは、メニューの「New repository」をクリック。
- Repository name→WordPressテーマやプラグインの名前（例：4536）
- Description→概要など
- 公開範囲→最初はPrivate（非公開）にしておきましょう
- Initialize this repository with a README→リポジトリについての詳しい説明など
- Add a license→ライセンスの種類。詳しくはこちらのページをチェック。英語苦手なら翻訳してみてください
と進めていき、下部の「Create repository」をクリック。
リポジトリを作成したらここでの作業は一旦終了です。「Clone or download」のボタンクリックで表示されるURLは後で使います。
パソコン側にオフラインのリポジトリを作成する
ここまでは特に難しいところもなく進めることができたはずですが、ここから少しだけ難しくなります。
難しいポイントは「コマンド操作」。
Macなら「ターミナル」、Windowsなら「コマンドプロンプト」を使って作業を進めていきます。
（どこにあるのかわからない場合はパソコン上で検索してみてください。どちらも必ず見つかります）
※この記事ではMacのターミナルを使って説明していきます。
フォルダの場所まで移動する
「コマンド操作よくわかんない！」って方にとってはいきなり難しいポイントですが、コマンド操作をする場合、そのフォルダの場所まで移動する必要があります。
例えば、MAMPのようなアプリを使って開発している場合は、アプリケーションフォルダ→MAMPフォルダ…と、階層が深いところまでコマンドを使って移動しなければいけないので、いきなりハマってしまう可能性があります。
ただ、すべての作業をコマンドでやる必要はなく、実はフォルダ移動はドラッグ・アンド・ドロップで簡単にできます。
例えば、MAMPでWordPressのテスト環境を構築していて、GitHubでテーマを管理する場合は以下の手順になります。
- テーマフォルダを開く
- ターミナルを立ち上げて、「cd」と入力。その後に半角スペースを開けておく
- ターミナルにフォルダをドラッグ・アンド・ドロップ
- エンター（Enter）を押す
すると、ターミナルの作業場所がドラッグ・アンド・ドロップしたフォルダになります。
ローカルリポジトリを作成する
先ほど、GitHubでアカウントの作成と同じタイミングでリポジトリ（パソコンでいうところのフォルダみたいなやつ）を作りましたが、このリポジトリはパソコン側にも作る必要があります。
（これもコマンド操作で進めていくので、淡々と進めてください!!）
ここまでの手順でGitHubで管理するフォルダの場所までターミナルで移動しているので、その状態で以下のコマンドを入力します。
git initこれで空のリポジトリが作成されました。
名前やメールアドレスを設定する
GitHubではデフォルトでパソコンの名前（ログインしているユーザー名）とメールアドレスが使われるようになっているので、GitHub用の名前やメールアドレスを設定するのがベターです。
以下のコマンドを使ってそれぞれ設定が可能です。
git config --global user.name 'ここに好きな名前（ニックネームなど）'
git config --global user.email 'ここに好きなメールアドレス'設定内容は以下のコマンドで確認できます。
git config -lローカルリポジトリとリモートリポジトリの状態を同じにする
GitHubの仕組みに通じる話ですが、GitHubではオンラインのリポジトリ（リモートリポジトリ）とオフラインのリポジトリ（ローカルリポジトリ）の2つが存在していて、パソコンで作業した内容をGitHubにあるリモートリポジトリに反映させることでファイルを管理していきます。
つまり、コードを書いていない時はリモートリポジトリとローカルリポジトリの状態は一緒になるわけですね。
（若干ニュアンスは違いますが、とりあえず今はそんな感じに覚えるとわかりやすいと思います!!）
で、初期段階ではどんな状態になっているのかというと、リモートリポジトリには「README」と「ライセンス」の2つのファイルがあり、ローカルリポジトリは空っぽです。
これを同じ状態にするには、以下の手順を踏みます。
GitHubのURLを登録
まず、以下のコマンドでGitHubのリポジトリのリンク（URL）を登録します。
git remote add origin GitHubのリンク※GitHubのリンクは先ほど登場したこのリンクです。
リモートリポジトリのファイルをローカルリポジトリに取り込む
次に、以下のコマンドを入力してローカルリポジトリにリモートリポジトリのファイルを取り込みます。
git pull origin master※READMEのファイルとライセンスのファイルがテーマ内にちゃんとあるか確認してみてくださいね!!
ローカルリポジトリにファイルを追加する
次に、ローカルリポジトリにテーマファイル一式を追加します。
※ローカルリポジトリは仮想空間にあるフォルダみたいなものなので、テーマファイルが一式入っているフォルダとは別物です。（現時点のローカルリポジトリはリモートリポジトリにあった2つのファイルだけが入っている状態）
まずはこちらのコマンドを入力。
git add .次にこちらのコマンドを入力。
git commit -m 'Initial commit'この2つは「すべてのファイルをローカルリポジトリに追加してね〜」ってコマンドです。
※commit -mの後のシングルクォーテーション（またはダブルクォーテーション）の中の文字はなんでもOKで、「不要な部分を削除」や「css update」といった変更内容を記述します。
これでfunctions.phpやらstyle.cssやら、すべてのファイルがローカルリポジトリに追加されました。
ローカルリポジトリの状態をリモートリポジトリに反映させる
最後にローカルリポジトリ（パソコン側にあるリポジトリ）をリモートリポジトリ（GitHub側にあるリポジトリ）に反映させます。
入力するコマンドはこちら。
git push origin masterこれで、テーマファイル一式がGitHubのリポジトリに取り込まれて、ローカルリポジトリとリモートリポジトリの状態（中に入っているファイルなど）が同じになります。
リモートリポジトリを公開する
最初にリポジトリをPrivate（非公開）にしている場合、ログインユーザー以外にはそのページで404エラーが発生してしまうので、ソースコードやファイルを公開する場合はPublic（公開）にします。
公開手順は以下の通り。
アカウントメニューの「settings」をクリックし、下部にある「Make public」をクリック。
入力ボックスにリポジトリの名前（例：4536）を入力して下のボタンをクリック。
管理する
さて、とりあえず一旦お疲れさまでした。けっこう疲れましたよね。
はい、それでは次に進みましょう!!
ここからはどうやって管理するかについて詳しくお話しします。
基本的な管理の流れは以下の通り。
- 作業する（ファイルの修正や追加、削除など）
- その作業内容を「ローカルリポジトリ（パソコン側のリポジトリ）」に反映させる
- 作業内容が反映されたローカルリポジトリを「リモートリポジトリ（GitHub側のリポジトリ）」に反映させる
すべてターミナルのコマンドを使って操作します。
ローカルリポジトリに作業内容を反映
編集作業が一段落したら、その作業内容をローカルリポジトリに反映させます。
使うコマンドは先ほどと同じ「add」です。
例えば、functions.phpを編集したら以下のコマンドを入力します。
git add functions.php（ターミナルにはaddされたことは表示されませんが、内部では進行しています）
ただ、このやり方は正直面倒なので、ファイル一式追加した時のように以下のコマンドを使うのが便利です。
git add .変更箇所がないファイルに関しては何もせずに、変更されたファイルだけを対象にaddしてくれるので特に問題ありません。
で、その後に以下のコマンドを入力。
git commit -m 'update'初期設定の時にも登場したコマンドですね。
ここでは例として「update」としていますが、「CSSの不要な部分を削除しました」とか「add single.php」にしても大丈夫です。
リモートリポジトリに作業内容を反映
ローカルリポジトリに作業内容が反映されたので、後はそのローカルリポジトリの状態をリモートリポジトリに反映させるだけです。
使うのは先ほども登場したこちらのコマンド。
git push origin masterこれで完了です。
管理の時に使う基本的なコマンド
- git add→ファイルを追加するための準備みたいなやつ
- git commit -m ‘変更内容’→addされたファイルをローカルリポジトリに追加する
- git push origin master→現在のローカルリポジトリの状態をリモートリポジトリに反映する
最低限これだけ覚えていれば大丈夫です。
この3つのコマンドだけでファイルを管理することも十分可能です。
タグをつけてバージョン管理をする
バージョン管理だけのためにGitHubを使う人もいるくらい、GitHubはバージョン管理が簡単です。
やり方は超シンプルで、タグを作ってそれをリモートリポジトリに反映させるだけ。
これだけで、
- 前のバージョンから現在のバージョンまでのリモートリポジトリの変更履歴の保存
- ファイルの圧縮（zip形式とtar.gz形式）
を自動でやってくれます。
つまり、「よし、これでリリース（公開）しても大丈夫だな」というタイミングでタグを付けるだけでバージョン管理ができるわけですね。
あなたも過去のバージョンを確認できますし、他のユーザーも好きなように過去のバージョンに戻せるようになります。
タグの作り方
まずはローカルリポジトリでタグを作ります。
使うコマンドは「tag」で、例えば、1.0.0というタグを作る場合は以下のコマンドになります。
git tag 1.0.0※ターミナルに特に動きはありません。
タグをリモートリポジトリに反映させる
後は作ったタグをリモートリポジトリに反映させるだけです。
使うコマンドは「push」で先ほどの1.0.0のタグを反映させる場合は以下のコマンドになります。
git push origin 1.0.0これで現在のリモートリポジトリの状態が保存されたバージョン1.0.0のファイルが完成しました!!
タグを削除する
このタグは削除できます。
例えば、1.0.0のタグを削除したい場合は以下のコマンドを入力します。
git tag -d 1.0.0これでローカルリポジトリのタグが削除されたので、後はリモートリポジトリからも同じタグを削除します。
git push --delete origin 1.0.0ローカルリポジトリにあるすべてのタグはgit tagで確認できるので、タグが追加されたか削除されたかなどの確認に使ってみてください。
また、リモートリポジトリのタグはreleaseタブから確認できます。
開発用の環境を構築する
誰に見せる予定でもなく、ファイルを配布するつもりもなく、そもそもリポジトリの状態がプライベート（非公開）になっている…なんて場合はこの項目はスルーしてもOKですが、ファイル配布やソースコード公開などの理由でリポジトリの状態をパブリックにする（公開する）のであれば「開発用の環境」を構築するのがベターです。
リモートリポジトリに反映させる時に以下のコマンドを使っていたことを覚えていますか？
git push origin masterこれは、現在のローカルリポジトリの状態を、リモートリポジトリ（origin）の中にある、「master」というブランチ（分岐点）に反映させるという意味なんですが、実はGitHubではリポジトリの中にいくつもの「分岐点」を作成することができます。
※ブランチについてはこちらのページに図解があるのでぜひチェックしてみてください。
この分岐点がデフォルトでは1つ用意されていて、それが先ほどの「master」という名前になっています。
で、分岐点が1つしかないとどんな問題があるのかといういと、すべての作業内容や変更履歴がこのmasterブランチに反映されるので、開発中のファイルはすべてローカルリポジトリだけで管理しなければいけないんですね。
なぜなら、リモートリポジトリ（のmasterブランチ）に反映するとそれが最終的なファイルになるので、ダウンロードしたファイルの中身もソースコードもすべてそのファイルのものになるからです。
まあ、個人開発であれば「これでリリースできるぞ！完璧！」というタイミングにだけリモートリポジトリに反映させるのも良いかと思いますが、GitHubのリモートリポジトリに反映させて管理した方が色々と便利ですし（ソースコードがどこでも確認できるとか、別のパソコンでも管理できるとか）、チーム開発を想定して作業するのも良いかと思います。
さて。先ほど開発用の環境を構築するのがベターと言いましたが、正確には「開発用の分岐点」を作るのがベターという意味になります。
要は、開発中の作業内容はすべて専用の分岐点（ブランチ）に反映させるということですね。
管理の流れとしては以下のようになります。
- 作業する（ファイルの修正や追加、削除など）
- 【※初回だけ】ローカルリポジトリに開発用ブランチ（例：development）を作る
- 開発用ブランチに移動する
- ローカルリポジトリの開発用ブランチに反映させる（add、commit）
- 4のローカルリポジトリの状態をリモートリポジトリに反映させる（push）
- 【※必要な時だけ】開発用ブランチをmasterブランチに反映させる（詳細は後述）
補足：これまではリモートリポジトリとローカルリポジトリの中にはmasterブランチしかありませんでしたが、開発用のブランチを作ることで、どちらのリポジトリも中に「masterブランチ」と「開発用ブランチ」の２つのブランチが存在することになります。
開発用ブランチを作る
まずは開発用ブランチを作ります。これは初回だけで次回以降は必要ありません。
ブランチを作るコマンドは「branch」で、例えば「development」というブランチを作る場合は以下のコマンドになります。
git branch development※ターミナルに特に動きはありません。
開発用ブランチに移動する
ブランチを作ったら、次はそのブランチに移動します。
移動コマンドは「checkout」で、今回の例だと以下のコマンドになります。
git checkout development※ちゃんと移動できると「Switched to branch ‘development’」というメッセージが表示されます。
ローカルリポジトリの開発用ブランチに作業内容を反映させる
作業が一段落したらローカルリポジトリに反映させましょう。
使うコマンドはこれまでと同じ「add」と「commit」です。
git add .その後に、
git commit -m 'update'で反映されます。
リモートリポジトリに開発用ブランチの状態を反映させる
最後に、pushコマンドでリモートリポジトリに反映させるんですが、現在作業しているのは開発用ブランチである「development」なので、コマンドは以下のようになります。
git push origin development※補足：リモートリポジトリ（origin）に開発用ブランチ（development）の状態を反映させる（push）という意味です。
これで開発用ブランチで管理する環境が構築できましたね!!
今後は、作業内容を反映させたい時にaddしてcommit。そして、pushするだけで開発用の履歴が残ります。
ブランチは自分で移動しない限りは最後にいた場所が保持されるので、毎回masterブランチから開発用ブランチに切り替える必要はありません。
開発用ブランチの内容をmasterブランチに反映させる
開発が一段落して「よし、この内容でリリース（公開）しよう！」というタイミングで、開発用ブランチの内容をmasterブランチに反映させます。
使うのは「merge」というコマンドです。
まず、開発用ブランチに切り替えている時は、masterブランチに切り替えてください。
git checkout master※checkoutコマンドでブランチを切り替えた後はその状態が保持されます。
次にmasterブランチに開発用ブランチ（例：development）を反映させます。2つのブランチを統合させるイメージですね。
git merge development後は、pushコマンドでリモートリポジトリのmasterブランチにローカルリポジトリのmasterブランチの状態を反映させます。
git push origin masterこれで開発用ブランチにあったファイルや変更履歴がmasterブランチにも反映されました!!
便利なGitコマンド
Gitコマンドをすべて覚えるのは大変なので、最初は「add」「commit」「push」など、必要最低限なコマンドだけ覚えておけばいいですが、1つだけ便利なコマンドがあります。
それは「status」というコマンド。
git statusステータスという名前の通り、現在のリポジトリの状態を表示してくれるんですが、それだけにとどまらず、次に何をすればいいのか（どのコマンドを使えばいいのか）といったことも教えてくれるんです。
いくつか例を挙げますが、本当に便利なのでGoogle検索の次くらいに活用してみてください。
例：何も作業していない時
ファイルの編集や追加・削除など、何も作業していない時にこのコマンドを入力すると以下のメッセージが表示されます。
On branch master
nothing to commit, working tree clean【意訳】今はmasterブランチ（デフォルトのブランチ）にいるよ〜、変更がないから何もしなくていいよ〜
例：ファイルを編集した時
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: archive-movie.php【意訳】archive-movie.phpが編集されたよ〜。ローカルリポジトリに反映するファイルならgit add archive-movie.phpと入力してね〜。変更内容を破棄するならgit checkout archive-movie.phpと入力してね〜
【補足】ここでaddコマンドを使うとcommitする準備完了。checkoutコマンドを使うと編集前の状態になります。
まとめ
GitHubは絶対使わなければいけないツールではありませんが、使うことで「開発の質」は間違いなく向上します。
少し前から無料プランでもリポジトリを非公開にできるようになったので、有料のWordPressテーマやプラグインなどを開発している人もGitHubで管理してみてはいかがでしょうか？
GitHub導入にあたり超参考になったページ→https://qiita.com/nnahito/items/565f8755e70c51532459
