この投稿は、初心者向けにざっくりとGitHubについて説明し、基本的な操作をざっと確認するために記述しました。
はじめに
はじめに、GitHubとは?Gitとは?を説明していきます。
GitHubとは?
GitHubは、Webサービスの名前で、
https://github.com で公開されています。
GitHubを使うと、自分の書いたコードを世界中に発信できたり、便利なライブラリを作って世界中に発信して、便利だな!と思った他のユーザーからスターをもらえたりします!
なんだか楽しそうですね😊
他にも、自分の書いたコードを保存しておくことができたり、今ある問題をまとめておくことができたり、進捗管理まで出来てしまいます。
Gitとは?
GitHubはGitの仕組みを利用して作られています。
Gitはバージョン管理システムのことです。
Gitそのものは、全てがコマンドライン上で完結していて、GUI上での操作ができません。
Gitを使うと、ソースコードのセーブを取ること(変更履歴などを記録すること)ができたり、複数人で同じソースコードを編集することが出来ます。
GitとGitHub
GitHubは、Gitの仕組みを使って、更にわかりやすく、GitHubオリジナルの機能を追加して発展したものです。
なので、GitHubを使うには、GitHubオリジナルの機能についての理解はもちろん、Gitの機能について理解する必要があります。
Gitを使うとできること(例え)
Gitはバージョン管理システムだという話をしました。
バージョン管理とは、具体的にどのような事ができるのかを説明します。
Gitでのバージョン管理は、ゲームのセーブのように考えてみるとわかりやすいかもしれません。
ゲームをやっていて、
- 何か新しいアイテムをゲットしたとき
- 次のステージに進んだとき
- レベルが上がったとき
など、何か前に進む変化があったときにセーブをすると思います。
Gitも同じように、自分でコーディングをしていて、何か前に進む変化があった時にセーブすることができます。
また、ゲームをしていて先に進んでいたセーブファイルと進む前のセーブファイルを分けたいときがあると思います。
Gitも同じように、変更後と変更前のセーブファイル(branch)をそれぞれ分けて保存して置くことが出来ます。
また、ゲームのセーブでは出来ない点として、前回セーブしたところと今回セーブしたところを比べると、どこがどう変わったのか、ということもGitでは管理することが出来ます。
例えば、前回、持ち物が剣だけの状態で、ステージ2まで進めたところで1回目のセーブ。
今回、ステージ3まで進めて、弓も手に入れてセーブしたとしましょう。
そうすると、前回から今回までの変更点として、
- ステージが3になったこと
- 弓
を手に入れられたこと
が記録されます。この変更点のことを、差分といいます。
Gitを使うとできること(実践)
リモートリポジトリとローカルリポジトリ
Gitを使うとインターネット上にあるリモートリポジトリ、自分のPC上にあるローカルリポジトリの2つが作られます。
自分のPC上で加えた変更はまずローカルリポジトリに保存され、その変更をリモートリポジトリに反映すると、そのソースコードを編集している人みんながその変更されたソースコードを見ることが出来ます。
Gitにはブランチというものがあり、ローカルリポジトリの中にあるブランチをローカルブランチ、リモートリポジトリの中にあるブランチをリモートブランチと呼びます。
ファイル更新をする
何か変更を加えてそれを更新したいときは、基本的にadd
、commit
、push
の3種類を使います。
これを3つを1セットと覚えておくと間違いがないと思います。更新をしたら、addしてcommitしてpushします。
add
何か変更を加えたファイルを追加する時に使います。
git add . //全てのファイルをadd
git add ファイルpath //指定したpathのファイルのみをadd
commit
addしたものをローカルブランチに反映させるために使います。
git commit -m "コミットメッセージ"
何かした作業ごとにこまめにコミットをしていきましょう。コミットログは、作業記録になり、コードの歴史を作ります。いつ何をしたのかを記録していきましょう。
コミットメッセージ
このコミットメッセージには、どんな変更を加えたかを書きます。
どんなふうに書いても良いのですが、あとから何を変更したのかちゃんと分かるように書きましょう。
ちなみに、日本語でなくて英語で書いたほうがやっぱりオシャレかっこいいです。スマートな感じを出すために(?)よく使われていると思われる英語のコミットメッセージを紹介しておきます。
基本的に、よく使うgitの操作というのは、
- 追加したよ!
- 変更したよ!
- 消したよ!
だと思います。それぞれ、
操作 | 内容 | 英語のメッセージ |
---|---|---|
追加したよ! | 何かファイルを追加した時 | add |
変更したよ! | 何かバグを解決した時 | fix |
変更したよ! | 何か変更を加えたとき(バグ以外) | change |
消したよ! | 何かファイルを消したとき | remove |
という英単語がよく使われます。
git commit -m "add hoge.java"
git commit -m "fix typo"
git commit -m "change file name"
git commit -m "remove piyo.png"
みたいな感じで簡単なコミットメッセージからチャレンジしてみましょう!目指せスマートなエンジニア
push
commit結果をリモートブランチに反映させるために使います。
git push origin ブランチ名
流れ
もともとあったファイル、例えばtest.java
があるとします
public class test{
public static void main(String[] args){
System.out.println("Hello World!!");
}
}
この出力結果を、Hello World!!
からGood-bye World!!
に変更するとします。
public class test{
public static void main(String[] args){
System.out.println("Good-bye World!!");
}
}
変更後、コマンドラインでGitの操作をします。
git add test.java //変更したファイルをaddします。今回の例では、1つのファイルしか変更していないので、git add .でもOK
git commit -m "出力結果を変更"
git push origin master
これでGitに変更を記録することが出来ます。
差分としてはHello World!!
からGood-bye World!!
に変更されたことが記録されます。
コミットメッセージを英語で書くなら、git commit -m "change output message"
とかになるのでしょうか!?
英語のほうがかっこいいですよね!という記事を書きながらスマートでおしゃれなエンジニアになれていないので、おしゃれじゃないかもしれません。おしゃれな書き方を教えてください
ブランチを作る
実際に完成形を残し続けるブランチを、基本的にmasterブランチとします。
作っている物をリリースしたいときはこのmasterブランチの内容を使用することが多いです。
なので、常に変更を加え続けるブランチを作る必要があります。基本的にdevelopブランチとします。
ブランチは、何かのブランチを元にして次のブランチを作ることができます。
この図では、masterブランチが大もとにあり、masterブランチを元にしたdevelopブランチ、developブランチを元にしたfeature/hogeブランチがあります。
それぞれのもととなっているブランチから新しいブランチをつくり、変更を加え、元のブランチに合流させることをマージと言います。
git branch ブランチ名 //指定した名前のブランチを作る
git checkout ブランチ名 //指定した名前のブランチに移動する
ブランチをマージするときは、マージされる側のブランチにcheckoutし、以下のコマンドを実行します。
git merge マージしたいブランチ名
こうしてブランチを複数作ることで、セーブファイルを複数作ることが出来ます。
GitHubを使うとできること
GitHubでは色々な便利な機能が使えます。その中でも、代表的なものについて説明します。
GitとGithubの連携
GitとGithubを連携させるにはコマンドを数行書くだけです。
まず、GitHub上でリモートリポジトリを作ります。
git init //Gitの初期化、これはGitの設定
git add ファイルpath
git commit -m "コミットメッセージ"
git remote add origin sshのURL //GitHubとSSH接続できるようにします
git push -u origin master //リモートのmasterブランチにpushします
プルリクエスト
あるブランチをマージしてほしい!という依頼をする時に使います。
ブランチが複数ある時に、マージできるブランチがあれば、そこにプルリクエストを送ることが出来ます。
このような緑のボタンがあるので、押すとプルリクエストを送ることが出来ます。
プルリクエストは、基本的に複数人で開発している場合に使います。
自分が書いたコードが、本当にマージしても良いのかをチェックしてもらうために送ることが多いです。
issue
例えば、そのコードで発生しているバグ、エラーなど、何か問題が起きている時にissueを立てることが出来ます。
issueはopenとcloseができて、解決したissueはcloseすることが出来ます。
Assignees
そのissueの解決を担当する人を選ぶことが出来ます。
Labels
そのissueがどんな性質を持っているのか選ぶことが出来ます。
Projects
後述するProjectsに紐付ける事ができます。
Milestone
後述するMilestoneに紐付ける事ができます。
Projects
ToDoリストをまとめることが出来ます。
カードをつくり、リポジトリ毎に進捗管理をすることが出来、とっても便利です。
Milestone
やることとについて期限をつけることが出来ます。
issueと紐付けることで、期限を設けることが出来ます。
1人で開発する上ではあまり使わないことが多いかもしれませんが、質問がある際などは、issueを立てて教えてくれる人をAssignするなどして活用できると思います。