こんにちは，米国データサイエンティストのかめ(@usdatascientist)です
前回の記事ではリモートリポをクローン(clone)してローカルリポを作成しました．（Git動画講座はこちら）
クローン(clone)ってなに？という人は前回の記事を是非一読ください．
さて，今日は実際にローカルリポのコードを更新するところやろうと思います．もっとぽくいうと．
ローカルリポで新しいbranchを作ってそこでコードを更新して，addしてcommitする
．．．ってなに言ってるかわからないですよねw
でもこの記事を読みながら実際に手を動かせば，多分明日にはなんの話かわかっていると思いますw
めちゃくちゃわかりやすく説明するよう努力しますmm
なにか質問等あればTwitter(@usdatascientist)にメッセージいただければと思います．
目次
ローカルリポでユーザをセット
ローカルリポでユーザをセットしましょう．一度セットすれば次回からは不要です．
|
1 2 |
$ git config user.name 'usdatascientist' $ git config user.email 'global.datascientist@gmail.com' |
git config user.name '{USERNAME}'でusernameを， git config user.email '{EMAIL}' でemailをセットします！
-global オプションをつければ，他のリポでもデフォルトでユーザがセットされるので毎回やる必要がなくて楽です．新しいbranch(枝)を作る
Gitでは，それぞれの修正箇所や担当機能ごとにbranchというものを作ります．branchはいわゆる’枝’です．
GitはVersion管理なので，コードのVersionを管理していきますよね？version1, version2って感じで．
でも時には開発途中のVersionもあるだろうし，実際にユーザに使ってもらうVersionもあるし，テスト段階のVersionもあります．
ある開発者がAという機能を作る時に，今ユーザーが使っているVersionを直接変更したり，テスト段階のものを変更したら大変なことになりますよね？
Gitでは，それぞれのVersionをひとまずbranchとして管理します．
幹に枝が付いているように，Gitにもメインのbranch(masterと呼ぶ)に様々なbranch(feature branchと呼ぶ)が付いていて，基本的には開発したい機能ごとにbranchを作っていきます．
ある枝から他の枝が生えていき，途中で合流させたりすることで，どんどんMasterの枝を太くしていくイメージです．
開発者はbranchを切り替えて適切なbranchの上で作業をします．
このbranchを切り替えることをcheckoutすると言います．また，新しくbranchを作る場合も同じです．是非今度機会があったら使ってみてください．「新しいbranch checkoutしちゃうよ？」って
それでは，前回cloneしたmy-first-repoが今なんのbranchがあるのか確認してみましょう．
|
1 2 3 |
$ cd ~/Desktop/my-first-repo $ git branch * master |
branchの一覧は $ git branch コマンドで表示できます．
my-first-repoにはmasterというbranchがあって，＊（アスタリスク）がついているので，今自分はmaster branchにいることがわかります．作成したばかりなので当然ですね．
それでは新しいbranch: update-readme branchをcheckoutしてみましょう．
|
1 2 3 |
$ git checkout -b update-readme $ git branch Switched to a new branch 'update-readme' |
$ git checkout -b {branch名} で新しいbranchを作成することができます．
するとupdate-readmeに移動していることがわかります．
|
1 2 3 |
$ git branch master * update-readme |
ここからはこのbranch上で作業をします．masterで作業するわけには行かないからね！毎回機能ごとにbranchを立てる癖をつけましょう！
ファイルを更新しコミット(commit)する
では早速このupdate-readme上でREADME.mdを更新してみましょう．
$ subl README.md でREADME.mdをsublimeで開きます．($subl コマンドが動かない人は正しくPathが通っていないので，こちらの記事のsublime使い方④を参考にしてください．sublimeは必須ではないので，他のエディタでももちろん問題ないです．．）Sublimeを使ってThis is my first repoをThis is my awesome repoに変更して保存します．
第一回でリポを作る時に「Description」に入力した文字がREADME.mdに記入されています．
(Sublimeをいれていない人は是非こちらの記事を参考にいれてみてください！便利なエディタです．)
変更できましたか？変更できたら今度は $ git status コマンドで今のリポの状態をみてみます
|
1 2 3 4 5 6 7 8 9 |
$ git status On branch update-readme Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: README.md no changes added to commit (use "git add" and/or "git commit -a") |
‘Changes not staged for commit’「変更がコミットへのステージングがされていない」と言っています．
日本語に訳しても意味わかんないですよねw
Gitでは変更は全てコミット(commit)という単位で管理されます．いわゆるセーブポイントみたいなものです．
そして，このcommitは複数の変更をまとめてcommitします．
どういうことかというと，今README.mdを変更しましたが，実はまだ途中で他の変更もしたいとしますよね？
「ここまでの変更を次のcommit対象にする」 といった具合にある程度まとめておきます．
この「次のcommit対象に入れる行為」をaddすると言いい，commit対象の変更達をstaging areaとかstagingと言います．
なので先ほどの’Changes not staged for commit’はupdateしたファイルがまだstagingにあがってないよということ．
それでは $ git add {ファイル名やフォルダ名} コマンドでstagingにあげましょう．
|
1 2 3 4 5 6 7 |
$ git add README.md $ git status On branch update-readme Changes to be committed: (use "git reset HEAD <file>..." to unstage) modified: README.md |
$ git add . とやるとカレントディレクトリ以下全ての変更をstagingにあげることができて便利です．
さて， $ git status をみると，Changes to be committed: と，commitできる変更があると言っているのでcommitしてみましょう！
|
1 2 3 |
$ git commit -m 'update read me' [update-readme 12bc06e] update read me 1 file changed, 1 insertion(+), 1 deletion(-) |
$ git commit -m '{メッセージ}' で今stagingに上がっている全ての変更をcommitできます． -m でコミットメッセージを入れる必要があります．これあとからこのcommitがどういう変更だったのかがわかるようにするためです．クオテーション ' を忘れないよーに
結構チームでコミットメッセージのルールとか決めているとおもあります．他の人がみてをわかるようにするのがいいです．
例えば add new button and deal with errorsとかです． updateとか，なんの更新なのかわからないメッセージはやめましょう．嫌われますw
ここでもう一度statusをみてみましょう．
|
1 2 3 |
$ git status On branch update-readme nothing to commit, working tree clean |
nothing to commitとありますね．もうstagingのものはcommitしたので特にcommitするものはないぜ！と言っています．
これで無事commitすることができました！イエイ！
commitの履歴(log)を確認する
さて，commitしたものは $ git log で今までの履歴を確認できます．
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ git log commit bb0dccb33a9814fe89e97482cc61bff14462d10d (HEAD -> update-readme) Author: usdatascientist <global.datascientist@gmail.com> Date: Sat Dec 28 19:11:36 2019 -0500 update read me commit 165c9e3bf866cabc0af00a5f3e6d61f788db2e9e (origin/master, origin/HEAD, master) Author: usdatascientist <59317042+usdatascientist@users.noreply.github.com> Date: Sat Dec 28 12:38:17 2019 -0500 Initial commit |
みてわかる通り，このbranchには2つのcommitがあります
bb0dccb33a9814fe89e97482cc61bff14462d10d という謎の暗号のようなものはcommit IDと呼ばれるもので，乱数文字なので人によって異なります．その他Authorや日時，コミットメッセージが記載されています．リポ作成時にInintial commitというメッセージでcommitされているのもわかると思います．
masterブランチに戻ってみる
では，masterブランチに戻るとどうなるのでしょうか？ $ git checkout master でmasterブランチにcheckoutしてみましょう
|
1 2 3 |
$ git checkout master Switched to branch 'master' Your branch is up to date with 'origin/master'. |
$subl README.md でファイルを開いてみると・・・
|
1 2 |
# my-first-repo This is my first repo |
This is my first repoになっていてawesomeになってないですよね
これは，あくまでも先ほどの変更はupdate-readmeブランチ上のことで，masterブランチには反映していないんです！
最終的にmasterブランチに反映することで初めて自分の開発内容が日の目を浴びることになります．では，どうすればいいのでしょう？
次回はこのupdate-readmeブランチでのcommitをmasterブランチに反映するところまでをやりたいと思います．↓次回はこちら
わからないところがありましたらTwitter(@usdatascientist)で受け付けておりますのでお気軽にどおぞ．フォローもお願いします．
それでは！
もっとGitHubの練習をしたい！という人はDataScienceHubへ！
DataScienceHubではGitHubを使ったコンテンツを実施しています．GitとGitHubを使って様々な課題を提出したり，コーディングレビューを受けることができます．
失敗してもOKな環境で，実際のフローに近いやり方でGitHubを使うことができます．わからないことがあったら自由に質問していただける，Git練習には最高な環境だと思うので是非活用してください．
