クモのようにコツコツと

フロントエンドエンジニア イイダリョウの技術ブログ。略称「クモコツ」

【GitHub】Gitコマンドでブランチ作成→プルリク→マージ→ブランチ削除の記録(Issueもあるでよ)

GitHubの続きです。前回はGitコマンド事始めでローカルにクローン→GitHubにプッシュ→GitHub Pages連携まで行いました。今回はその続きでブランチ作成→プルリク→マージ→ブランチ削除をやってみます。Issueとの紐付けも行いました。それではいきましょう!

【目次】

※参考:前回記事
【GitHub】Gitコマンド事始め(ローカルにクローン→GitHubにプッシュ→GitHub Pages連携) - クモのようにコツコツと

※参考:Web開発環境についてのまとめ
qiita.com

Issueの作成

まずGitHub上でIssueを作る。

GitHubのリポジトリ画面で f:id:idr_zz:20200724183459j:plain メニューの「Issues」をクリックすると…

「Issues」の画面になる f:id:idr_zz:20200724183641j:plain 右側の緑のボタン「New issue」を押すと

Issueの作成画面になる。 f:id:idr_zz:20200724183733j:plain 内容を入力して「Submit new issue」をクリック

Issueが作成された! f:id:idr_zz:20200724183844j:plain タイトルの右に「#1」というIssue番号が振られている。

この番号を使ってブランチを作成したい。

ブランチの作成

Gitコマンド はまたこちらの記事を参考にさせていただく。

※参考:Gitコマンド早見表 - Qiita

まず最初にリモートとローカルのリポジトリの差分がないか調べる(あったらリモートの内容をpullする必要がある)。

git diff

差分はないようだった。

次にローカルのmasterからブランチを作る。ブランチについてはいくつかのコマンドがあるが

  • git branch ブランチ名:ブランチの作成は
  • git checkout ブランチ名:ブランチの切り替え
  • git checkout -b ブランチ名:ブランチの作成と切り替え

3つ目のコマンドがブランチの作成と切り替えを同時にやってくれる。

git checkout -b '#1'

Issue番号とブランチを紐付けたいのでブランチ名にした。


なお、ブランチ名は' 'なしの状態だと…

git checkout -b #1

このようなエラーになった

error: switch `b' requires a value

下記のQAを参考にブランチ名を' 'で括ったらうまくいった。

※参考:git - Why can't a branch name contain the 'hash' (#) char at the begining? - Stack Overflow

#はターミナルではコメント開始と認識されるようだった。

ローカルのブランチをリモートに反映

下記のコマンド

git push -u origin '#1'

GitHubでリポジトリを見ると… f:id:idr_zz:20200724184036j:plain おお!ブランチの数が「1」から「2」に変わっている!

ブランチ「#1」を選択すると f:id:idr_zz:20200724184136j:plain

「master」と同じ内容が入っている。 f:id:idr_zz:20200724184232j:plain

ブランチにファイル一式を入れる

ブランチ「#1」を修正していく。

念のためブランチ一覧を確認

git branch

うむ、#1*がついているのでちゃんと選ばれているな。

* #1
  #1-my-awesome-feature
  master

これまでローカルで作ってきたメタ言語のファイル一式をコピーする。 f:id:idr_zz:20200724184549j:plain

そしてルート直下のindex.htmlは不要なので削除する。 f:id:idr_zz:20200724184655j:plain

.gitignoreファイルで除外ファイルを設定

ルート直下に「.gitignore」ファイルを作成。 f:id:idr_zz:20200724185145j:plain このファイルの内容はGitHubへのコミットから除外される。

「node_modules」フォルダにインストールされているパッケージのファイル一式はGitHubへのコミットは不要。「package.json」に情報が記載されていればnpm installコマンドのときに自動的にインストールされるため。

※参考:.gitignoreでgitにコミットしないディレクトリを管理する【node_modules】 - Qiita

.gitignoreのコード

# ディレクトリを指定する場合
node_modules/

# ファイルのパターン一致でコンパイルなどで生成したファイルを指定する場合
*.com
*.class
*.dll
*.exe
*.o
*.so

先ほどの記事を参考に「node_modules」フォルダだけでなく、自動で作られそうな拡張子の削除設定も追加した。


なお、「package-lock.json」、こちらは除外しない方がいいようだ。npm installで挙動の違いが起こって(そのバージョン番号以上の最新が入ったり)パッケージ同士の依存関係がおかしくなったりするらしい。

※参考:package.jsonとpackage-lock.jsonの運用方法について – もばらぶエンジニアブログ

ローカルの変更状況を確認

ローカルの変更を確認

git status

下記の表示が

On branch #1
Your branch is up to date with 'origin/#1'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    index.html

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        .gitignore
        dest/
        gulpfile.js
        package-lock.json
        package.json
        src/
        tsconfig.json
        webpack.config.js

no changes added to commit (use "git add" and/or "git commit -a")

和訳すると

ブランチ#1
あなたのブランチは 'origin /#1'で最新です。

コミットのためにステージングされていない変更:
(コミットされる内容を更新するには、「git add / rm ...」を使用してください)
(「git restore ...」を使用して、作業ディレクトリの変更を破棄します)
削除済み:index.html

追跡されていないファイル:
(「git add ...」を使用して、コミットされるものに含めます)
.gitignore
dest /
gulpfile.js
package-lock.json
package.json
src /
tsconfig.json
webpack.config.js

コミットに変更が追加されていません(「git add」または「git commit -a」を使用してください)

ステージングエリアに反映

作業エリアの変更をステージングエリアに反映する。git addコマンド。

git add .

.は全フォルダ、全ファイルが対象。

変更を確認すると

git status

結果

On branch #1
Your branch is up to date with 'origin/#1'.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        new file:   .gitignore
        new file:   dest/css/style.css
        new file:   dest/img/header_bg.jpeg
        new file:   dest/index.html
        new file:   dest/js/script.js
        new file:   dest/other.html
        new file:   gulpfile.js
        deleted:    index.html
        new file:   package-lock.json
        new file:   package.json
        new file:   src/ejs/base/_head.ejs
        new file:   src/ejs/block/_footer.ejs
        new file:   src/ejs/block/_header.ejs
        new file:   src/ejs/block/_inner.ejs
        new file:   src/ejs/block/_main.ejs
        new file:   src/ejs/block/_other.ejs
        new file:   src/ejs/index.ejs
        new file:   src/ejs/other.ejs
        new file:   src/json/data.json
        new file:   src/scss/base/_base.scss
        new file:   src/scss/block/_footer.scss
        new file:   src/scss/block/_header.scss
        new file:   src/scss/block/_inner.scss
        new file:   src/scss/block/_main.scss
        new file:   src/scss/setting/_mixin.scss
        new file:   src/scss/setting/_variable.scss
        new file:   src/scss/style.scss
        new file:   src/ts/modules/omikuji/kekka.ts
        new file:   src/ts/modules/omikuji/omikuji.ts
        new file:   src/ts/modules/omikuji/unsei.ts
        new file:   src/ts/script.ts
        new file:   tsconfig.json
        new file:   webpack.config.js

おお、もうコミットしても大丈夫そうだな!

ローカルリポジトリにコミット

git commit -m "メタ言語のファイル一式を追加 #1"

結果

[#1 2539e8d] メタ言語のファイル一式を追加
 33 files changed, 8411 insertions(+), 14 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 dest/css/style.css
 create mode 100644 dest/img/header_bg.jpeg
 create mode 100644 dest/index.html
 create mode 100644 dest/js/script.js
 create mode 100644 dest/other.html
 create mode 100644 gulpfile.js
 delete mode 100644 index.html
 create mode 100644 package-lock.json
 create mode 100644 package.json
 create mode 100644 src/ejs/base/_head.ejs
 create mode 100644 src/ejs/block/_footer.ejs
 create mode 100644 src/ejs/block/_header.ejs
 create mode 100644 src/ejs/block/_inner.ejs
 create mode 100644 src/ejs/block/_main.ejs
 create mode 100644 src/ejs/block/_other.ejs
 create mode 100644 src/ejs/index.ejs
 create mode 100644 src/ejs/other.ejs
 create mode 100644 src/json/data.json
 create mode 100644 src/scss/base/_base.scss
 create mode 100644 src/scss/block/_footer.scss
 create mode 100644 src/scss/block/_header.scss
 create mode 100644 src/scss/block/_inner.scss
 create mode 100644 src/scss/block/_main.scss
 create mode 100644 src/scss/setting/_mixin.scss
 create mode 100644 src/scss/setting/_variable.scss
 create mode 100644 src/scss/style.scss
 create mode 100644 src/ts/modules/omikuji/kekka.ts
 create mode 100644 src/ts/modules/omikuji/omikuji.ts
 create mode 100644 src/ts/modules/omikuji/unsei.ts
 create mode 100644 src/ts/script.ts
 create mode 100644 tsconfig.json
 create mode 100644 webpack.config.js

2539e8dがコミット番号のようだ。index.htmlの削除も行われている。

リモートリポジトリにプッシュ

前回はmasterだったが今回はブランチ名#1

git push origin '#1'

結果

Enumerating objects: 51, done.
Counting objects: 100% (51/51), done.
Delta compression using up to 4 threads
Compressing objects: 100% (43/43), done.
Writing objects: 100% (50/50), 104.42 KiB | 1.90 MiB/s, done.
Total 50 (delta 0), reused 0 (delta 0)
To https://github.com/ryo-i/frontendMetaLanguage.git
   f8a7b9b..2539e8d  #1 -> #1

うまくいっているっぽいぞ!

GitHubで#1ブランチを確認すると… f:id:idr_zz:20200724200059j:plain うおお!ファイル一式が追加されている!

「index.html」は削除され、「node_modules」フォルダは除外されている。

一方、masterを見ると、最初の状態のまま。 f:id:idr_zz:20200724200136j:plain

こうやってmasterを保持したままブランチでいろいろな修正を行うことができるわけだ。


当初、コミットメッセージにIssue番号を入れ忘れたため、後からコミットメッセージを変更した。

そしたらコミットやプッシュの変更、取り消しがうまくいかず、エラーになった。

最終的には強制プッシュの下記のコマンドでプッシュが成功した。荒技のようだが。

git push -f origin '#1'

プッシュの後に-fオプションを追加。

※参考:GitHubにpushする時にerror: failed to push some refs と表示されてpushできない時 - Qiita

修正、再プッシュ

完成したファイルのURLが「/dest」フォルダになるのでREADMEのプレビューのURLを変更。

README.md

# frontendMetaLanguage

メタ言語(EJS、Sass(SCSS)、TypeScript)で作ったWebページ。gulpでコンパイル。JSはWebpackでバンドル。

プレビュー
https://ryo-i.github.io/frontendMetaLanguage/dest/

ステージングエリアに反映

git add .

ローカルリポジトリにコミット

git commit -m "プレビューのURLを変更 #1"

リモートリポジトリにプッシュ

git push origin '#1'

GitHubの「#1」ブランチ f:id:idr_zz:20200724201726j:plain 「README.md」のコミットメッセージが変わった!

「README.md」を開くとURLが変わっている。 f:id:idr_zz:20200724211958j:plain コミットメッセージ「プレビューのリンクを追加」を開くと…

修正内容が確認できる。 f:id:idr_zz:20200724234753j:plain 赤色が修正前で緑色が修正後

「#1」のリンクを開くとIssue画面が開く。 f:id:idr_zz:20200724212312j:plain

プルリクを作成

次はmasterにマージするためのプルリクを作成する。

「#1」ブランチの画面で「Pull request」をクリックすると… f:id:idr_zz:20200724214026j:plain

プルリクエスト作成画面になる。 f:id:idr_zz:20200724214132j:plain

修正内容を入力して「Create pull request」をクリック f:id:idr_zz:20200724214209j:plain

プルリクが作成された! f:id:idr_zz:20200724214247j:plain 「#2」という番号が振られている。

コードレビュー

チームで作業している場合はここで第三者によるコードレビューが行われるはす。

「Files changed」を押すとコードの修正内容が表示される。 f:id:idr_zz:20200724214537j:plain

コードの行に直接コメントを書くことができる。 f:id:idr_zz:20200724214601j:plain

コメントにレスを返してやり取りをすることもできる。 f:id:idr_zz:20200724214637j:plain

今回は自作自演乙だけどw

masterへマージ

コードレビューの修正が終わったらブランチをmasterへマージする。

マージは修正した人が行うケースが多いようだ。

※参考:Pull Request をマージするのは誰だ - Qiita

Pull requestの下部にある「Merge pull request」を押す f:id:idr_zz:20200724214842j:plain

マージにあたりタイトル、コメントなどを入れて f:id:idr_zz:20200724215016j:plain 「Confirm merge」を押すと

マージ成功の表示が!

masterにも追加ファイルが反映された!! f:id:idr_zz:20200724215125j:plain

GitHub Pagesも表示が変わった!! f:id:idr_zz:20200724215326j:plain

※参考:メタ言語同時コンパイル(EJS、Sass(SCSS)、TypeScript)

Issueの削除

終了したIssue「#1」をCloseにする。 f:id:idr_zz:20200724215720j:plain

「#1」を開いて下の方にスクロールすると… f:id:idr_zz:20200724215727j:plain

コメント入力欄がある。ここでクローズもできる。 f:id:idr_zz:20200724215732j:plain

コメントを入力して「Close issue」を押すと… f:id:idr_zz:20200724215736j:plain

Issue「#1」がクローズになった! f:id:idr_zz:20200724215741j:plain

Issueのトップには表示されなくなったが… f:id:idr_zz:20200724215749j:plain

「Closed」のタブを開くと過去のIssueが確認できる。 f:id:idr_zz:20200724215759j:plain

これならアクティブなIssue以外はクローズしても良さそう。

ブランチの削除

次にブランチ「#1」を削除する。 f:id:idr_zz:20200724221234j:plain ブランチの削除は個人的にはこれまでの修正記録が消えてしまうようで勇気がいる作業なんだが…どのように変わるのか、迷わず行けよ、行けばわかるさ!

ブランチ「#1」の下の方にスクロールすると「Delate branch」のボタンがある。 f:id:idr_zz:20200724221238j:plain

クリックするとブランチが削除できる。 f:id:idr_zz:20200724221243j:plain 間違って削除した場合は「Restore branch」で復帰できるようだ。

削除した結果、プルリクの「close」の方には引き続き修正の履歴が残っている。 f:id:idr_zz:20200724221248j:plain

しかし「Code」画面のブランチ選択からは「#1」が消えている。 f:id:idr_zz:20200724221253j:plain

ほっ。修正履歴が残るならアクティブなブランチ以外は削除しても大丈夫そうだ。

「Insights」の「network」も確認。 f:id:idr_zz:20200724221821j:plain 「#1」ブランチが「master」から分岐してマージされた記録はここにも残ったまま。

ローカルのブランチも削除

最後にローカルリポジトリのブランチも不要なので削除する。

ブランチ「#1」がアクティブだと削除できないっぽいのでmasterに切り替える。

git checkout master

ブランチ削除を実行

git branch -d '#1'

結果

warning: deleting branch '#1' that has been merged to
         'refs/remotes/origin/#1', but not yet merged to HEAD.
Deleted branch #1 (was 72910a8).

警告:マージされたブランチ '#1'を削除しています
「refs / remotes / origin /#1」ですが、まだHEADにマージされていません。
ブランチ#1を削除しました(72910a8でした)。

ブランチの状態を確認

git branch

結果

  #1-my-awesome-feature
* master

「#1」ブランチは消えてmasterが選ばれている。

「#1-my-awesome-feature」ってのが残っている。これはなんぞ?

消してみるか。

git branch -d '#1-my-awesome-feature'

再度確認してみる。

git branch

うむ、消えた。

* master

ローカルのリポジトリを削除した後、ふとローカルのファイルを見るとgulpの設定ファイルなどがゴソッとなくなっている!

幸いリモート(GitHub)のファイルは無事だったのでpullで同期したら復旧した。ほっ。。

git pull origin master

ちょっとこの現象がどの段階で起こったのかよくわからず。。今後も注意深く観察していきたい。

最後に

ということでブランチの作成、プルリク、マージに成功し、Issueのクローズ、ブランチの削除も行いました!

ブランチの削除って結構勇気が必要な処理だったんですが、やってみると修正の記録は残っていて、ブランチの選択メニューから消えているだけだったので安心しました。

Gitコマンドはまだ慣れませんが、これからもなるべくSourceTreeを使わず、慣れて行きたいと思う所存です。

それではまた!


※参考:Web開発環境についてのまとめ
qiita.com