Loading [MathJax]/extensions/tex2jax.js

初心者による初心者のためのGitHubコード管理

こんにちは。新人の加藤です!

前回投稿時は絶賛研修中でしたが、現在は初めての案件に入り、日々精進しております。
案件では、クラウドのリソース管理をIaC上で行っており、コードも含め全てGitHub上で管理を行っています。
今回は、そのGitHubについて色々とつまづいてしまった部分が多かったため、初心者による初心者のためのGitHubの情報共有を行えたらと思います!
何となくでGitHubを使用している方やこれから使用する人の手助けとなれば幸いです。

GitHubとは

そもそもGitHubとは

GitHubとは、Gitをオンライン上で設置し、世界中からファイルを参照/編集できるようにしたWebサービスのことを指します。では、Gitとはどのようなものなのかを説明していきます。

Gitとは、プログラムのソースコードやCloud Formationのテンプレートファイルなどの変更履歴を分散型で管理することができるシステムです。
従来までは1つのメインとなるディレクトリで中央集中的にコードを管理していましたが、その状況だとユーザ同士が同時にファイルを編集してしまうと、ファイルの競合などが起こりやすい環境でした。
分散型で処理をするようになったおかげで、ユーザが個々にディレクトリを持ち、変更履歴を管理できるようになりました。

Gitの特徴として以下が挙げられます。

  • ファイルの変更履歴を管理することができる
  • ユーザ同士が同時にコードを参照し、作業することができる
  • 過去のバージョンに戻すことができる
  • 自分用の作業環境(ブランチ)を作成することができる

このような特徴があるため、チームで開発する際にコードを管理する道具としてGitHubが優れているわけです。

Gitの構造

Gitの構造を紹介する前に、リポジトリとリモートリポジトリ、ローカルリポジトリという言葉だけ先に紹介します。

  • リポジトリ
    ファイルや変更履歴を管理するためのストレージ
  • リモートリポジトリ
    Web上に置かれ、複数のユーザが参照する最もメインのリポジトリ
  • ローカルリポジトリ
    個々のユーザのPC上に置かれるリポジトリ

ユーザはリモートリポジトリからメインとなるソースコードやファイルを自身のローカルリポジトリに持ってきて、そこでファイルの編集や追加を行います。このような構造となっているため、個々がファイルの編集を行っても、他のユーザが参照するメインのリモートリポジトリには影響がないため、競合が起きにくくなります。

Git構造

 

Gitの基本的なアクション

では実際はどのようにして、リモートリポジトリで管理されているファイルやフォルダを持ってきて、どのようにしてローカルリポジトリで自身が編集したファイルをリモートリポジトリに上げるのでしょうか?

それはGitの基本的なアクションである「pull」「add」「commit」「push」をすることによって実現することができます。以下に図と共にそれぞれのアクションについて説明します。

Git基本アクション

ワークツリーとは、ユーザが編集している作業場所
インデックスとは、ローカルリポジトリとワークツリーの間の中間領域

【pull】
リモートリポジトリの内容をローカルリポジトリに持ってくること。
<コード>

【add】
ワークツリーで編集したファイルをインデックスに移すこと。簡易的に述べると、自身の作業場所からローカルリポジトリに保存したいファイルを選択すること。
<コード>

【commit】
addで選択したファイルをローカルリポジトリに反映させること。
<コード>

【push】
ローカルリポジトリの変更内容をリモートリポジトリに反映させること。
<コード>

ブランチについて

ブランチとは、1つのメインのプロジェクトとは異なる分岐を作り、プロジェクト本体に影響を与えずに開発を行える機能のことをいいます。例えば、メインのプロジェクトからブランチAとブランチBをそれぞれ作成することにより、ブランチAでは機能Aの開発をしブランチBでは機能Bの開発をする、という住み分けが可能になるということです。具体的なイメージは下記の通りとなります。

ブランチ概要

ブランチ、リポジトリのどちらも各ユーザが個別にファイルを変更できるようにした機能という観点では変わりはないですが、管理対象が明らかに異なります。リポジトリには複数のブランチを含めることができ、プロジェクト全体(ディレクトリとファイル)を管理しており、ブランチはリポジトリのバージョンを管理しています。

リポジトリとブランチの関係

よく使用するコマンド

よく使用するコードについて、下記に記載します。

git clone <リポジトリのURL> 対象リポジトリのデフォルトブランチをローカルリポジトリに作成する
git clone -b <ブランチ名> <リポジトリのURL> 対象リポジトリの対象ブランチをローカルリポジトリに作成する
git branch  ローカルブランチの一覧を出力する
git branch <ブランチ名> 対象ブランチを新規作成する
git checkout <ブランチ名> 対象ブランチに切り替える
git checkout -b <ブランチ名> 対象ブランチを新規作成し、切り替える(git branchとgit checkoutをまとめて行える)
git status 変更したファイルの一覧を出力する
git fetch <リモートリポジトリ名> <ブランチ名> 指定したリモートレポジトリの指定したブランチのみの最新のコミット履歴を取得

git fetch <リモートリポジトリ名>

指定したリモートリポジトリの最新のコミット履歴をまるごと取得

git merge <ブランチ名>

現在の作業ブランチに指定したブランチの内容を取り込む
git reset HEAD <ファイル名> インデックスにある対象ファイルをワークツリーに戻す(git add <ファイル名> を取り消す)
git reset HEAD インデックスにある全ファイルをワークツリーに戻す(git add -a を取り消す)

まだまだこれ以上にコマンドはあるのでぜひ調べてみてください!

GitHubを使用した開発の流れ

ブランチとリポジトリを組み合わせた、主な流れは以下のようになっています。

  1. リモートリポジトリからローカルリポジトリにフォルダやファイルを持ってくる(git clone)
  2. 開発用ブランチの変更(git branch)
  3. ブランチを切り替える(git checkout)
  4. ファイルの編集
  5. 編集したファイルの確認(git status)
  6. コミットしたい対象ファイルを選択(git add)
  7. ローカルリポジトリに対象ファイルをコミット(git commit)
  8. リモートリポジトリにローカルリポジトリの内容をプッシュ(git push)
  9. 自分が作成したブランチを開発で使用しているメインのブランチに統合
    このとき、プルリクエストというメインのブランチに統合していいか許可をもらうリクエストを提出する

上記の流れで開発を進めることで、ひとつのリポジトリで複数人のユーザが同時にファイルを編集し、バージョンを管理することができます。

注意点

下記に私がGitHubを使用していて疑問に思ったことや注意点をつらつら書いていきたいと思います。

git pullとgit fetchの違い
どちらもリモートリポジトリの内容をローカルリポジトリの持ってくるという意味では違いはありません。ではどこに違いかあるのかというと、持ってきたデータをどこに保存するかです。実は、リモートリポジトリにあるブランチ(リモートブランチ)からローカルリポジトリにあるブランチ(ローカルブランチ)に内容を同期する際には、直接ローカルブランチの内容を書き換えるのではなく、2つのブランチ間にある「リモート追跡ブランチ」の内容を更新し、そこからローカルブランチを更新しています。git fetchはそのリモート追跡ブランチの内容を更新するコマンドで、その後にgit mergeを実行することによってローカルブランチの内容が更新されます。一方で、git pullはgit fetchとgit mergeを合わせたコマンドです。
コミットする際にはコメントをつけよう
今まで私はコミットする際にコメント内容を変えずに、コミットしていました。リポジトリを使う人が自分自身だけなら中身を見ればすぐ分かるので問題はないのかもしれませんが、Gitは複数人で開発する際に最も有用なコード管理ツールのうちの1つです。自分だけではなく、他の方もリポジトリの更新内容やその修正差分を見ます。それらが分かるように“git commit -m <コメント>”で絶対コメントをつけるようにしましょう。
競合が起きた際の解決策
チームで開発をしている際に自身の作業内容をマージさせるためにプルリクエストを行うと、競合が発生することがしばしばあります。私も研修で初めて競合が出た際にはどうしたらいいか分からず、適当に「Resolve conflicts」ボタンをポチって直していました。後々調べてみるとあれは実は裏で、どのコミットを優先的に反映させるかを選び、マージをしていたそうです。基本的には、あなたのブランチの変更だけを保持したいか、他のブランチの変更だけを保持したいか、あるいは両方のブランチからの変更を取り入れられる新しい変更を作成するかの3つから選択します。基本的にはボタンを押せば解決するかもですが、どのコミットを優先するべきなのか考えるためにも、競合が発生した場所同士を把握することが最も大切です。

おわりに

研修では、AWS CodeCommitを使用してコードを管理していましたが、その際にはGitについてよく分からないまま、手順書通りにコマンドを打っていました。今回、このブログを通してGitについて調べ自身でまとめることにより、どこで何をしているのかが明確になり、Gitを使用する嬉しさみたいなものが理解できるようになりました。現在の案件ではコードの管理だけではなく、タスクの管理までGitHubで行っているのでそれについても調べていきたいと思います。

前回の投稿では、「AWSのナレッジ共有をします」といっていたにも関わらず、もはやクラウドの内容でもなかったので次こそはAWSの内容を投稿します!

著者について

テクノロジーサービス部 第一課に所属している入社1年目の新人です。

加藤祐をフォローする

クラウドに強いによるエンジニアブログです。

SCSKでは、自社クラウドと3大メガクラウドの強みを活かし、ハイブリッドクラウド/マルチクラウドのソリューションを展開しています。業界の深い理解をもとに、お客様の業務要件に最適なアーキテクチャをご提案いたします。サービスサイトでは、お客様のDX推進をワンストップで支援するサービスの詳細や導入事例を紹介しています。

アプリケーション開発ソリューション
シェアする
タイトルとURLをコピーしました