はじめに
はじめまして！@yabuuuuuuk83446(矢吹)です。AWSに本格的に取り組み始めて約8ヶ月が経ちました。そこで、インフラエンジニアでもGitでツール開発、IaCのTerraformなどのソースコードを管理し、チーム開発をするのが現状です。僕は、GitコマンドやGitHubの使用頻度があまり高くないため、バージョン管理の概要やコマンドでの操作について非常に苦戦しました。GitやGitHubを初めて使う方、また使い始めたばかりの方を対象にした記事にしたいと思います。
- 自己紹介
1994年生まれ。元公務員。公務員時代にインフラエンジニア/AWSと出会い、思い切って転職。SESを経て、現在は某クラウドインテグレータ勤務。2024年1月から本格的にAWSを使った仕事に従事し、自分の技術を上げるためにTechBullに参加。個人学習や現場でのクラウド関連の記事を執筆しております。ぜひXのフォローもお待ちしてます！
バージョン管理とは
GitやGitHubの説明に入る前にバージョン管理について説明します。バージョン管理は、プロジェクトやファイルの変更履歴を追跡し、誰が、いつ、何を変更したかの情報を記録します。これにより、何かあった時にプロジェクトを過去のある状態にも戻すことができます。そのためのツールとしてGitなどのバージョン管理システムを使用します。複数の人が同じプロジェクトで効率的に協業できます。異なる人が同じ箇所を変更した場合、システムが自動的に検出し、統合を支援します。バージョン管理の主な利点は、変更の追跡が容易になること、過去の状態に簡単に戻れること、そしてチームでの協業が円滑になることです。
Git とは
Gitは、ソフトウェア開発におけるバージョン管理ツールです。オフラインでも使用可能であり開発者のパソコン上で動作し、コードの変更履歴を順番に記録・追跡します。機能の追加や既存機能の修正といった変更内容を保存し、プロジェクトの進行状況を管理します。Gitを使用することで、開発者は変更履歴の確認が容易になり、以前のバージョンへの復帰が可能になります。また、異なる機能開発を並行して行うことができ、作業内容を安全にバックアップすることもできます。これらの特徴により、効率的なプロジェクト管理と柔軟な開発作業が可能となります。
以下Gitコマンドのhelpになります。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 |
❯❯ git -h usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>] [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path] [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch] [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>] <command> [<args>] These are common Git commands used in various situations: start a working area (see also: git help tutorial) clone Clone a repository into a new directory init Create an empty Git repository or reinitialize an existing one work on the current change (see also: git help everyday) add Add file contents to the index mv Move or rename a file, a directory, or a symlink restore Restore working tree files rm Remove files from the working tree and from the index examine the history and state (see also: git help revisions) bisect Use binary search to find the commit that introduced a bug diff Show changes between commits, commit and working tree, etc grep Print lines matching a pattern log Show commit logs show Show various types of objects status Show the working tree status grow, mark and tweak your common history branch List, create, or delete branches commit Record changes to the repository merge Join two or more development histories together rebase Reapply commits on top of another base tip reset Reset current HEAD to the specified state switch Switch branches tag Create, list, delete or verify a tag object signed with GPG collaborate (see also: git help workflows) fetch Download objects and refs from another repository pull Fetch from and integrate with another repository or a local branch push Update remote refs along with associated objects 'git help -a' and 'git help -g' list available subcommands and some concept guides. See 'git help <command>' or 'git help <concept>' to read about a specific subcommand or concept. See 'git help git' for an overview of the system. |
GitHub とは
GitHubは、Gitを基盤とするインターネット上のプラットフォームで、ソフトウェア開発プロジェクトの共有と協力作業を促進するサービスです。GitHubは中央リポジトリを提供し、開発者全員が最新のコードベースにアクセスして変更を共有できるようにします。プルリクエスト、イシュー、コードレビューなどのコラボレーション機能を通じて、開発者間のコミュニケーションと協力を支援します。また、GitHubはプロジェクト管理ツールも提供しており、タスクの割り当てや進捗の追跡、マイルストーンの設定などが可能です。これらの機能により、複数の開発者が同じプロジェクトで作業する際に、互いの変更を確認し合いながらスムーズに開発を進めることができ、チーム開発の効率を大きく向上させます。GitHub以外では、GitLabやBitbucket、AWSではCodeCommitがありますね。
主要用語解説
- リポジトリ (Repository)
- プロジェクトの全ファイル、フォルダ、変更履歴を含む保管場所
- クローン (Clone)
- リモートリポジトリのコピーをローカルマシンに作成する操作
- コミット (Commit)
- 変更をリポジトリに保存する操作
- プッシュ (Push)
- ローカルの変更をリモートリポジトリにアップロードする操作
- プル (Pull)
- リモートリポジトリの最新変更をローカルリポジトリに取り込む操作
- ブランチ (Branch)
- メインの開発ラインから分岐した独立した開発ライン
- マージ (Merge)
- あるブランチの変更を別のブランチに統合する操作
- プルリクエスト (Pull Request)
- 変更をメインブランチにマージする前に、レビューを依頼する仕組み
- フォーク (Fork)
- 他人のリポジトリのコピーを自分のGitHubアカウントに作成すること
- イシュー (Issue)
- プロジェクトのタスク、バグ、機能要求などを追跡するための機能
Git の重要概念：ワーキングツリーとステージングエリア
ワーキングツリー
- プロジェクトの現在の状態を表す実際の作業ディレクトリ
- ファイルの編集、新規作成、削除など、実際の作業が行われる場所
- ローカルマシン上に存在し、直接アクセス・操作可能
ステージングエリア
- 次のコミットに含める変更を準備する中間的な場所
git addコマンドで変更をステージングエリアに追加- コミット前の変更内容の確認と調整が可能
ステージングエリアの必要性
- 変更の選択的コミット
- コミット前のレビュー
- 部分的なファイルのステージング
- 作業の中断と再開
- コミットの整理
Git でよく使われる基本コマンド
- 既存のリポジトリをローカルにコピー
|
1 |
$ git clone <リポジトリURL> |
- 現在のブランチの状態を表示
|
1 |
$ git status |
- ブランチの新規作成
|
1 |
$ git branch <ブランチ名> |
- ブランチ一覧を確認する
|
1 2 |
$ git branch $ git branch -A |
- 指定したブランチに切り替え
|
1 |
$ git checkout <ブランチ名> |
- 変更をステージングエリアに追加
|
1 |
$ git add <ファイル名> |
- ステージングされた変更をリポジトリに保存
|
1 |
$ git commit -m "メッセージ" |
- ローカルの変更をリモートブランチにアップロード
|
1 |
$ git push origin <ブランチ名> |
- リモートの変更をローカルに取り込む
|
1 |
$ git pull origin <ブランチ名> |
チーム開発について
チーム開発におけるGitHubの活用。チーム開発でGitHubを効果的に使用するには、ブランチ戦略が必要です。一般的にはGitFlowやGitHub Flowなどのモデルを参考にしつつ、メインブランチ、開発ブランチ、フィーチャーブランチなどを適切に設定します。
チーム開発ではプルリクエストの活用が欠かせません。適切な粒度でプルリクエストを作成し、レビュアーを指定し、コードレビューを通じた品質向上と知識共有が促進されます。また、プルリクエスト時にはコードの変更理由や影響範囲を明確に説明することが重要です。
-
メインブランチ
「master」や「main」と呼ばれ、プロジェクトの主要なコードを保持し、本番環境と同じ状態を維持することが期待されます。メインブランチは、製品のリリースバージョンを表すものであり、直接このブランチで作業は行いません。他のブランチで開発を完了し、十分にテストされた後にメインブランチにマージされます。
-
開発ブランチ
次のリリースに向けた開発作業が行われるブランチです。多くの場合「develop」と名付けられます。このブランチはメインブランチから分岐し、新機能の追加やバグ修正などの開発作業が統合されていきます。開発ブランチは、個々の開発者やチームが作業を統合する役割を果たします。開発が進み、リリースの準備が整ったら、開発ブランチの内容はメインブランチにマージされます。
-
フューチャーブランチ
個別の機能開発やバグ修正のために作成される一時的なブランチです。開発ブランチから分岐して作成されます。各フューチャーブランチは特定の機能やタスクに焦点を当てており、その作業が完了するまで存続します。開発者はこのブランチで自由に実験や変更を行うことができ、他の開発作業に影響を与えることなく独立して作業を進められます。フューチャーの開発が完了し、コードレビューを通過したら、このブランチは開発ブランチ（または場合によってはメインブランチ）にマージされます。
実際の作業の流れ
- ワーキングツリーでファイルを編集
ワーキングツリーとはローカル上で行う作業場所でGitに保存（バージョン管理）する前。様々なファイルがありここでコードを編集したり、文章を書いたりすると思います。ローカルで行った変更は、まだGitに「保存」されていない状態です。 - 変更をステージングエリアに追加 (
git add)
ステージングエリアとは、ローカル上でGitが管理するエリアの一つで、ワーキングツリーとローカルリポジトリの間に位置します。git addコマンドで変更をこのエリアに追加します。
ローカル環境にあり、リモートリポジトリ（GitHub）とは独立しております。git commitコマンドの前段階として、コミットする変更を準備するエリアです。一時的な準備エリアであり、最終的な保存場所ではありません。
- ステージングエリアの内容をコミット (
git commit)
ステージングエリアに追加された変更をローカル上のリポジトリにGitに保存するのがgit commit。
git commitを実行後、git pushコマンドを使ってリモートリポジトリ（GitHub）に送信できます。
- リモートリポジトリにローカルリポジトリの内容を保存する(
git push)
git commitでステージングエリアに変更したデータを保存したら、リモートリポジトリに保存するのがgit pushです。git pushすることで、チーム開発の中心となるGithubに対してデータを共有できます。
では長くなったので、実際にGitコマンドを利用してソースコードをpushしてみましょう！
プルリクエストまでの流れ
GitHubからリポジトリをローカルマシンにクローンします。次に、新しい機能やバグ修正のために、新しいブランチを作成し切り替えます。ワーキングツリーで必要な変更を行い、その変更をステージングエリアに追加します。ステージングされた変更をコミットし、説明的なメッセージを付けます。その後、ローカルの変更（新しいブランチを含む）をGitHubにプッシュします。GitHubのウェブインターフェースで、プッシュしたブランチからメインブランチへのプルリクエストを作成します。チームメンバーがコードをレビューし、コメントや提案を行います。必要に応じて追加の変更やコミットを行い、最終的にレビューが完了し承認されたら、プルリクエストをメインブランチにマージします。
まずはGitHubとローカルで作成した鍵認証の設定を行います。
- sshで鍵の認証を行う ターミナルを開く
- ターミナルで鍵の保管場所へ移動
|
1 |
$ cd ~/.ssh |
- sshのディレクトリへ移動したら、鍵を生成する
- 実行すると
公開鍵と秘密鍵が生成されます
|
1 |
＄ ssh-keygen -t rsa |
id_rsa（秘密鍵）id_rsa.pub（公開鍵）- 生成された公開鍵の内容を表示し、文字列をコピーします
|
1 |
$ cat ~/.ssh/id_rsa.pub |
- GitHubへ移動し公開鍵を登録していく
Settingsをクリック
- 左側のメニューから「SSH and GPG keys」をクリックしNEW SSH Keyを選択
- タイトルとkeyの内容を記載していく
- 接続を確かめる
接続できれば以上でsshで鍵の認証は終了です。
|
1 |
$ ssh -T git@github.com |
初期セットアップは以上となります。
- リポジトリのクローン(sshでclone)
|
1 |
$ git clone git@github.com:username/repository.git |
git@github.com:username/repository.gitは置き換えるクローンしたいリポジトリの情報に変更すること
- クローンしたいリポジトリを選択
codeをクリック
SSHをクリック後、③をクリックしてコピー
ここからは実際にGitコマンドを利用して開発をしていきます。今回はGitHubフローを利用してmainブランチからローカルブランチを作成してpushからのプルリクエストを出します。この開発方法以外にもGitフローもありますので、次回ブログしていきたいと思います。
- ブランチの作成と切り替え
ブランチ名はなんでもいいですが、例えばシェルスクリプトのprocess.shを修正したい場合は「feat_fix-process.sh」のように分かりやすく作るのがベストです。
|
1 |
$ git checkout -b <ブランチ名> |
- ローカルでの作業:(ファイルの編集、作成、削除など)
- 変更のステージング
|
1 2 3 |
$ git add . または $ git add ファイル名 |
- コミットの作成
|
1 |
$ git commit -m "fix: 環境変数の修正" #例 |
- リモートリポジトリへのプッシュ
|
1 |
$ git push origin <ブランチ名> |
プッシュをすることで、初めてリモートリポジトリに反映される
- プルリクエストの作成:GitHubのウェブインターフェースで行う
①をクリック
②をクリックするとプルリクエストの画面に遷移
- レビューとディスカッション:GitHubのウェブインターフェースで行う
プルリクエストを行ったら、レビュワーがチェックを行います。
レビューが通ったら、変更をメインブランチにマージ（統合）という流れです。 - マージ:GitHubのウェブインターフェースで行い、Delete remote branchをする
- レビュー完了後の処理
プルリクエストを出した開発者はローカル上にあるブランチを破棄します。対象のgit branchを削除する事で作業が完了したブランチを整理し、不要なブランチによる混乱を防ぎ、開発環境をクリーンに保つことができます。
レビューからコード修正と、レビュー完了後の処理は以下となります。
|
1 2 3 4 5 6 |
修正はadd,commit,pushをする レビューOKもらったらマージボタンを押してDelete branchを押すこと $ git checkout main $ git pull $ git branch -D 好きなブランチ名(feat_xxxxxxxx) また開発したいときは git branch 好きなブランチ名(feat_xxxxxxxxx) から行う |
実際のプルリクエストの様子
マークダウンで書きましょう「#」を入れるとオートリンクが作成できます。
例えば、「#1」を関連する「#1」issueのリンクが付きます。大量のissueがあると、レビュー者が該当するissueを見つけるまでに時間がかかってしまいますので、リンクを作ってissueをすぐに確認できるようにしましょう。
- 要件を書きましょう
- 目的や何をしたのか端的に
- テスト証跡を入れましょう
- コードが実行できているか、ログなどを貼りましょう
実際のプルリクエストの例
- プレビューの様子
- レビュー者を選択は右側の「Reviews」の隣の⚙️をクリックし、レビューワーを選択、「Assignes」は自分を選択しましょう
- 最後に「Create Pull Request 」を選択
まとめ
インフラエンジニアもクラウドのみ触るだけではく、GitHubを利用して安全にコード管理をしていきましょう！次回はGitコマンドで間違えてpushしたcommitを元に戻す方法などブログを書いていきます！
ありがとうございました！
1994年生まれ。元公務員。公務員時代にインフラエンジニア/AWSと出会い、思い切って転職。SESを経て、現在は某クラウドインテグレータ勤務。2024年1月から本格的にAWSを使った仕事に従事し、資格取得ばかりだったが、自分の技術力を上げるためにTechBullに参加。個人学習や現場でのクラウド関連の記事を執筆しながらもくもく会では司会を行っている。