2015年7月21日火曜日

ブランチを整理する

プルリクエストを出したブランチがマージされると
リモート側ではfeature/add-forestブランチは削除されますが(管理者次第)
リモートで消えたからといってローカル側が消えるわけではありません。
リモート側でマージされたことを確認したら削除して整理しましょう。
整理せずに置いておくと使わないブランチの山ができて混乱のもとになります。

※今回も、一人ではやりにくい作業なのでマージされた想定で進めていきます。



  • フェッチを行いorigin/master側でマージされていることを確認したら
    プルを行います。
    マージされているかどうかは樹形図を見るとわかりやすいです。
  • プルをする際はmasterブランチに切り替えて行いましょう。
  • プル完了後、マージされて不要になったブランチは削除します。
    今回の場合「feature/add-forest」「origin/feature/add-forest」ブランチを右クリックし
    削除を選択します。

これでgitを利用する際にひと通り必要な基本は抑えられたかと思います。
開発環境によっては、今回と違うアプローチがとられることも十分ありますが
基本はそこまで大きく変わらないと思います。
gitを使うことで、バージョン管理やファイルのマージが便利になるだけではなく
皆で一つのものを作っているんだということが視覚化されて楽しいので
是非、gitをどんどん触って慣れていってもらえればと思います。

慣れてきた頃には他の参考サイトを見てもらえれば更に深く知っていくことができると思います。


また、今回githubを紹介しましたが、githubは基本的に完全オープンな場所なので
関係者以外に見られたくないプロジェクトを扱う場合はプライベートリポジトリを利用しましょう
githubでは有料。bitbucketでは人数制限がつきますが無料で使えます。
その辺りもググれば詳しい情報がいっぱいあるので探してみてください。

プルリクエストを作成する

実際にプルリクエストを出してみましょう。



  • masterブランチを元に新しいブランチを作成する必要がありますが
    まずはmasterブランチをプルして最新の状態に更新します。
  • 更新後、ブランチを作成します。
    ブランチの名前は「このブランチを取り込んだらどうなるかわかりやすい名前」
    をつけましょう。
    例えば、森を追加するブランチなら「add-forest」という名前をつけましょう。
    また、ブランチを整理しやすいようにディレクトリを追加しましょう。
    ブランチ名を「feature/add-forest」という名前にして作成します。
  • すると、featureフォルダに入った状態でブランチが作成されました。
    こうすることでブランチを分類することができます
  • scenario.txtに「まぁ、とりあえず森へ行こう」の一文を追加しコミット、プッシュを行います。
    プッシュはfeature/add-forestブランチだけ行いmasterは除外します
  • するとこのようにorigin側にもorigin/feature/add-forestというブランチが追加されました
  • githubのページを更新するとこのような表示になっていると思います。
    なっていれば右側の「Compare&Pull Request」を選択しましょう
  • プルリクエストの内容が表示されるので確認して問題なければメッセージを作成し
    「Create pull request」を選択します。
  • プルリクエストが作成されると右のPull requestの欄に数字が表示されます
    これはまだマージ及びクローズされていないプルリクエストの数を表しています。
    (クローズとはマージせずにプルリクエストを無効にする操作です)

あとは管理者にプルリクエストのページのURLを一緒に添えてリクエストを出した旨を
伝えてください。
もし、問題が見つかった場合、修正で済む場合は修正を加えて再度プッシュしてください。
その際、プルリクエストは出す必要がありません。
なぜならプルリクエストはブランチの変更内容をまるごと取り込むものなので
同じブランチで修正を行った場合は、その修正もプルリクエストの対象になります。
但し、既にマージ済みのものを修正する場合は新たにブランチを作りプルリクエストを作成してください。

プルリクエストとは?

gitで開発をする際、プルリクエストという機能が使用されることがよくあります。
この機能を使うことで問題の発生するファイル変更を弾くことができるようになったり
マージ作業がやりやすくなったりします。
プルリクエストにはfork式とリポジトリ共有式の2つがあります。
今回は(私の周りでは)よく用いられるリポジトリ共有式について解説します。



  • 今まではmasterブランチを直接弄っていましたが
    通常はmasterは本番データとして扱われ直接弄ることは少ないです。
    もし誤ったデータを上げてしまった場合、本番データが正常に動かなくなる原因になったり
    なかなかハイリスクな感じになります。
  • こういった自体を避けるために各メンバーは作業時に独自のブランチを切り
    そのブランチのみプッシュします。
  • そして、リモートリポジトリの管理者に対してこのブランチの変更内容をプルして
    masterブランチにマージしてほしい。
    というリクエストを出します。これがプルリクエストです。
  • 管理権限を持った人はプルリクエストの内容を見て問題なければマージしますが
    問題がある場合マージせずに差し戻すことができます。
  • そして、マージ自体はいつでも行えるので管理者の都合の良いタイミングで
    行うことができます。

このように柔軟に対応することのできるプルリクエスト機能はよく利用されているので
gitを利用するのであれば是非とも抑えておきたい機能です。
次は実際にプルリクエストを出してみます。



プルする

今回は複数人いないとやりにくい作業なので必ずしも実践しなくても大丈夫です。



  • 他のメンバーがリモートリポジトリに反映した内容を取り込みたい場合は
    上部メニューから「プル」を選択します。
    ※即座に変更を取り込みたくない場合は「フェッチ」を選択します。
    フェッチは変更があるかどうか確認だけを行います。
  • 手動のフェッチや定期で行われる自動フェッチで更新が見つかった場合は
    プルに数字が表示されます。
    そして今度は逆にリモートより1コミット遅れているので「1コミット遅れ」と表示されています
  • 上部メニューから「プル」を選択すると
    このようなウインドウが表示され、どのブランチの変更を取り込むか
    表示されます。origin/masterブランチの内容をmasterブランチに取り込みたいので
    このままOKを押します
  • これでこちらのローカルリポジトリがリモートリポジトリの状況に追い付きました。
    更新があればプルを行いmasterブランチはできるかぎり最新の状態を
    保つようにしましょう。

作業を行う前には必ずプルやフェッチを行いmasterブランチを最新の状態に保つことを
習慣にするようにしましょう。

次のページへ
目次へ

プッシュする

リモートリポジトリを利用する場合、コミットする際にプッシュという操作が必要になります。



  • では何かコミットをしてみましょう。試しに先ほどと同じようにscenario.txtを追加して
    「僕は旅に出ることにした」という内容を追加してコミットをしてみましょう。
    無事にコミットを終えると以前とは若干異なった感じになっていると思います
  • 1コミット先行という文字が出ていますが、これはmasterブランチがorigin/masterに比べて
    1コミット分先行しているという意味になります。
    つまり現時点ではローカル側のリポジトリにだけ変更が加えられている状態で
    リモートリポジトリはまだ変更が加えられていません。
    リモート側にも変更を反映させるには「プッシュ」という操作が必要になります。
    上部メニューから「プッシュ」を選択してください。
  • するとこのようなウインドウが出てくるので変更を反映させたいブランチを選択し
    OKを押してください。今回はmasterブランチを反映させます。
  • OKを押した後にgithubのユーザー名とパスワードを求められると思うので
    入力してください
  • 無事にpushが完了すればorigin/masterブランチもmasterブランチと同じコミットに
    表示されるようになっているはずです
  • github側も同様に変更が反映されていることが確認できます

リモートリポジトリをクローンする

先ほどgithub上に作成したリモートリポジトリが本体になります。
まずは本体のデータをクローンしましょう。



  • SourceTreeの上部メニューの「新規/クローンを作成する」を選択し
    出てきたウインドウに先ほどコピーしたURLをペーストします。
    問題なければリポジトリタイプの欄に「これはGitリポジトリです」と表示されます。
    そして、クローンするリポジトリをどこに保存するかを設定して
    「クローン」を選択してください。
  • 暫く待つとローカルリポジトリを作った時同様の画面になりましたが
    ところどころ異なる部分があります。
    違いとしては
    ・READMEを追加する初期化コミットが入っている
    ・ブランチのタグが「origin/master」と「master」の2つが存在する
    ・リモートにoriginという項目が追加されている
    という部分です。
  • originとはリモートリポジトリのことを指しています。
    「origin/master」がリモートリポジトリのmasterブランチ
    「master」がローカルリポジトリのmasterブランチ
    を指しています。

リモートとローカルと、2つのリポジトリが出てきたややこしいかもしれませんが
本体と自分で別々のリポジトリをもっているというだけなので難しく考えないようにしましょう

アカウントを作成する

githubではまずアカウントを作成する必要があるので作成しましょう。
実際にgithubに触らず、複数人作業の概念だけ知りたい場合は
次のページヘ進んでください



  • https://github.com/
    にアクセスします。
  • Sign Up for github を選択します
  • STEP1にて下記の項目を入力し次へ進みます
    • ユーザー名(重複禁止)
    • メールアドレス
    • パスワード
  • STEP2ではFREEプランが最初から選ばれているので
    そのまま「Finish sign up」を選択します
    ※Help me set up an organization next へのチェックは不要です
  • この画面まできたら、登録は完了です。
    早速「New repository」を選択してリモートリポジトリを作成してみましょう!
  • リポジトリの作成画面に映るので
    リポジトリの名前とリポジトリについての説明を入れ
    「Initialize this repository with a README」にチェックを入れて
    「Create repository」を選択しましょう
  • するとリモートリポジトリが作成されました。
    このリポジトリをクローンする際にこのURLが必要になるのでコピーしましょう

複数人でgitを利用する

複数人でgitを利用するためにはリポジトリを
メンバー全員で共有できる場所に置く必要があります。
共有場所に置かれたリポジトリをリモートリポジトリと呼びます。



リモートリポジトリをメンバーそれぞれがコピー(以下、クローン)して
それぞれがローカルリポジトリを持つ形になります。



そして、それぞれのメンバーが変更内容をリモートリポジトリに反映したり
リモートリポジトリから最新の変更をもらったりして作業を進めていく形になります





リモートリポジトリの置き場所についてですが
今ではgithubやbitbucketといったリモートリポジトリを簡単に管理できる
サービスがありますのでそちらを利用しましょう。
今回はgithubを利用してみます。

次の項目へ
目次へ

2015年7月20日月曜日

ローカルリポジトリを作る



  • 左上にある「新規/クローンを作成する」を選択
  • 「リポジトリを作成」タブを選択
  • 「保存先のパス」にバージョン管理したいフォルダを入力してください。
    フォルダから下の領域はすべて管理対象になります。
    試しに「D:\gittest」という領域を作ってそこを管理対象にしてみます
  • 選択すると名前欄に自動でフォルダの名前が入ります。
    今回はそのままにしますが、名前を変えたい場合は変更してください
  • 「作成」を選択します
  • これでローカルリポジトリが作成されました。
    隠しフォルダが見れる環境であればgittestフォルダに「.git」フォルダができています
    ここにgitの設定やログなどが格納されていきます。
    このフォルダを消すと全てのログや設定が消えてしまうのでここは触らないようにしましょう。



コミットする

ファイルの追加、変更、削除などの作業内容をまとめて記録して残すために
「コミット」という操作を行います。



  • 試しに先ほど作ったgittestフォルダにscenario.txtというファイルを追加して
    「僕はこれから旅に出る...」
    という内容を入力します。
  • すると、SourceTree上でファイルが追加されたことが通知され
    「作業ツリーのファイル」(以下、ワークツリー)に表示されます
  • そして、この追加をコミットに含めるためにscenario.txtを選択し
    「Indexにステージしたファイル」(以下、インデックス)にドラッグ&ドロップします
  • するとファイルがインデックスに移動します。
    ここに表示されているファイルがコミットの対象になります。
    また右側にコミットするファイルの内容が表示されます。
  • コミットするファイルを決めたら上部メニューから「コミット」を選択します
  • すると下部に入力欄が現れるので、どのような変更を行ったか表記します。
    このログは後から見返した時にどのような変更を行ったわかりやすいものを入力しましょう。
    入力が終わったら右下の「コミット」ボタンを選択します
  • 完了後、ブランチ欄に「master」の項目が追加されるので選択します。
  • 選択後、このような画面になり先ほどのファイル追加がコミットとして表示されます。
  • では、更にもう一度コミットをしてみます。
    scenario.txtの内容に次の一文を追加して保存します。
    「まずは森へ向かうことにした」
  • ファイルに変更が加えられると、変更されたがまだコミットされていないファイルがある。
    という表示が追加されます
  • 選択して先ほどと同じようにコミットに含めたいファイルをインデックスに移し
    コミットを選択します。
  • メッセージには「森編を追加」としてコミットしましょう
  • これで、変更履歴が以前と合わせて2つに増えました





変更を破棄する

ファイルに変更を加えたものの
やっぱり無かったことにしたい時に変更内容を破棄して
直前のコミットの状態に戻すことができます。



  • scenario.txtに以下の内容を追記し保存します
    「しかし、僕の冒険は終わりを迎えます」
  • 変更がワークツリーに追加されます
  • 変更を破棄したいファイルを選択し右クリックして
    表示されたメニューから「破棄」を選択します。
    破棄の確認が表示されるのでそのままOKを押しましょう
  • すると、変更内容が破棄されscenario.txtの中身は直前のコミットの状態に戻っています。
    また、変更されるファイルがなくなったことで「変更されていないコミットがあります」の表示
    もなくなりました。

このように気軽に変更を破棄して以前の状態に戻す。
といったことができるのもバージョン管理のメリットです。



昔のコミットに戻す

コミット単位で当時の状況に遡ることができます。




  • 遡りたいコミットを選択してダブルクリックします。
    すると、アラートが表示されるのでクリーンにチェックを入れてOKを押してください。
  • すると、フォルダの中身が最初のコミットの時と同じ状況になり
    「HEAD」という仮のブランチが作成されました。
    ※ブランチについては次の項目で説明します。
  • 移動が確認できたら


このようにコミット単位で好きな時の状況に遡れるので
昔のバージョンを元にして別のバージョンを作りたい。
といったことを手軽に行うことができます。