はじめに
投稿者の私自身、業務で未だにGit, GitHubを利用したことがないのですが、
個人でWebアプリを開発し始め、ソースのバージョン管理をGitHubで管理することにした。
今後、開発中のWebアプリ開発を自身の所属する会社のメンバーにも展開しようと思っています。
その時の為に、個人でissueを上げたり、issueに対応するためのbranchを作ったり、pull-request
をしてmargeしたりしたので記録として残しておきます。
前提
- GitHubのアカウントは作成済み
- GitHub上にプロジェクトのリポジトリは作成済み
- 自分のマシンにGitがインストール済み
環境
- Windows10 Home
- Git操作(Git Bash)
参考サイト
操作方法(Git)
- リモートリポジトリ(GitHub)からmasterブランチをローカルに取得する
GitHubのリポジトリ画面の[Clone or download]を押下してリポジトリURLを取得し
下記コマンドを実行する。
予めローカルリポジトリを作成するディレクトリを作成し移動しておくこと。
下記コマンドを実行すると、初回にGitHubのログインフォームが表示され、
その後OpenSSH認証？の為、GitHubユーザー、パスワードが順番に聞かれる。
git clone <リポジトリURL>
cloneが正常終了すると所定のディレクトリにローカルリポジトリが作成されます。
さぁ、ここからチーム開発を実施しましょう。
- ブランチを作成する
issueに対応する時など、masterブランチで作業せず、対応するissue用のブランチを作成して作業をします。
git branch <ブランチ名>
- ブランチを切り替える
ブランチを作成しただけでは、まだ作業ディレクトリの内容は元のブランチままです。 以下のコマンドを実行し、作業ディレクトリの内容を指定のブランチの内容にしましょう。
git checkout <ブランチ名>
上記ブランチ作成とブランチ切り替えを同時に行うには以下のコマンドです。
git checkout -b <ブランチ名>
- 作業ディレクトリがどのブランチなのかを確認する
masterブランチとissueに対応するブランチなど、複数のブランチがある場合、現在の作業ディレクトリがどのブランチのものなのかを確認するコマンドです。
ブランチ一覧が表示され、ブランチ名の横に*が表示されているものが現在のブランチになります。
git branch
- ブランチを削除する
issue対応で作成したブランチなどで、対応が完了しmasterへのmargeも行われたものは削除します。 margeが行われていないブランチを削除しようとすると警告が表示され、強制的に削除する方法が提案されます。
但し、このブランチ削除はあくまでローカルリポジトリからの削除となります。
git branch -d <ブランチ名>
- ローカルでのブランチ削除をサーバーリポジトリに反映する
上記で記載したgit branch -d <ブランチ名>を行っただけでは、サーバーリポジトリに保持している同ブランチは削除されていません。
それを削除するには以下のコマンドを実行します。
git push --delete origin <ブランチ名>
- リモートリポジトリ(GitHub)から最新の情報を取得する
他のメンバーが修正しリモートリポジトリに反映した情報は、自分のローカルリポジトリに自動では反映されません。
下記コマンドで最新の情報を取得します。
git fetch
- リモートリポジトリから取得した最新情報をローカルのブランチに反映する
上記git fetchしただけでは、まだ自分のローカルリポジトリは変更されていません。 取得した最新情報をローカルリポジトリに反映するには、以下のコマンドを実行します。 この際、取得した最新の情報に含まれるソースファイルと、自分がローカルリポジトリで修正していたファイルが同じ場合、コンフリクト(競合)が発生します。 その場合はマージが必要となりますが、今回はコンフリクトが発生していないと仮定します。
git pull
ここから以下の操作については、リポジトリ内のファイルに対して行う操作となります。
その前にgitでのファイルステータスについて記載しておきます。
下記画像は、参考サイト:GitBookの【2.2 Git の基本 - 変更内容のリポジトリへの記録】から抜粋したものとなります。
画像を見るとファイルには4つの状態があることが分かります。
このファイル状態を理解した上で以降の操作説明を見たほうがイメージがつくと思います。
| ステータス | 状態説明 |
|---|---|
| Untracked | リポジトリで管理されていない |
| Unmodified | 変更されていない |
| Modified | 変更されている(ローカルリポジトリにコミットされているファイルと比較して) |
| Steged | ローカルリポジトリへのコミット待ち |
- ファイルの状態を確認する
どのファイルが変更(modified)されているか、そもそもリポジトリで管理されていない(untracked)かなどがわかります
git status
- ファイルを管理対象として登録する
新規追加されたファイルはまだリポジトリで管理されていない状態(untracked)なので、 まずはリポジトリに登録しましょう
git add <ファイル名>
ステータス=untrackedのファイルを登録するために上記コマンドを行いましたが、それ以外にも作業ディレクトリでプログラムを修正したものをステージ状態にするためなどに使用します。
上記コマンドを行うと、ファイルの状態は"Staged"になります
- 変更をローカルリポジトリにコミットする
状態=Stagedのファイルをローカルリポジトリにコミットする
--ファイル名を指定してコミット
git commit -m "コミットコメント" <file1> <file2>
--Staged状態のファイル全てをコミット
git commit -m "コミットコメント" -a
- 変更を取り消してリポジトリのファイルで上書きする
状態=modifiedのファイルをリポジトリの状態に戻したい場合に使用します。
git checkout <ファイル名>
git add後(状態=staged)のファイルを取り消すには、下記コマンドで一旦staged → modifiedにした上で取り消します。
git reset <ファイル名>
- リモートリポジトリ(GitHub)に反映する
ローカルリポジトリにコミットされている情報をリモートリポジトリ(GitHub)に反映する。
git push origin <リポジトリ名>
GitHub画面での操作
GitHub画面でのissue作成、pull-request作成、レビュアーのレビュー＆マージについて記載します。
Gitコマンドでも可能だと思いますが、現時点ではまだ実施していないので...
- issueを作成する
開発プロジェクトでのToDoリストのような使い方をしていることも多いのではないでしょうか。
プロジェクトのissuesを選択し、New issueから新規issueを追加します。
追加後
- プルリクエスト作成する
issueに対応したブランチをGitHubにpush後、そのブランチの変更内容をmasterブランチにmargeしてもらうため、プルリクエストを作成します。 GitHub上でマージしてもらいたいブランチに切り替え、[New Pull request]を押下してプルリクエストを作成します。
- プルリクエストの内容をレビューしmasterブランチにマージする
プルリクエストが作成されると[Pull requests]に表示される。 プルリクエスト画面のコミットコメント[下記画像だと"supports iss3"]を押下すると、 変更内容が表示されるので、ソースレビューを実施します。 問題なければマージを実施します。 今回のケースではマージ対象のソースファイルにコンフリクト(競合)が発生していないため、 ボタンぽちーでマージされます。 コンフリクト発生時の対応は後日更新予定とします。。。
以上となります。
私自身、未だ業務でGit及びGitHubを利用していないため、自分なりの理解で記載しました。
もし間違いなどがあれば指摘いただけると幸いです。
なお、各種Git CLIですが、オプションも色々とありますが今回は記載していません。
今後そのへんも記載できたらいいなぁと思っています。