【6,000文字】GitHubのお勉強【初心者】

hama

本記事について

3か月プログラミングを学んでもGitHubを「ネットにコードを保存するためのツール」という程度にしか理解できていない私が、GitHubについて勉強しながら記録していくnoteです。

GitとGitHub

Gitはバージョン管理

誰がいつどこを変更したのかが分かるようにする仕組みです。バージョン管理を行うことで、複数人で作業する際に、変更を上書きしたり、削除したものを復元したりするトラブルを防ぐことができます。Gitを使ってバージョン管理されたファイルや変更履歴の保存場所がGitリポジトリです。
リポジトリ（repository）：倉庫

GitHubはオンラインで使えるGit

GitHubは、Gitをオンラインで他の人と共有・管理できるサービスです。プルリクエストなどの機能を通じてオープンソースの開発を効率的に管理できます。Bitbucketも同様のサービスを提供しています。

Git

Gitの保存方法

Gitは、変更のあったファイル全体を保存しており、差分ではなくファイルの全体を保存します。この全体をスナップショットと呼びます。

GitHubへの保存の流れ

自分のPC（ワークツリー）でファイルを保存する際、まずファイルのスナップショットをローカルリポジトリに保存します。その後、ローカルリポジトリのスナップショットをオンラインのGitHubリモートリポジトリにアップロードします。

GitHubから取り込む流れ

GitHubのリモートリポジトリからファイルをローカルリポジトリにダウンロードし、その後、ローカルリポジトリの内容を自分のPC（ワークツリー）に反映させます。

ローカルでの保存の流れ（add/commit）

ワークツリー → ステージ → ローカルリポジトリ という順番で変更が保存されます。

  1. ワークツリー：

    • ファイルを編集する作業スペースです。

  2. ステージ：

    • git add コマンドを使って、変更をステージングエリアに追加します。ここでの作業は、次にコミットする内容を準備することです。

  3. リポジトリ：

    • git commit コマンドを使って、ステージングエリアにある変更をリポジトリに保存します。

commit -m 

コミットした際に、コメントを記入する必要がある。

git commit -m "<コメント>"

あるいはgit commit　した際に、

この画面が出るので、コメントを打って、Escキー押して、「:wq」を打つ。
wqは、write（書き込む）とquit（やめる）。

Gitのデータ管理

git add や git commit を行うと、Gitでは3種類のファイルが作成されます。これらをGitオブジェクトと呼びます。

  1. 圧縮ファイル（Blob）：

    • ファイルの内容を圧縮して保存します。

  2. ツリーファイル（Tree）：

    • ディレクトリの構造やファイルのリストを保存します。

  3. コミットファイル（Commit）：

    • コミットのメタデータ（変更履歴、メッセージ、ツリーオブジェクトなど）を保存します。

これらのオブジェクトによって、Gitはファイルの内容やバージョン履歴を効率的に管理しています。

ローカルリポジトリの作成（init）

git init コマンドを実行すると、プロジェクトフォルダ内に .git というディレクトリが作成されます。このディレクトリには、Gitがリポジトリの管理に必要なすべての情報や設定が保存されます。

ディレクトリとフォルダ

「ディレクトリ」と「フォルダ」は、基本的には同じ概念を指しますが、用語の使われ方に違いがあります。

  • ディレクトリ：

    • 主にコマンドラインやプログラムで使われる用語です。ファイルシステム内でファイルや他のディレクトリを整理するための構造です。Unix系システムやプログラミングの文脈でよく使用されます。

  • フォルダ：

    • 主にグラフィカルユーザーインターフェース（GUI）やデスクトップ環境で使われる用語です。ファイルや他のフォルダを整理するためのアイコンやウィンドウのことを指します。WindowsやMacのデスクトップ環境でよく使用されます。

どちらもファイルシステムの階層構造を表すため、機能的には同じです。ただし、用語の使われる状況によって異なる表現がされることがあります。

GitHub

リモートリポジトリを追加する（remote add origin）

git remote add origin https://github.com/hamanyann/test.git

urlを登録することで、originという名前でGitHubにpush出来るようになる。

リモートリポジトリへ送信する（push）

git push -u origin main

コマンドの意味:

  • git push: 現在のブランチの変更をリモートリポジトリにプッシュ（アップロード）するコマンドです。

  • -u (または --set-upstream): このオプションは、ローカルブランチとリモートブランチの追跡関係を設定します。これにより、今後 git push や git pull を実行する際にブランチ名を省略できます。

  • origin: リモートリポジトリの名前です。通常、クローンしたリポジトリのデフォルト名は origin です。

  • main: プッシュ先のリモートブランチの名前です。最近のリポジトリでは、デフォルトブランチとして main が使われることが一般的です。

pushしたリポジトリの確認

Raw：生のコード。コピペするときに使う。

Blame:責任者。だれがどの部分をいつ変更したか。

History:コミットの履歴を見れる。

Commits:リポジトリ全体のコミット履歴

コマンドエイリアス（alias）

コマンドにエイリアス（別名）を付けることで入力が楽になる。

git config --global alias.ci commit
git config --global alias.st status
git config --global alias.br branch
git config --global alias.co checkout

たぶんこの辺は好みがあるので自分でおすすめ設定を調べてください。
自分も変わると思います。

--globalを入れると、すべてのプロジェクトに適応。

.gitignoreファイル

バージョン管理しないファイルを指定する。

ファイルへの変更を巻き戻す（checkout -- / status）

変更した内容を巻き戻すやり方。

git checkout -- <ファイル名>
git checkout -- .

変更をしてgit statusで見てみる。

data.jsonが変更されてるけどステージに上げてないよ、という警告。

無事に変更前に巻き戻りました。

ステージした変更を取り消す（reset）

git reset HEAD .

git addでステージに上げた変更を取り消す。ワークツリーは巻き戻らない。

直前のコミットをやり直す（amend）

git commit --amend

git commit でローカルリポジトリに上げたコミットを取り消す。

注意：pushでリモートリポジトリへ上げた後だと、整合性が取れなくなるのでpushしたら取り消しは行わないこと。

リモートリポジトリの情報を確認する（remote -v）

git remote -v

リモートリポジトリから情報を取得する（fetch）

git fetch origin

リモートリポジトリからローカルリポジトリに変更を取得する。
その後、git mergeでワークツリーに反映させる必要がある。

リモートリポジトリから情報を取得する（pull）

git pull

リモートリポジトリからローカルリポジトリに変更を取得し、さらにワークツリーへのマージまで行う。

fetchとpull

pullはマージまでしてくれるが、現在の作業ブランチにマージするため注意が必要。

ブランチ

複数の機能を同時に開発するために、ブランチを使用します。

ブランチを使用することで得られるメリットは多くあります。以下はその主なメリットです：

  1. 並行作業のサポート: 異なる機能やバグ修正を独立して開発できるため、複数の作業を同時に進めることができます。

  2. リスクの分離: 新しい機能や変更をブランチで開発することで、メインのコードベースに影響を与えることなく作業を行えます。これにより、安定した状態を保ちながら開発できます。

  3. コードレビューの容易さ: ブランチごとに機能や修正内容が分かれているため、コードレビューやテストがしやすくなります。変更が明確に区別されるため、レビューが効率的になります。

  4. リリース管理: リリースごとに異なるブランチを使用することで、各リリースの準備が容易になり、特定のバージョンを管理しやすくなります。

  5. 簡単な統合: 機能が完成したら、ブランチをメインブランチに統合することで、作業内容を一元管理できます。merge や rebase を使って変更を取り込むことができます。

  6. 実験の機会: 新しいアイデアや試験的な変更をブランチで試すことができ、成功した場合にのみメインブランチに統合できます。失敗してもメインブランチには影響しません。

  7. バージョン管理の強化: 各ブランチが異なる作業や機能に対応しているため、履歴の管理や追跡がしやすくなります。どのブランチで何を行ったかが明確に記録されます。

これらのメリットにより、チームでの協力や個人での開発作業がスムーズに進むようになります。

ブランチはどのコミットファイルを指し示すかというもの。
どの時点のコミットファイルを作業しているか、ということを意識する。

ブランチの作成（branch）

git branch

現在のブランチ一覧を表示する。

今はmainブランチのみ。

git branch <ブランチ名>

git branch issueによって、新たなブランチissueが作成できた。
*マークは現在のブランチ。
まだmainブランチで作業している状態。

ブランチの切り替え（checkout）

git checkout <既存ブランチ名>

切り替え完了。
ワークツリーを巻き戻すgit checkout -- <ファイル名>と間違わないように。

ブランチを作成して切り替え（checkout -b ）

git checkout -b <新ブランチ名>

新しいブランチからpush（--set-upstream）

新しいブランチを作成して移動する。

issue2という新しいブランチで変更を行った結果。

後で出てきます

git commitした後pushしたらエラーが出ました。

git push origin issue2とすることでpush出来ました。
git pushだけでpush出来るのは、先にgit push -u origin mainを入力したmainブランチのみなんですね。

issue2ブランチでもgit pushだけでpush出来るようにするには、

git push --set-upstream origin issue2

このコマンドを打てばいいようです。

git pushのみでissue2にpush出来るようになりました。

マージ（merge）

他の人の変更内容を取り込むこと。

git merge <ブランチ名>
git merge <リモート名/ブランチ名>

先ほどissue2で変更した内容をmainに取り込みます。

mainブランチに移動してissue2の変更をマージしました。

Fast-forward　/　Auto-merge

これはissue2に変更を加えた時の画像。

これは今回issue2をマージした時の画像。
issue2をマージしたことで、コミットファイル名がac85175になっています。
つまり、前回のmainブランチからissue2に変更後、mainに変更がなかったため、issue2が純粋な最新ブランチとなり、mainのポインタがissue2に向いたということですね。

これがFast-forwardです。

逆に、mainにも変更を加え、issue2が単純なアップデートじゃなくなった場合、新たなコミットファイルが作られ、コミットファイル名は別のものになります。それがAuto mergeです。

コンフリクト

コンフリクトは同じファイルの同じ行に対して異なる変更を行った際に発生します。

issue2とmainで同じ個所を変更してマージしました。

解決策としては、単純にmainでいらない部分を削除してpushするだけです。

ブランチ名の変更と削除（brantch -m / branch -d）

git branch -m <ブランチ名>

作業中のブランチを別の名前を変更する

git branch -d <ブランチ名>
git branch -D <ブランチ名>

作業中のブランチを削除する
-D 大文字のDはブランチに変更が残っていてマージされてない状況でも関係なく強制的に削除する。

ブランチを利用した開発

現行の稼働しているリリースアプリをmainブランチにして、機能の追加や回収を行っているものを別のブランチにする。

そうすることで現行の把握が出来、現行のサービスに影響が出ないように出来る。

リモートブランチ

ブランチを確認すると、4つのブランチが出来ている。

issue2：ローカルissue2ブランチ
main：現在作業中のローカルmainブランチ
remotes/origin/issue2：リモートリポジトリoriginのissue2ブランチ
remotes/origin/main：リモートリポジトリoriginのmainブランチ

マージを行っても元のブランチ自体は残っている。

勘違いしてたけど、自分がgit merge issue2でマージしたのはローカルのissue2であって、pushしたリモートリポジトリのissue2ではなかった。

今回一人でやってるから結果はローカルからマージしてもリモートからマージしても結果は同じ。

プルリクエスト

自分の変更したコードをリポジトリに取り込んでもらえるよう依頼する機能。

  • リポジトリをクローンする

  • ブランチを作成する

  • コードを変更する

  • 変更をコミットする

  • 新しいブランチにプッシュする

  • プルリクエストを作成する

  • コードレビューを受ける

  • 必要な変更を行い、再度プッシュする

  • プルリクエストをマージする

  • 不要なブランチを削除する

GitHub Flow

守るべきルール
①「masterブランチのものは何であれデプロイ可能である」
②「masterから説明的なブランチを作成する」
③「名前をつけたブランチに定期的にpushする」
④「いつでもプルリクエストを作る」
⑤「マージはプルリクエストがレビューされた後だけ」
⑥「レビューのあとは直ちにデプロイする」

GitHub Flowの流れ
【1】作業用ブランチを作成し開発作業を行う
【2】プルリクエストを実行する
【3】コードレビューを行う
【4】デプロイする

イシュー

イシュー（issue）は、ソフトウェア開発やプロジェクト管理において、タスク、バグ報告、機能要望などの個別の項目を指す用語です。GitHubやGitLab、Jiraなどのプロジェクト管理ツールでは、イシューはチームが共同で作業するための基本的な単位となります。

コントリビュート

「コントリビュート（contribute）」とは、特定のプロジェクトやコミュニティに対して貢献することを意味します。特にオープンソースソフトウェアの開発においてよく使われる用語です。以下に、コントリビュートの具体的な意味や方法について説明します。

フォーク

リポジトリのフォーク（fork）とは、他のユーザーのリポジトリを自分のアカウントにコピーして、新しい独立したリポジトリを作成する操作のことです。フォークを行うと、オリジナルのリポジトリと同じ状態のリポジトリが自分のアカウントに作成され、そこで自由に変更を加えたり新しい機能を追加したりすることができます。フォークは特にオープンソースプロジェクトでよく使われ、以下のような用途に役立ちます。

感想

一日GitHub漬けでした！

これでGitHub博士ですね。

イシューとかコントリビュートがわからなくてGitHubの勉強を始めましたが、全然出てこなかったので最後にまとめて調べました。

インプットは終わったので明日からアウトプット頑張ります！


この記事が気に入ったらサポートをしてみませんか？