kazumalab tech log

流行りとリラックマと嵐が大好きです。技術的ログ。

Githubを活用する方法

Kazuma.です。

今回はGithubの使い方についてまとめておきます。

Githubとは?

バージョン管理システムと呼ばれるものでコードの変更が一目でわかり、途中でバグが発生した場合、変更前のプロジェクトに戻したり、
複数人でプロジェクト運営が楽になります。
非常になれれば使いやすく、かつITスキルとしては必須になりつつあります。

少し古いですがこのサイトに詳しく解説されています。
https://blog.sixapart.jp/2014-03/mttips-02-what-is-git.htmlblog.sixapart.jp
一度見てみるといいと思います。

github.com
登録はしておくといいかもしれません。

Githubを使うまで

アカウントを作ったらとりあえずsshキーをGithubのアカウントに置くところから始めるといいと思います。
ssh keyはwindowsでもmacでもどちらでも作れます。
windowsのかたはコマンドプロントよりもgit bashを使うと使いやすいです(gitbashで検索)

作ったことがある方(とりあえず確認する)

$ ls ~/.ssh/
id_rsa       id_rsa.pub   known_hosts


上記のものがない場合。初めてssh keyを作る場合(英語で全部聞かれるので全部エンター)

$ ssh-keygen


このid_rsa.pubの中をコピーします。
公開鍵認証方式と呼ばれ、毎回passwordを打たなくてもいいので面倒が省けますし、実際こちらの方が多少安全です。

id_rsa.pubをコピペ

$ pbcopy < ~/.ssh/id_rsa.pub

あとは
githubにログイン後右上のアイコン部分からSettings -> SSH and GPG keys -> new SSH key
ここにペーストします。

以上。これで認証できるはずです。

リポジトリを作って環境を作ってみる

とりあえずやること箇条書き

github上でやるとこ

自動的にこのようなページに移動します。
f:id:kazumalab:20160421200430p:plain
以下のものをコピーしておきます。

git remote add origin git@github.com:kazumalab/sample.git


ローカル上でやること

Unityのプロジェクトを管理したい場合
プロジェクト名の直下に移動します。(Assetsとかには入らない)

あとはターミナル(windowsはgit bash)上で

$ git init
$ git remote add origin git@github.com:kazumalab/sample.git

これで環境が整いました。

コミット&プッシュしてみる


今回はUnityプロジェクトでやってみます。
f:id:kazumalab:20160421201501p:plain
さきほどここまで行きました。

githubでは.gitignoreというものがあります。
その名の通りいらないものを退けることができます。

Unityの場合はコレを入れておきましょう。
github.com

その他プロジェクト(Railsとか)の場合はGoogle先生Rails gitignoreなどと聞いてみましょう。

今のディレクトリの構造はこんな感じです。
.gitと.gitignoreは同じディレクトリ内
f:id:kazumalab:20160421202037p:plain

次に

$ git add .
$ git commit -m "first commit."
$ git push origin master

これでちゃんとsshkeyが設定できていれば問題なくpushできると思います。
f:id:kazumalab:20160421202339p:plain

access deniedとでる場合は認証がうまく言っていない場合があります。

疑問コーナー

  • originって書いてるけど何??

これ結構難しい。
リモートのリポジトリ先を変えるときによくつかいます。
特にフォークしたリポジトリなどではフォーク元に追従させておきたいときなど。

$ git push kazumalab master

と言った感じで使います。(kazumalabはユーザーネーム)

その場合fork元を登録する必要があります。

# cloneしたkazumlab/sample内
git remote add igdaryukyu  git://github.com/igdaryukyu/sample.git

これでリポジトリを追従できます。
igdaryukyuが元ディレクトだとするとフォークしてきたkazumalabのsampleはフォークしたときのコミットのままです。そこで、

# cloneした kazumalab/sample内
git pull igdaryukyu master

これでフォークしたものを最新にできます。
そのあとそのままpushすればforkしたリポジトリが更新されます。

  • masterって何??

githubにはbranchと呼ばれるものがあります。

そもそもmasterは基本的には触らない方がいいと言われている・・・。
多くの場合masterブランチはプロジェクトの中心になることが多いので、そこがエラってしまうと元も子もないですよね。

なので基本的にはブランチを分けて中心とは関係のないところで作業を進めて後でそれをmasterに結合します。(マージするという)

先ほどpushしたディレクトリのターミナルからブランチを変えて見ましょう。

これで新しいブランチを作ることができます。

git checkout -b (branch名)

どのブランチがあるのか、自分がどこのブランチにいるのか確認したい場合は

git branch

ではやって見ます。今回はtest_branchというブランチを作ります。

f:id:kazumalab:20160421204652p:plain

ちゃんと切り替わったことが確認できます。

masterに戻りたい場合は

$ git checkout master
  • -bは新たにブランチを作る場合に必要なのでブランチがある場合は必要ありません。

[豆知識]
ハイフンだけだと一つ前のブランチに戻れます。

$ git checkout -

ブランチで作業してみる

今回はUnityでスクリプトを追加して見ます。
追加後、以下のスクリプトでどこが変更されたのかを見ることができます。

$ git status

f:id:kazumalab:20160421205611p:plain

Assets/が変更されていることが分かりますので次のように変更された箇所をaddして、commitし、その後pushします。
今回はmasterではなくtest_branchでコミットします。

$ git push origin test_branch

f:id:kazumalab:20160421210052p:plain
push できたらgithubリポジトリページを更新してみてください。

すると黄色い注意書きみたいなものが出てきます。

f:id:kazumalab:20160421210316p:plain

これはpullrequestといって自分以外の人にコードレビューをしてもらったり、masterに結合する時に使います。
今回は一人ですがpullRequestを送ってその後masterに結合してみます。
Compare & PullRequestを押します。

f:id:kazumalab:20160421210623p:plain
writeの部分にどこを変更したか、見てほしいところはどこかなどメモを書きます。

送信後このような画面になるので本当であればこの後、チームのだれかに見てもらってよければマージします。
f:id:kazumalab:20160421211019p:plain

マージし終わるとこのようになります。
f:id:kazumalab:20160421211244p:plain

masterブランチに結合されたのでローカルで一度pullしてきます。
pullは最新の状態にすると言ってもいいと思います。

ではやって見ましょう

masterブランチに移動
$ git checkout master
masterでpull
$ git pull origin master

f:id:kazumalab:20160421211537p:plain
できました。

同じブランチで複数人が作業している場合

今回作ったブランチ、test_branchで2人以上作業している場合があるとします。

その流れをざっと書くと、

作業 -> 他の1人が作業終了(pushまで終わった)-> 自分もcommitまではする -> その後pullをする -> ローカルで結合をする(pull時に自動的にvimが起動) -> push

このような流れになります。

同じブランチで2人以上で作業する場合はトピックブランチを作るほうが良さそう。

トピックブランチにマージされたらそれぞれのブランチで、git rebase <トピックブランチ名>をすれば良さそう。

masterにマージされた場合も作業している部分が終わったら一旦rebase masterをして、オートマージできるように木のrootを入れ替えて上げると結構良さそう。