Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

GitHubを使ってみよう!👶基本的な操作をざっと確認!

More than 3 years have passed since last update.

この投稿は、初心者向けにざっくりとGitHubについて説明し、基本的な操作をざっと確認するために記述しました。

はじめに

はじめに、GitHubとは?Gitとは?を説明していきます。

GitHubとは?

GitHubは、Webサービスの名前で、
https://github.com で公開されています。
GitHubを使うと、自分の書いたコードを世界中に発信できたり、便利なライブラリを作って世界中に発信して、便利だな!と思った他のユーザーからスターをもらえたり:star:します!
なんだか楽しそうですね😊

他にも、自分の書いたコードを保存しておくことができたり、今ある問題をまとめておくことができたり、進捗管理まで出来てしまいます。

Gitとは?

GitHubはGitの仕組みを利用して作られています。
Gitはバージョン管理システムのことです。
Gitそのものは、全てがコマンドライン上で完結していて、GUI上での操作ができません。
Gitを使うと、ソースコードのセーブを取ること(変更履歴などを記録すること)ができたり、複数人で同じソースコードを編集することが出来ます。

GitとGitHub

GitHubは、Gitの仕組みを使って、更にわかりやすく、GitHubオリジナルの機能を追加して発展したものです。
なので、GitHubを使うには、GitHubオリジナルの機能についての理解はもちろん、Gitの機能について理解する必要があります。

Gitを使うとできること(例え)

Gitはバージョン管理システムだという話をしました。
バージョン管理とは、具体的にどのような事ができるのかを説明します。
Gitでのバージョン管理は、ゲームのセーブのように考えてみるとわかりやすいかもしれません。
ゲームをやっていて、

  • 何か新しいアイテムをゲットしたとき
  • 次のステージに進んだとき
  • レベルが上がったとき

など、何か前に進む変化があったときにセーブをすると思います。
Gitも同じように、自分でコーディングをしていて、何か前に進む変化があった時にセーブすることができます。

また、ゲームをしていて先に進んでいたセーブファイルと進む前のセーブファイルを分けたいときがあると思います。
Gitも同じように、変更後と変更前のセーブファイル(branch)をそれぞれ分けて保存して置くことが出来ます。

また、ゲームのセーブでは出来ない点として、前回セーブしたところと今回セーブしたところを比べると、どこがどう変わったのか、ということもGitでは管理することが出来ます。
例えば、前回、持ち物が剣:dagger:だけの状態で、ステージ2まで進めたところで1回目のセーブ。
今回、ステージ3まで進めて、弓:bow_and_arrow:も手に入れてセーブしたとしましょう。
そうすると、前回から今回までの変更点として、

  • ステージが3になったこと
  • :bow_and_arrow:を手に入れられたこと

が記録されます。この変更点のことを、差分といいます。

Gitを使うとできること(実践)

リモートリポジトリとローカルリポジトリ

Gitを使うとインターネット上にあるリモートリポジトリ、自分のPC上にあるローカルリポジトリの2つが作られます。
自分のPC上で加えた変更はまずローカルリポジトリに保存され、その変更をリモートリポジトリに反映すると、そのソースコードを編集している人みんながその変更されたソースコードを見ることが出来ます。
Gitにはブランチというものがあり、ローカルリポジトリの中にあるブランチをローカルブランチ、リモートリポジトリの中にあるブランチをリモートブランチと呼びます。

ファイル更新をする

何か変更を加えてそれを更新したいときは、基本的にaddcommitpushの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"

みたいな感じで簡単なコミットメッセージからチャレンジしてみましょう!目指せスマートなエンジニア:muscle:

push

commit結果をリモートブランチに反映させるために使います。

git push origin ブランチ名

流れ

もともとあったファイル、例えばtest.javaがあるとします

test.java
public class test{
   public static void main(String[] args){
     System.out.println("Hello World!!");
   }
}

この出力結果を、Hello World!!からGood-bye World!!に変更するとします。

test.java
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"とかになるのでしょうか!?
英語のほうがかっこいいですよね!という記事を書きながらスマートでおしゃれなエンジニアになれていないので、おしゃれじゃないかもしれません。おしゃれな書き方を教えてください:older_woman_tone1:

git.001.jpeg

ブランチを作る

実際に完成形を残し続けるブランチを、基本的にmasterブランチとします。
作っている物をリリースしたいときはこのmasterブランチの内容を使用することが多いです。
なので、常に変更を加え続けるブランチを作る必要があります。基本的にdevelopブランチとします。

名称未設定.001.jpeg

ブランチは、何かのブランチを元にして次のブランチを作ることができます。
この図では、masterブランチが大もとにあり、masterブランチを元にしたdevelopブランチdevelopブランチを元にしたfeature/hogeブランチがあります。

それぞれのもととなっているブランチから新しいブランチをつくり、変更を加え、元のブランチに合流させることをマージと言います。

git branch ブランチ名 //指定した名前のブランチを作る
git checkout ブランチ名 //指定した名前のブランチに移動する

ブランチをマージするときは、マージされる側のブランチにcheckoutし、以下のコマンドを実行します。

git merge マージしたいブランチ名

こうしてブランチを複数作ることで、セーブファイルを複数作ることが出来ます。

GitHubを使うとできること

GitHubでは色々な便利な機能が使えます。その中でも、代表的なものについて説明します。

GitとGithubの連携

GitとGithubを連携させるにはコマンドを数行書くだけです。
まず、GitHub上でリモートリポジトリを作ります。

スクリーンショット 2017-11-02 21.14.06.png

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します

sshのURLは、リポジトリを作った際にでてきます。
スクリーンショット 2017-11-02 21.18.21.png

プルリクエスト

あるブランチをマージしてほしい!という依頼をする時に使います。
ブランチが複数ある時に、マージできるブランチがあれば、そこにプルリクエストを送ることが出来ます。
スクリーンショット 2017-11-02 21.07.46.png
このような緑のボタンがあるので、押すとプルリクエストを送ることが出来ます。
プルリクエストは、基本的に複数人で開発している場合に使います。
自分が書いたコードが、本当にマージしても良いのかをチェックしてもらうために送ることが多いです。

issue

例えば、そのコードで発生しているバグ、エラーなど、何か問題が起きている時にissueを立てることが出来ます。
スクリーンショット 2017-11-02 21.33.09.png
スクリーンショット 2017-11-02 21.34.14.png
issueはopenとcloseができて、解決したissueはcloseすることが出来ます。

Assignees

そのissueの解決を担当する人を選ぶことが出来ます。

Labels

そのissueがどんな性質を持っているのか選ぶことが出来ます。

Projects

後述するProjectsに紐付ける事ができます。

Milestone

後述するMilestoneに紐付ける事ができます。

Projects

ToDoリストをまとめることが出来ます。
カードをつくり、リポジトリ毎に進捗管理をすることが出来、とっても便利です。
スクリーンショット 2017-11-02 21.41.27.png

Milestone

やることとについて期限をつけることが出来ます。
issueと紐付けることで、期限を設けることが出来ます。
スクリーンショット 2017-11-02 21.40.30.png

1人で開発する上ではあまり使わないことが多いかもしれませんが、質問がある際などは、issueを立てて教えてくれる人をAssignするなどして活用できると思います。

mii-chang
モバイルアプリエンジニア
iotlt
IoT縛りの勉強会です。 毎月イベントを実施しているので是非遊びに来てください! 登壇者を中心にQiitaでも情報発信していきます。 https://iotlt.connpass.com
https://iotlt.connpass.com/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away