けんきうしつのフレンズに送り付けた怪文書のQiita版です。
gitとは？
変更履歴を記録・追跡するための分散型バージョン管理システム。 Git - Wikipedia
Linuxカーネルの膨大なソースコードを効率的に高速な管理をするためにリーナス・トーバルズによって開発されたもの。
言ってしまえばLinuxのために生み出されたLinuxの副産物。リーナスさん最強すぎる。
GitHub / GitLabとは？
GitHubは最もポピュラーなgitリポジトリホスティングサービス。
最近の有名なオープンソースソフトウェアのほとんどはGitHubを通じてソースコードが公開されている。
（rails/rails: Ruby on Rails とか、laravel/laravel: A PHP framework for web artisans とか）
GitLabも同じく有名なgitリポジトリホスティングサービス。DevOps Platform Delivered as a Single Application | GitLab
しかし、ホスティングサービスとしてというよりは、自分で用意したサーバへGitLabの環境を構築し、自分の用意したサーバを通じて身内の中でプロジェクトを共有するためによく利用されている印象。
このようなサービスはgitにより管理されているプロジェクトをクラウド上で管理し、大勢と共有し、ともに開発を進めたり、問題を報告したり、議論したりすることができるものです。そのためgitと密接ではあるものの、また違うものという感じ。
gitはコマンドラインツール、GitHub/GitLabはWebサービス。 ざっくりとこんな印象を持っておいてください。
GitHubのアカウントを作る
https://github.com/ を開きましょう。
右上の Sign upからアカウントの作成を行いましょう！
ちゃっちゃか必要項目を入力します。
Usernameは割とバシバシに公開されるし割と入力するのでそれなりに覚えやすいもののほうが良いと思います。
Email addressはとにかく通じればよし。
PasswordはGitHubにブラウザからログインするときにくらいしか使わないのでなんでも良いと思います。
んで、アカウントつくると「メールにリンク送ったから確認してちょ」みたいになると思うのでメールボックスを開いて確認を済ませましょう。
公開鍵の登録を行う
sshの設定をするとき、scpコマンドで鍵を送ったように、GitHubにも公開鍵を登録してパスワードいらずでGitHubとやり取りできるようにしておこう。
鍵がない場合はssh-keygenして鍵を作ろう。詳しくは調べてくれると助かる...
GitHubがGit操作時のパスワード認証を廃止、今後はトークンによる認証が必須に - GIGAZINE にもある通り8月でクライアントによるパスワード認証の利用が廃止される。あとGitLabも公開鍵認証方式でやりとりすることになるのでまずは試しにGitHubで鍵登録を行ってみよう。
まず、自分の公開鍵を確認する。以下のコマンドをタイプすることで確認できるはず。
# windows
notepad $HOME/.ssh/id_rsa.pub
# macOS / Linux
less ~/.ssh/id_rsa.pub
ちょっと解説しておくと$HOMEはC:\Users\<ユーザ名>の文字列が格納されている環境変数で、これはすなわちホームディレクトリへの絶対パスになっている。
そして.sshディレクトリはホームディレクトリにあるのが基本でssh-keygenに鍵が作成されるデフォルトのディレクトリも.sshでデフォルトの公開鍵名はid_rsa.pubなので$HOME/.ssh/id_rsa.pubに鍵があることが多いのです。
おそらくこれ以外のディレクトリに鍵がある場合は有識者なので特別な解説はいらないかなって。
あ、あとあと。似た名前のファイルでid_rsaがあると思うがこいつは秘密鍵につき門外不出にして最高機密の情報なので何があってもほかの人に見せたりどこかにコピペしたりしないこと。もし門の外に持ち出しちゃったかも...と思ったらssh-keygenして鍵を書き換えて、今までいろいろなところに登録した公開鍵を新しく生成したものに変えること。
もし、知らない人に秘密鍵を奪取されてしまったら、SSHでサーバをあなたの名義で勝手に使ったり、GitHubのアカウントへのかなり強めなアクセス権が奪われたことと同義になります...
このコマンドをタイプするとWindowsならばメモ帳が起動して公開鍵を表示してくれているはずなのでファイル内容すべてをクリップボードへコピーする。
macOSなりLinuxなりならば画面に公開鍵が表示されているはずなのでファイル内容すべてをクリップボードにコピーしておく。記憶できるのならば脳みそで覚えてもいいけど...
次に、GitHubのSettingsページを開く。
Settingsを開いたらSSH and GPG keysをクリック。
そしたら、new SSH key的なミドリのボタンがあるはずなのでそいつをクリック。
Titleには鍵の名前を入力しよう。複数台パソコンを使う人なら複数の鍵を登録することになるのでどのパソコンの鍵かわかりやすくしておくとよいと思う。
Keyには先ほどコピーしたものをペーストする。
最後にAdd SSH keyをクリックすれば公開鍵の登録完了！やったね！
ちゃんと登録できているかは少し後で確認しましょう。
リモートリポジトリを作成する
GitHubにログインした状態でページ左上のこのミドリのやつをクリックしよう。
そしたらこんな感じのリポジトリ作成画面に移るので必要項目を入力しよう。
Repository Name
リポジトリの名前。
これから作成するソフトウェアの名前ともいえるもの。内容が分かりやすいものがよいだろう。
またこのリポジトリをcloneするとRepository Nameがディレクトリ名となるのでほどほどの長さがよいかと思います。
Description (optional)
リポジトリの説明です。
どんなリポジトリなのか、どんなソフトウェアなのかを書くことができます。
optionalなので書かなくていいです。書いても特に何にも影響しないので書いてもいいです。
Public / Private
PublicにするとGitHubで公開されます。誰でもこのリポジトリに含まれるファイルを閲覧することができ、forkして派生プロジェクトを作成することもできます。ただし、設定を変更したり、だれかを招待しない限りは勝手にほかの人に内容を書き換えられることはありません。
Privateにすると自分と招待されたユーザだけしか内容が確認できないリポジトリになります。
どちらを選んでもちょっと使う分にはあんまり違いはないのでどっちでも大丈夫です。
Pricing · Plans for every developer に細かい違いが書いてあります。
Initialize this repository with:
リポジトリ作成と同時に最初のコミットを作成するかどうかの欄です。
リポジトリ作成と同時にコミットをしたくないときはいずれにもチェックを入れる必要はありません。
いずれかひとつでもチェックを入れるとデフォルトのブランチとしてmainが作成され、Initial commitされた状態のリポジトリが作成されます。
Add a README file
README.mdファイルを追加しておくオプションです。
README.mdファイルは通常、ソフトウェアの利用方法や、開発の仕方、開発者の連絡先などを記しておくファイルです。
Markdown記法で書かれることが多く、GitHubではREADME.mdファイルを良い感じにプロジェクトページに表示してくれたりします。
Add .gitignore
.gitignoreをあらかじめ作成しておくオプションです。
.gitignoreファイルはgitでバージョン管理させたくないファイルを指定するためのファイルです。
例えばコンパイルして生成されるファイルやパッケージマネージャによりダウンロードされるファイルなどを指定しておくことで、不必要に変更を記録してごちゃごちゃしたりだとか、リポジトリのやり取りを不必要に重くすることを防ぎます。
Choose a license
オープンソースライセンスを指定し、LICENSEファイルを作成するオプションです。
オープンソースライセンスとはGitHubなどで公開されているソースコードを2次利用する際のルールとして掲示するものです。
Apache License 2.0やMIT License、クリエイティブ・コモンズ・ライセンスなど、見聞きしたこともあるのではなかろうか。
これらには何をしてよくて、何をしてはダメなのかが明記されており、ライセンスとして自由に使っていい文書として公開されているものです。
これらのオープンソースライセンスはLICENSEの定型文のようなもので、適用したいルールと一致しているライセンスがあればこれをそのまま記せば自分はライセンスを書く手間が省けるし、利用する側も知ってるライセンスなのでルールを把握できていていちいち全文を確認する必要ななくお互いにハッピーな取り組みです。
自分のプロジェクトにLICENSEという名前テキストファイルを配置してあげることで「これに従って2次利用しなさい」とお願いしていることになります。不特定多数に広めたいプロジェクトならば必ず作成すべきですがそうでもないならなくても問題にならないです。
ちなみに、オープンソースライセンスの中には「成果物を必ずオープンソースにし、このライセンスを適用しろよな」みたいな強い制約のあるものもあるので、見たことないライセンスを目にしたら全文読んでみるうえに和訳なり解説記事を読むなりしてライセンスで制限されていることを十分に理解してから使うようにしましょう。
リモートリポジトリへのURLをクリップボードにコピーする
リポジトリのページの真ん中へんにあるCodeのミドリのやつをクリックすると何やらリンクが表示される。
これのSSHのところに下線が引かれているか確認しよう。
HTTPSとかになっていたらSSHをクリックしてリンクをクリップボードへコピーしておこう。
HTTPSのリンクを使ってもいいけど... さっき公開鍵登録したしさ... パスワードを手入力しなくてよくなるんだ...
おっと、ここでちょっとルート分岐だ。
先ほど、Initialize this repository with: のどれかにチェックを入れたかな？
入れていたらリポジトリをcloneするに、入れていなければローカルリポジトリを作成するに進んでくれ！
リポジトリをcloneする
コマンドラインでリポジトリを配置したいディレクトリを開いて次のコマンドをタイプしよう。
git clone git@github.com:XXXXXX/XXXXX.git # <- コピーしたURL
公開鍵の登録が正しくできていればリポジトリがGitHubよりダウンロードされ、自分のパソコンに配置される。
これがcloneと呼ばれる操作でリモートに存在するリポジトリをローカルにダウンロードしている。
アクセスできなさそうな感じになったら公開鍵の登録がうまくできていない。
先ほど追加した鍵を削除してもう一度鍵の登録を試してみよう。
ローカルリポジトリを作成する
コマンドラインからリポジトリを配置したいディレクトリを開こう。
プロジェクトのルートディレクトリとなるディレクトリを作成しよう。
この時作成するディレクトリの名前は先ほど作成したリモートリポジトリのものとそろえておくのがベターだ。
mkdir your-repository-name # リポジトリの作成
cd your-repository-name # カレントディレクトリの移動
そしていよいよ、ローカルリポジトリの作成だ。
いでよ、git init ───
git init
そうするとまだインターネッツに接続されていないローカルリポジトリが作成される。
このままだと井の中の蛙大海を知らず、だれもこのプロジェクトを知らないし、きみのパソコンだけに幽閉されてしまっている。
リモートを追加してGitHubにアップロードできるようにしてあげようじゃないか。
git remote add origin git@github.com:XXXXXX/XXXXX.git # <- 先ほどコピーしたURL
git remote addはリモートの追加を行うコマンド、originはデフォルトのリモートの名前としてよく使われている。
特別な理由がなければoriginとして登録しておくのが無難だと思うけど、別にどんな名前でも差し支えない。
そして最後に先ほどコピーしたURL。こちらを参照してリポジトリを共有したり、GitHubでのリポジトリの状態を取得したりするわけだ。
ちゃんと登録できたか、確認してみよう。
git remote -v
これでなんか2行くらい出てきたらおっけー。
では、けなげなローカルリポジトリをインターネッツに染め上げてやろうか...
git push -u origin main
git pushはリモートにローカルリポジトリに加えた変更を反映させるコマンド。これをタイプすることでリモートへ自分の生み出した進捗が共有され、他のチームメンバーがこの進捗を取り込んだりすることもできるってこと。
-uオプションは今後mainブランチが参照するリモート（up stream）を設定してあげている。これからはgit pushだけタイプすれば変更がリモートに反映されるようになります。
最後のmasterはリモートに作成されるブランチの名前。なんでもかまいません。伝統的にはmasterです。
black lives matterに配慮してGitHubではデフォルトのブランチ名がmainに変更されていますが、gitがデフォルトで作成するブランチ名はmasterのままです。そのうち変わったりするのだろうか...
この記事では以下mainを使っていきますので適宜読み替えてね。 デフォルトのブランチ名変えたいときはググってみよう。
このコマンドをタイプするとリモートにローカルリポジトリの内容が反映される。
公開鍵の登録が正しくできていればリポジトリがGitHubアップロードされる。
これがpushと呼ばれる操作なのである。
アクセスできなさそうな感じになったら公開鍵の登録がうまくできていない。
先ほど追加した鍵を削除してもう一度鍵の登録を試してみよう。
メールアドレス / 名前の設定
さて次はcommitを試しにしてみたいのだが、このままだとgitに「おまえだれやねん」って怒られる。
なので、メールアドレスと名前を設定しよう。
git config --global user.name 好きなお名前
git config --global user.email c0118999xx@edu.teu.ac.jp
お名前は特になんでもいいけど、GitHubのアカウント名が適切かと思います。
メールアドレスはGitHubでの表示に絡んでくるのでGitHubでの登録に使ったメールアドレスにしておくのが良いかと思います。
コミットしてみる
エディタか何かでリポジトリのディレクトリにファイルを追加してみよう。
そして、git statusコマンドを実行してみよう。
$ git status
On branch master
No commits yet
Untracked files:
(use "git add <file>..." to include in what will be committed)
hello.txt
nothing added to commit but untracked files present (use "git add" to track)
こんな感じの出力があればよろし。
そしたらgit addしよう。
git add 作成したファイル名
# とにかくすべてのファイルをコミットするファイルとする
git add *
git add出来たらgit commitだー！
コミットに対するコメントは何でもよいですが、どんな作業をしたかわかりやすいものを書くと有識者がメロメロになります。
-mオプションはコミットにコメントをつけるというものです。
これを省いてgit commitだけタイプするとviエディタを使って「コミットメッセージ打てやコラ」みたいな感じになります。
もし間違えちゃったときはescキーを押して :q!とタイプしてenterを押すととりあえず抜けられます。
viエディタの使いかたを習得すると長文コミットメッセージを打ちたいときなんかに便利です。
git commit -m "コミットに対するコメント"
コミットという操作はRPGゲームなんかで新しいスロットにセーブを書くようなもの。
コミットを打った時点にいつでもリポジトリすべてでも一部のファイルだけでも復元することができたりします。
とにかく、進捗を生んだらコミット。コミットメッセージをひとことで言い表せるくらいの細かさで作ると有識者にモテます。
pushする
いくらコミットしても git pushをしない限りはリモートリポジトリに反映されません。
コミットしたら忘れずにgit pushをしましょう。
git push
さすればきみがコミットした進捗はインターネット上に共有されるってワケ。
ざっくりこれらのコマンドを活用してみんなでひとつのソフトウェアを作り上げたりあげなかったりします。
ちゃんとgit pushできたか、GitHub上で確認しましょう！
git pushに失敗したらメールアドレス/名前の設定ができていないことが主に考えられます。git config --global user.email、git config --global user.nameのコマンドをタイプして設定が完了しているか確認しましょう。
多分連載。