1_git_tutorial.md

Git

ファイルのバージョン（リビジョン）を管理してくる仕組みの１つ。
他にはsubversionとかがある。
github や bitbucket は git にソーシャルな仕組みを付け加えたサービス名を指す。

簡単に仕組みを

バージョン管理したいフォルダ（リポジトリ）がローカルPCとクラウドの両方にある感じ。
それらをうまいこと同期させたり枝分けさせたりできる感じ。

例）

1. AさんとBさんのローカルに同じファイルがある状態
2. Aさんがローカルでファイルを修正
3. Bさんがローカルで別のファイルを修正
4. Aさんが修正をクラウド（リモート）に送信（push）
5. Bさんがリモートのファイルを受信（pull）
6. Bさんのローカルでは自分の修正しているものにAさんの修正が加わった状態

正直パっとはわかりにくいけど、
誰がどこを修正しても push / pull の動きだけで常に同期できる。

準備

Git入ってますか？

win: コマンドプロンプト起動してgit --versionを叩いてみる
mac: ターミナル起動してgit --versionを叩いてみる

C:\Users\a_shimada> git --version
git version 1.9.5.msysgit.0

こんな感じの結果が返ってくればインストールさてれいる

ローカルPCで使えるようにする

インストールされてなかったら以下からインストール

https://git-scm.com/downloads

winならtortoisegit(とーたすぎっと)を入れると割りとGUIで操作できるっぽい
https://code.google.com/p/tortoisegit/wiki/Download

リポジトリ操作してみる

多分GUIあるけど、詳しくないのと
細かい操作は出来なそうなのでコマンドでの操作方法をつらつら書く。

0. リモートリポジトリの作成 bitbucketとかで非公開の新規リポジトリ作成
   リポジトリURL:https://bitbucket.org/[username]/[リポジトリ名].git

1. ローカルにバージョン管理させるフォルダ・ファイルを作る
   コマンドプロンプト / ターミナル　でそのディレクトリまでいく

[shimada🐱 shimada-no-MacBook-Air]
     >>> [workspace2] $ mkdir gittest
[shimada🐱 shimada-no-MacBook-Air]
     >>> [workspace2] $ cd gittest/
[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ vim test.html
[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ ll
total 8
drwxr-xr-x   3 shimada  staff  102  8 11 20:48 ./
drwxr-xr-x  10 shimada  staff  340  8 11 20:47 ../
-rw-r--r--   1 shimada  staff   48  8 11 20:48 test.html

2. このディレクトリをgitで管理するよ宣言（git init）

[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ git init
Initialized empty Git repository in /Users/shimada/Documents/workspace2/gittest/.git/

3. まだローカルにしかファイルがないので、リモートをどこにするか設定

[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ git remote add origin https://bitbucket.org/hakopako/test.git

4. ローカルとリモートの差分修正をコミット（編集確定）

[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ git status
On branch master

Initial commit

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

	test.html

nothing added to commit but untracked files present (use "git add" to track)
[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ git add .
[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ git commit -m "first commit."
[master (root-commit) caf69ec] first commit.
 1 file changed, 6 insertions(+)
 create mode 100644 test.html

5. ローカルの修正をリモートにpush

[shimada🐱 shimada-no-MacBook-Air]
     >>> [gittest] $ git push origin master
Password for 'https://hakopako@bitbucket.org':
Counting objects: 3, done.
Writing objects: 100% (3/3), 246 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To https://hakopako@bitbucket.org/hakopako/test.git
 * [new branch]      master -> master

これでリモートと同期完了

2_git_dev.md

Gitでの開発サイクル

gitを導入したときに考えなきゃいけない開発サイクルの変化

コードの修正的には

• ソースの管理
  • master : 開発中の安定したコード（１リポジトリ１つ）
  • branch : 絶賛開発中のコード（１リポジトリ複数）
  • tag : リリースされたバージョン（１リポジトリ複数）
• 開発者の作業サイクル
  1. master からbranch をきる
  2. branch で修正作業をする
  3. 修正が問題なさそうなら master に取り込む(merge)
  4. リリース段階までmaster が修正できたらリリースバージョン(tag)をきる
     そしてまた1から次のリリースに向けて作業する

※　これが基本的な教科書どおりの開発手順。
※　だけど実際branch切らずにmasterに直push もよく見る。（ホントは良くない）
　　　⇒　いつのまにか壊れてんだけどになる
※　さらに実際tag 切らずにmaster で常にリリースも良く見る。（ホントは良くない）
　　　⇒　リリースしたら致命的なバグがーってなっても即効で戻すのはつらい （戻せはする）

サーバ系だったら

構成

大体３サーバ必要

• dev環境（開発環境）　：gitのbranch / master を動かす環境
• staging環境（検証環境）　：gitの tag / master を動かす環境
• product環境（本番環境）　：gitの tag / master を動かす環境

※　stagingとproductは常に同じ環境・同じソースが動いているのが基本
※　リリース作業時に本番勝負は危険なのでステージング環境を一旦はさむ
※　本番で障害が起きたときにそれが負荷的なものかコード的なものか原因切り分けとかでも必要
※　普通は３サーバも持てない、費用対効果的に。
※　でもステージング/本番構成は最低限してるかな。
※　１サーバでもパス振り分けとかで本番に影響ない範囲にステージング作るんじゃね？（まだ出会ったことない）

リリース作業

git でコードを管理していればscpとかでリリースファイルをぽちぽちしなくていい。

tag 運用なら
$ git checkout <タグ名>

master 運用なら
$ git pull origin master

でリリース完了。
リリース作業時の人的ミスはほぼなくなる。

3_git_system.md

もうすこしGitを理解する

gitがどういう仕事をしているかはわかっているとして。

バージョン管理ということ

git init するとその階層には　.gitファイルが生成される。
こいつがgit でバージョン管理をする中枢フォルダ。

.git フォルダはそのリポジトリのどのバージョンが
どういうファイル状態である/あったかをすべて保持している。

ex.) 例えば今masterのファイルにいる

[a_shimada@P-574]
     >>> [gittest] $ git branch
* master
  test_branch
[a_shimada@P-574]
     >>> [gittest] $ ll
合計 1.0K
-rw-r--r-- 1 a_shimada Domain Users 6 8月  13 17:24 test.html

test_branch に切りかえる

[a_shimada@P-574]
     >>> [gittest] $ git checkout test_branch
Switched to branch 'test_branch'
[a_shimada@P-574]
     >>> [gittest] $ git branch
  master
* test_branch
[a_shimada@P-574]
     >>> [gittest] $ ll
合計 2.0K
-rw-r--r-- 1 a_shimada Domain Users 6 8月  13 17:24 test.html
-rwxr-xr-x 1 a_shimada Domain Users 6 8月  13 17:29 test2.html*

これで今、
このフォルダはtest_branchで編集中のフォルダ構成・ファイル状態に置き換わっている。
例だと、test_branchにはtest2.htmlが追加されている状態。

またブランチをマスターに切り替えると

[a_shimada@P-574]
     >>> [gittest] $ git checkout master
Switched to branch 'master'
[a_shimada@P-574]
     >>> [gittest] $ ll
合計 1.0K
-rw-r--r-- 1 a_shimada Domain Users 6 8月  13 17:24 test.html

test2.htmlはいなくなっているが、消えたわけではなく、
test2.htmlはまだtest_branchでの修正なのでmasterには存在していないだけ。