Cloud9ワークスペースをGitでバージョン管理しよう

Linux環境をAmazonさんからお借りしているのですからよく考えたら当たり前ですよね。サクッと環境構築できてさらにバージョン管理までできるってどれだけ便利な世の中なんでしょう。

準備

• Cloud9にワークスペースを作っておきます。中にすでに何かのプロジェクトがあっても構いません。
• GitHubアカウントを作成しておいてください。

ローカルリポジトリの作成

Gitを使ってバージョン管理をはじめるためにローカルリポジトリの作成と初期化を行います。ローカルとは言うものの当然PC上ではなくワークスペース内のお話です。

cd やcd ~などで左側のツリー上で最も上に表示されているフォルダ(ルートディレクトリ)に移動します。移動できるならどのコマンドでもOKです。

git init

作成できたら(master)と表示されます。｢いまgit上ではmasterという名前のブランチにいますよ｣という意味です。

リポジトリとは

リポジトリ(レポジトリ Repository)とは、ファイルやディレクトリの状態を記録する場所です。後述するコマンドでファイルの内容やフォルダ構成、変更された箇所などが自動的に保存されます。保存されたこれらの情報は履歴として残り、あとから確認することができます。

ブランチとは

Gitは履歴を枝分かれさせて記録することができます。例えば複数人で開発をしている際、追加している機能ごとにバージョン管理できたら便利だとおもいませんか？ブランチを切っていればそれが可能です。 身構えてしまいますが実は既にブランチを使っています。｢master｣というブランチです。Gitのリポジトリを作成すると自動で作られます。プロジェクトの中で最も安定したバージョン、主たるバージョンの役割が与えられることが多いです。(カオスなプロジェクトは例外です。)

コミット対象になるファイルを確認

ルートディレクトリの中でGit管理対象になるファイルを確認します。

git status

すると下記のように表示されるかと思います、

On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        README.md
        ……

nothing added to commit but untracked files present (use "git add" to track)

すでに他のプロジェクトが入っているワークスペースは｢Untracked files:｣のあとにズラッとファイル名が並ぶはずです。

ローカルリポジトリにファイルを追加

git add .

addコマンドのあとに｢.｣を指定するとルートディレクトリ以下のフォルダ・ファイル全て、つまりワークスペース上のファイル全てがGit管理下におかれます。 (実はアスタリスク(*)でも行けます、慣例的にこっちを使ってます。)

git add README.md

ファイル名を指定することで特定のファイルのみをGit管理下におくことも可能です。

ローカルリポジトリをコミットする

ここでgit statusでローカルリポジトリの状況を確認すると

No commits yet

(中略)
   new file:   README.md

となっているかと思います。 まだコミットされていませんよ、と言われているのでローカルリポジトリに正式にファイルを登録します。

git commit -m "はじめてのコミット"

git commitだけでもコミットできるのですが、あとでコミット履歴を見返した時に一行一行履歴を開いてコードを一つ一つ見ないと何を修正したのかわからなくなります。それを避けるため-mオプションと続けてコメント内容を書くことでわかりやすくしています。

コミットが成功したところでgit statusで確認してみると

nothing to commit, working tree clean

ローカルリポジトリの中にコミット対象のファイルはない……先ほどのコミット以後変更されたファイルはありませんよと教えてもらえます。

GitHubリポジトリを作成

Cloud9ワークスペースのファイル管理からは一旦離れて、GitHubアカウント上にリポジトリを作ります。

Webブラウザに移動してGitHubアカウントにアクセスします。 右上の+ボタンを押して｢New repository｣を選びます。

必須項目はRepository nameのみです。 必要であればリポジトリを公開するか(Public)非公開にするか(Private)を選択して、Create Repositoryを押します。

最近GitHubの無償アカウントでもプライベートリポジトリが無制限に作れるようになりましたので、余計な心配をしなくて済みます。(共同編集者は最大3名までですが個人の開発には問題ないでしょう。)

リポジトリを作成すると［HTTPS | SSH］トグルボタンの右にURLが表示されています。このURLはCloud9で必要ですので右端のコピーボタンを押してクリップボードにコピーしておきます。もちろん、あとから該当リポジトリページにアクセスして確認することもできます。

ローカルリポジトリにリモートリポジトリを登録

ローカルリポジトリはCloud9側で作ったリポジトリ、リモートリポジトリはGitHubアカウント上に作ったリポジトリです。

ローカルリポジトリにおいて、リモートリポジトリを｢origin｣という名前で登録します。

git remote add origin 先ほどのURL

｢先ほどのURL｣と書いてある箇所にGitHubでコピーしたURLを貼り付けます。

(originは慣例です。好きな名前を付けていいですが、多くのGit解説本や記事にはoriginで書いてあると思います。最初のうちはわけがわからなくなるのでoriginを採用しましょう。)

ローカルリポジトリからリモートリポジトリへソースをプッシュ

カタカナばっかじゃん、ルー大柴かよ。 いよいよローカルリポジトリでコミットしたファイルをリモートリポジトリへアップロードします。

git push アップロード先のリモートリポジトリ名 ローカルブランチ名

つまりこうなります。

git push origin master

originはリポジトリなのにローカルはブランチ名？ 一瞬ちぐはぐに見えたのは私だけでしょうか？

ブランチの解説を思い出してください。リポジトリを作成した時点でmasterブランチが作られるんでしたよね。

Gitは上流リポジトリ(この場合GitHub上のリモートリポジトリ)のうち指定がなければ同名のブランチにプッシュするようです。 もし同名ブランチがなければ勝手にリモートリポジトリに作成されます。

pushコマンドにリモートブランチを指定するオプションをつけることもできます。

git push リモートリポジトリ名 ローカルブランチ名:リモートブランチ名

Cloud９でワークスペースを作って実験するだけならあまり出番はないのかなと思います。

　まとめ

git push の後ファイルの修正をして再度リモートリポジトリに反映する方法も一緒です...... とか端折ってはいけないので追記するか別の記事に書く予定です。

Git環境を構築して、Angularの勉強をされる方はCloud9上にAngular環境を構築する方法を載せているのでぜひご覧ください。