Explore "Full-Stack" in depth!

情報系の専門学校で、今は機械学習に的を絞って学習中。プログラミングを趣味でやりつつ、IT系のあらゆる知識と技術を身に付けるべく奮闘中。

非ソフトウェアエンジニアも使えるべき最低限Git

概要

それなり前に

gihyo.jp

を買いました。

技術の世界に入って半年、Gitの使い方の勉強をしていない事にめちゃくちゃ後悔していましたが、
他にやるべきことがあるのだろうとなんとなく蔑ろにしていました。

間違いだった。
真っ先に身に付けるべき技術だったと心底思い知った

これ以上ファイル損失の被害が起こらないようにするためにも、
この記事を持って最低限使えるところまでサポート致します。

当記事の目的

ソフトウェアエンジニアに限らず、
機械学習を勉強する人たちにもGitの必要性を問いかけたい為。

つまり本当に初歩的なことしかやりません。

何故今更こんな記事を?
今プログラミングをしていて、Gitを使っていない人はまぁいないと思います。
しかしこのブログは機械学習を勉強している方も見ていることでしょう。
そんな方は知らないかも?と思ったので書いてみた次第です。
後単純に私が勉強してなかったことに危機感を持ちアウトプットしたかった

対象読者

  • Gitがなんだか知ってるが使い方ようわからん
  • githubってなんやねん?gitlabはもっとなんやねん

First Impact

gitlab設定

この記事を見た方は、Gitってなんなの?何が良いの?という疑問はとうに捨て去り、
使いたいけど本買うのは…な方や、
とりあえず最低限が出来ればいいんじゃな方だと思うんですね。

なのでいきなり設定に入っていきます。

こちらのページから、個々人が使用するOSのGitをダウンロードしてきてください。

インストールの方法は特に言うことありません。
厳密にやりたいかたは調べる事をおすすめしますが、いくつか留意点だけ。

  • MSYS2(MINTTY)を強く推奨します。Windows標準のコマンドプロンプトより絶対いい。
  • git bashのみで使うがおすすめです。単純にシンタックスハイライトも見やすい。
  • experimental機能は困ったら導入しなくていいと思います。

Git初期設定

インストールが終わったら、Git Bashを起動しましょう。

git config --global user.name "<任意のユーザネーム>"
git config --global user.email "<あなたのEメールアドレス>"

これは、コミットログ(ご存知かもしれませんが、リポジトリ、ファイルに対する更新履歴)に表示される情報です。
githubでもgitlabでも公開される情報になるので、

知られたくない文字列の使用は控えてください。

見やすくなるような設定も書いておきます。

git config --global color.ui auto

それでは、GitLabにアクセスしてアカウント作成を始めます。

何故GitHubじゃないの?

勿論有名で利用者が多いのはGitHubです。
GitHubリポジトリを面接に使用する企業もどんどん増えてきており、その影響の大きさが伺えます。
GitLabやGitHubと比較して以下の利点があります。

  • 無料でプライベートリポジトリ(厳密にはプロジェクト)を立てられる(一番重要)
  • UIが洗練されていて見やすい
  • 他サービス連携が非常に濃い。(Dockerとか、今を駆けるサービスなどなど)

また、GitHubのアカウントやリポジトリをそのまま流用出来るので、
初期コストも非常に低いです。

賛否両論あるかもしれませんが、今からホスティングサービスを使うなら、
困ったらGitlabで良いんじゃないかなぁと思いました。

あくまでBitbucketとGithubとしか比べてませんのでわかりませんけど。

アカウント作成で言うことは特にありませんが、ひとつだけ。
TwitterGitHubの連携は必ず行いましょう。


更にセットアップを続ける

このGitLabですが、プロジェクトを基本単位としています。

GitHubリポジトリ単位で管理していきますよね。
リポジトリとしての機能以外も追加できたりします。

セルフホスティングを主として利用する人は特に意識するポイントかもしれませんね。

さて、SSh接続の設定をしていきます。

Git Bashにどんどん書いていきましょう。

まずは~/.ssh/というディレクトリに移動(無ければ作成)し、

ssh-keygen -t rsa -C '<Eメールアドレス>'

を入力します。

以下のような文が出力されるはずです。

Generatin public/private rsa key pair.
Enter file in which to save the key
(<鍵を保存するパスを聞かれる>):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

パスについては何も入力せずEnter
passphrase には任意の文字列を入力してEnterです。

これからpushやその他接続時に
pashphraseを聞かれるので必ずメモ!

謎の模様とfingerprint:のようなものが出力されればOKです。

それでは公開鍵をGitlabに登録していきます。

Topページにアクセスし、

[右上のユーザアイコン]→[settings]→[左にあるSSH key]の欄を順にクリックします。

公開鍵をコピペします。タイトルは任意で大丈夫です。

秘密鍵をペーストしないように!!!当たり前ですが秘密鍵を公開してはいけません
正常に登録されたら、接続できるか確認します。

Git Bashから、

ssh -T git@gitlab.com

と入力。
Welcome to Gitlab.com的なのが出ればOKです。


いざ実践

※ここはさらっと流すのでわからずに、コマンドの写経だけ行っていただいても大丈夫です。
まとめの項を御覧ください。

GitLabの左上からProjectsをクリックして、
新規のプロジェクトを作成しましょう!

PublicでもPrivateでもどちらでも良いです。

リモートリポジトリの取得(git clone)

プロジェクトのページに飛ぶと、SSHというプルダウンメニューの隣に
git@gitlab.comから始まるアドレスがあるのでコピー。

任意のフォルダに移動した後、

git clone <コピペ>

でリモートリポジトリをローカルに持ってこれます。

持ってきたリポジトリ内に移動して、適当にファイルを作ってみましょう。

$touch exam.rb

今回はRubyのソースファイルを作成しました。
任意のファイルで構いません

git status

とすると、Untracked filesとしてexam.rbが表示されると思います。
このコマンドはリポジトリの状態を確認出来ます。

具体的には現在作業しているブランチや
コミットの情報などが表示されます。

よく使うコマンドなので覚えておきましょう。

ステージ領域への登録(git add)

git add exam.rb

とすることで、ワーキングツリーからステージ領域に登録します(ココらへんの言葉は後ほど解説します)。
git statusコマンドでnew filesに表示が変わっていることを確認しましょう。

ステージ領域から実際に履歴を残す際には、

ローカルへのコミット、リモートへのプッシュ

git commit -m '<任意のメッセージ>'

とします。

コミットの履歴を見る場合はgit logです。

最後に、コミットした内容をリモートに反映します。

git push

これでGitLabにアクセスして、リモートリポジトリが変更されていることを確認してください。


ここまでのまとめ

さて、ここまで最低限の説明のみしてきましたが、わからなかった人も多いと思います。

ここではGitの主な流れを図にし、理解を深めたいと思います。

f:id:orangebladdy:20181117084733j:plain

基本的にはこのように進んでいきます。

  • ディレクトリ内でファイル編集
  • `git add``でステージング
  • git commitで履歴を残す
  • git pushでリモートに反映

これさえわかっていれば最低限のことは出来ます。

次のステップへ

ここまでの理解で、
ワークツリー・ローカル・リモートという構造とその連携を経験出来ました。

しかし、ブランチを理解することで、
よりGitの便利さを実感する事が出来、
またバージョン管理たる所以の一端との邂逅に心震えることでしょう。


Second Impact

ローカルリポジトリ

今度はローカルリポジトリを作り、
そこで様々なコマンドとともに理解を進めた後、
最後にリモートに反映させるというアプローチを取ってみましょう。

mkdir <任意のディレクトリ>
cd <先程作ったディレクトリ>
git init

git initによってローカルのリポジトリが初期化されます。
ls -a等して、.gitディレクトリが作成されていることを確認しましょう

touch exam.md
git add exam.md
git status

先程と同様に、new fileとして作成したファイルが追加されていますね。

git commit -m "First commit"

一応言及しておくと、
commitしただけでは勿論リモートに何か反映しているわけではないですよ。

git statusとすると、前回のコミットから変更が無いことがわかります。

ここでここまでのコミットを表示してみましょう。

git log

これで、コミット履歴が表示されます。
あるファイルに対して のコミットのみ表示したい場合は
git log <ファイル名>としたり、
-p というオプションをつける事で ファイルの内容の差分が表示されたりします。

では次に、先ほど作成したexam.mdを編集してみましょう。

お好きなエディタ(ターミナルで編集できるものがあれば今回の場合一番手っ取り早い)で(例:Vim)、

vim exam.md

とし、

# git tutorial

welcome to the tutorial of **Git** !

と書いてみましょう。 ファイルの内容を上書き保存したら、

git diff

とすることで変更した差分を表示できます。

この差分は最新コミットと現在のワークツリーの差分になっています。

ステージ領域に保存している場合はそちらとワークツリーを比較します。

それではステージングしましょう。

git add exam.md

git diff HEADとすることで、
最新のコミットとの差分が確認出来ます。
新しくコミットする前に確認する癖をつけてもいいと思います。

git commit -m "add index"

としてコミットしておきましょう。

git logを入力して、コミット履歴を確認すると、
add indexがきちんと反映されています。

ブランチ

ブランチについては既に理解していることと思います。

主に作業台という意識を持っていれば問題ないと思います。

機械学習でコンペに参加した例を取ると、

f:id:orangebladdy:20181117102458j:plain

のようなユースケースも考えられます。

また、別ブランチで追加のデータを結合したデータを用いたい時も、
masterブランチにある元データは汚れないので検証がしやすい。

(ブランチとは直接関係しませんが、
機械学習エンジニアの有用なユースケースとして精度調整が挙げられます。
様々条件での精度をコミットしておけば、いつでも最良なモデルに戻れる等、
機械学習エンジニアにとってもGitは欠かせないツールです。)

それでは実際に使っていきましょう。

git branch

で、現在存在するブランチの一覧が表示されます。

今はmasterしかないですよね。

ここで確認しておくことは * マークです。
これは現在作業中のブランチを表します。
カレントディレクトリみたいなものですね。

ブランチの作成、作業ブランチの移動(git checkout -b)

新しいブランチを作ってみます。

git checkout -b feature

これでgit branch feature(新しいブランチを作る)と、
git checkout feature(指定したブランチに移動する)が同時に行われました。
git branchで現在のブランチがfeatureに移動していると思います。

ここでexam.md`を編集します。

# git tutorial

welcome to the tutorial of **Git** !

## about

it's still modifying now...
git add exam.md
git commit -m 'add message into exam.md'

さて、この編集したファイルがmasterブランチではどうなっているでしょうか?

git checkout master
cat exam.md

ファイルが変更されていないことが確認できるはずです。

ブランチの統合(git merge)

それでは変更をmasterブランチ(統合ブランチとも言う)に反映させてみましょう。

git merge --no-ff feature

--no-ffとすることで、マージされた履歴(マージコミット)を作成出来ます。

これによってfeatureブランチがmasterブランチにマージされ、
変更も反映されました。

リモートに反映

ここまでをリモートに反映していきます。

まず、GitLabに新しいプロジェクトを作成します。
すぐ消すことになるので何でも構いませんが、
特に公開する必要がないのでPrivateで良いでしょう。

作成したら、先程行ったようにリモートへのパスをコピーし、

git remote add origin <パス>

を実行します。

これによりローカルリポジトリとリモートが連携され、
以後originが示したパスを指すようになります。

git push -u origin master

とすることで、ローカルのコミット内容をmasterブランチに反映させます。

この時、現在のブランチがmasterになっていないと上手く機能しないので注意してくださいね。

先程git cloneで持ってきたリポジトリは、
既にパスが登録された状態だったということですね。


総評

いかがだったでしょうか…?
初めてのGitは新鮮さと難しさがあいまって、
刺激的な経験になったと思います。

今回は一人で活用する最低限の(もっと知らなければ行けないことはある)手法を解説しましたが、
Gitの真骨頂はチームでの開発、プロジェクトでのバージョン管理です。

次回git pullgit cloneを用いて、
多人数で利用する際に気をつけること、そして知るべきコマンドと知識について紹介していきますが、

今回はこのような入門的な記事として締めさせていただきます。

全てのエンジニアに必要なGitを、
この記事を皮切りに使っていってください。