howto-use-git-github.md

バージョン管理の基礎

現代のソフトウェア開発では、プログラムなどのテキストファイルを管理する方法としてバージョン管理ソフトウェアが使われる事が一般的となっている。

バージョン管理を使うことで、

• 変更の巻き戻し
• 複数人での開発

等が容易になる。

バージョン管理をする際はバージョン管理システム(VCS)を使う事が多い。

広く使われているVCSとして

• Mercurial
  Firefoxのコード管理で使われている。

• Subversion
  集中型のVCS。

• Git 最も広く使われている分散型のVCS。

集中型と分散型

集中型はネットワーク上にあるリポジトリへ複数人が同時にアクセスして変更を適用させる形式。 そのためオフライン状態の時は変更を取得・反映できない。

分散型はローカルとリモートの2つのリポジトリを持つ形式。 オフライン状態の時でも変更をリモートリポジトリへ反映させたり、 複数のリモートリポジトリを用いて運用する事も可能という違いがある。

リポジトリ(Repository)

ローカルとリモートの2種類のリポジトリがある。

ローカルリポジトリは個々人のマシンにあるリポジトリで、 メンバーはコードの変更をまずこのリポジトリに適用する。

リモートリポジトリはネットワーク上にあるリポジトリで、 メンバーはgit pushコマンドを用いてローカルリポジトリに施した変更をリモートリポジトリに適用する。

他のメンバーはgit pullコマンドを用いてリモートリポジトリに施された変更を自身のローカルリポジトリに適用させる。

ブランチ(Branch)

Gitには別々の変更を適用したコードを平行して管理するためのブランチという機能がある。

これを使うと、

• 機能Aを実装するfeat-aブランチ
• 機能Bを実装するfeat-bブランチ

という風に機能ごとにコードを分けつつ同時にコードに変更を加えられる。

非常に便利な機能であると共に、マージコンフリクト(merge conflict)等の問題を引き起こすのでgitの中でも扱いが難しい機能でもある。

Gitを使ったプロジェクトではGit FlowやGitHub Flowと呼ばれるマージの運用プラクティスをベースにした運用を行うことが多い。

個人的にはGitを使い始めたばかりで慣れない時は、これらブランチの機能を使わずにmainブランチに全ての変更を適用させる運用でも良いと思っている。

GitHub

GitHubはGitHub社が運営する世界最大のGitホスティングサービス。 その他のホスティングサービスとしてBitbucket, GitLab, sourcehut, Codeberg等がある。

その他のホスティングサービスについて

特にBitbucketはGitHubがプライベートリポジトリの制限がなくなる以前からプライベートリポジトリを無料で使えたため、 企業が採用しているケースが多い。 GitHubにも商用利用のためのエンタープライズプランが存在するが、(用途が用途なため)使っている企業はほとんど見かけない。

先述したリポジトリの話だとリモートリポジトリを担当する。

通常GitのリモートリポジトリはGitを使用しているユーザー自身がサーバーを運用する必要がある。 (つまり、GitHubを使わないとGitが使えないという訳ではない)

しかしGitHubを用いるとそのサーバーの管理をする事なく開発に集中できる。

またGitHubにはIssueやPull Requestなどコラボレーションのための機能が複数備わっていて、 通常のGitサーバーを使用して開発するより効率的に開発できる。

OSSのGitサーバーについて

なおGitHub等のサービスを使わず、素のGitサーバを使う場合はmailing listとpatchを使って開発する。 今でもその手法を取っているソフトウェアは存在する。(例: Emacs)

GitLab等OSSで開発されていて自身でホスティング可能なGitサーバーも存在している。 (例: Gitea, Gogs)

GitHubとも遜色ない機能を使用できるので、自身でホスティングしたい場合はまずこれらのソフトウェアを使用するのがベター。 これらのソフトウェアはGitHubが使用できない(主にアメリカのサイトへのアクセスを禁止されている/している)国で使用されている事が多い。

コマンド操作

コマンド	操作
git add	ファイルの追跡開始/変更の追加
git commit	コミットの作成
git push	リモートリポジトリへコミットを適用
git pull	リモートリポジトリにある変更必要条件をローカルリポジトリへ適用

GitHub CLIを用いてローカルリポジトリを公開する方法

Important

GitHubリポジトリを作成している前提で進めていく

まずGitHub CLIをインストールする。 Windowsならwingetでインストールできる。

winget install -e --id GitHub.cli

まずGitHub CLIでログインする。

gh auth login

プロンプトが表示されるので以下の項目を選択する。

• GitHub.com
• HTTPS
• Login with a web browser

以下のようなメッセージが表示されるので、BA3C-7D14にあたるテキストをコピーしてEnterを押す。

! First copy your one-time code: BA3C-7D14
Press Enter to open https://github.com/login/device in your browser...

ブラウザで認証のためのページが開くので、そこに先程コピーしたテキストをペーストする。 GitHub CLIからアカウントへの許可を求めるページが開くので許可する。

ターミナルに戻って認証が成功した旨のメッセージが表示されていればログインは完了。

最初のGit commit

リポジトリの作成

まずGitリポジトリを作成する。

git init

ファイルに変更を加える

任意のファイルに変更を加える。

# Linuxでの実行例
echo "hello!" > sample.txt

ファイルを追跡(Tracking)する

sample.txtを追跡対象に加える。

なおGit管理下にないファイルをGit管理下に加える事をトラッキング(Tracking)、 Git管理下にあるファイルに変更を加えた状態をコミットに追加する操作をステージング(Staging)と呼ぶ。

git add sample.txt

コミット

コミットを行う。 この際コミットメッセージを編集するためのテキストエディタ(特に設定していない場合デフォルトで使っているエディタが使われる。大抵はVSCode)が起動するので、 それを使ってコミットメッセージを編集する。 保存して終了すればコミットが完了する。

git commit

Tip

--allow-emptyオプションを使用するとファイルに変更を施していなくともコミットが可能。 最初のコミットを空コミットにするというプラクティスもある。

リモートリポジトリの作成/プッシュ(push)

Caution

2020年からGitHubの新規作成されるリポジトリのデフォルトブランチがmasterからmainへと変更になった。 これに伴いローカルリポジトリを公開する際に Publickeyの該当記事 もしローカルリポジトリのブランチ名がmasterになっている場合(git branchで確認できる)はgit branch -m master mainを実行してブランチ名を変更する。

gh repo create

プロンプトが表示されるので、その指示に従ってリポジトリを作成する。 この際既に変更がコミットされていればそれも自動的にpushされる。 また、リモートリポジトリの登録などが自動で行われる。

変更をリモートリポジトリへプッシュ(Push)

ローカルリポジトリへ変更を適用できたので、次はその変更をリモートリポジトリへ 適用させる。

git push 

# 最初のコミットを行う場合は以下のコマンドを使用する。
git push -u origin main

他者がリモートリポジトリに施した変更をリモートにプル(Pull)

リモートリポジトリの変更をローカルリポジトリに適用するにはgit pullコマンドを使用する。

git pull

リモートリポジトリを作成した後の開発サイクル

リモートリポジトリを作成した後は以下の手順で開発を進めていく。

• プルをしてリモートの変更をローカルリポジトリに適用させる 始めにこれをしないと他者の変更と自身の変更がバッティングしてコンフリクト(Conflict)の 原因となる。(詰む訳ではないが解消が面倒)

• ファイルをステージング/トラッキングする(Staging/Tracking)
  どちらもgit addで行なう。

• コミットを行う

• プッシュする