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上でやるとこ
自動的にこのようなページに移動します。
以下のものをコピーしておきます。
git remote add origin git@github.com:kazumalab/sample.git
ローカル上でやること
Unityのプロジェクトを管理したい場合
プロジェクト名の直下に移動します。(Assetsとかには入らない)
$ git init $ git remote add origin git@github.com:kazumalab/sample.git
これで環境が整いました。
コミット&プッシュしてみる
今回はUnityプロジェクトでやってみます。
さきほどここまで行きました。
githubでは.gitignoreというものがあります。
その名の通りいらないものを退けることができます。
Unityの場合はコレを入れておきましょう。
github.com
その他プロジェクト(Railsとか)の場合はGoogle先生に Rails gitignoreなどと聞いてみましょう。
今のディレクトリの構造はこんな感じです。
.gitと.gitignoreは同じディレクトリ内
次に
$ git add . $ git commit -m "first commit." $ git push origin master
これでちゃんとsshkeyが設定できていれば問題なくpushできると思います。
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というブランチを作ります。
ちゃんと切り替わったことが確認できます。
masterに戻りたい場合は
$ git checkout master
- -bは新たにブランチを作る場合に必要なのでブランチがある場合は必要ありません。
[豆知識]
ハイフンだけだと一つ前のブランチに戻れます。
$ git checkout -
ブランチで作業してみる
今回はUnityでスクリプトを追加して見ます。
追加後、以下のスクリプトでどこが変更されたのかを見ることができます。
$ git status
Assets/が変更されていることが分かりますので次のように変更された箇所をaddして、commitし、その後pushします。
今回はmasterではなくtest_branchでコミットします。
$ git push origin test_branch
push できたらgithubのリポジトリページを更新してみてください。
すると黄色い注意書きみたいなものが出てきます。
これはpullrequestといって自分以外の人にコードレビューをしてもらったり、masterに結合する時に使います。
今回は一人ですがpullRequestを送ってその後masterに結合してみます。
Compare & PullRequestを押します。
writeの部分にどこを変更したか、見てほしいところはどこかなどメモを書きます。
送信後このような画面になるので本当であればこの後、チームのだれかに見てもらってよければマージします。
マージし終わるとこのようになります。
masterブランチに結合されたのでローカルで一度pullしてきます。
pullは最新の状態にすると言ってもいいと思います。
ではやって見ましょう
masterブランチに移動 $ git checkout master masterでpull $ git pull origin master
できました。
同じブランチで複数人が作業している場合
今回作ったブランチ、test_branchで2人以上作業している場合があるとします。
その流れをざっと書くと、
作業 -> 他の1人が作業終了(pushまで終わった)-> 自分もcommitまではする -> その後pullをする -> ローカルで結合をする(pull時に自動的にvimが起動) -> push
このような流れになります。