概要

CircleCIの設定において、ジョブの実行するブランチをfilterで制御できる。
git-flowを採用している場合、CircleCIの動作確認のブランチによって発生する利点と欠点を出してみた。

ジョブ実行対象をdevelopブランチ以降にする場合

利点

develop以降ブランチへのマージで自動実行されないため、最終的なCI/CDの待ち時間が減る。

欠点

CircleCIの動作確認のために、プルリクエストを作成する必要がある。

ジョブ実行対象をfeatureブランチ以降(無制限)にする場合

利点

CircleCIの動作確認のために、プルリクエストを作成する必要がない。

欠点

featureブランチのコミットごとにジョブを実行するため、最終的なCI/CDの待ち時間が増える。

(不要なジョブ手動で止める運用で回避可能)

はじめに

超初心者向けです。とりあえず使えるようになる情報しか記載しません。
実作業（ブランチ切る〜マージする）編です。

1. ブランチを新規作成する（ブランチを切る）

(1-1)「ブランチ」ボタンを押下。
(1-2)のウィンドウが開く。
(1-3)にブランチ名を入力すし（※日本語は不可！！）「チェック」の項目にチェックが入っているか確認。
(1-4)「ブランチを作成」のボタンを押下。

ブランチ作成と同時に作成したブランチに移動（チェックアウト）した状態になる↓

2. 修正・変更作業〜コミットボタンを押下

(2-1)各種エディタで変更を加えるとSourceTree側に変更内容が表示される。
(2-1)'変更内容の詳細も表示されるので、さらっと確認。
(2-2)左上の「コミット」ボタンを押下。

3. コミットする

(3-1)コメント記入欄が表示されるので、コメントを記入する。
※後々、履歴を検索する時にヒットしやすいコメントを意識して記入するのがおすすめ。

あわせて、変更ファイルの一覧や変更内容詳細が表示されるので、さらっと確認する。
コメント記入欄下の「コミットをただちに〜プッシュする」にはチェックを入れない！！
（慣れない内は事故を起こしやすい為。）

(3-2)右下のボタン押下。（コミット完了）

コミット完了後の画面↓

4. プッシュする

(4-1)左上の「プッシュ」ボタンを押下。
(4-2)のウィンドウが開くので、作業ブランチにのみチェックする。
※masterは絶対チェック入れない（他諸々、プロジェクト単位で要確認）

「すべてのタグをプッシュする」はタグを作らなければスルーで可。気になる場合はチェックを外す。
（初心者はタグは作らない！と思っておくのが良いです）

内容を確認して右下の「OK」ボタンをクリック。

プッシュ完了後の画面↓

5. マージリクエストを作成（gitlab ver）

SourceTreeから離れます。
お好みのブラウザで対象プロジェクトのページを開く。
(5-1)左メニューの　Repository > Branches と選択し、ブランチ一覧のページを表示する。
（左メニューがない場合はブラウザの幅を広げてみる）
(5-2)対象ブランチの「Merge request」のボタンを押下。

(5-3)タイトルテキストの入力（任意）
(5-4)コメントの入力（任意）
他、念の為、ブランチ名、マージ先ブランチのチェックをする。
(5-5)緑のボタンを押下。（マージリクエストの完了）

6. マージする

• 自分以外の作業ブランチをマージする場合、コードの添削（コードレビュー）もできるだけ行ってください。
• 複数人の修正箇所が重複（コンフリクト）していると修正するまで押せません。
• 「Delete source branch」にチェックを入れて、不要なブランチは削除してください。

(6-1)緑の「Merge」ボタンを押下でマージ完了。

※以下の画面が表示されない方は権限がない（と思う）ので、権限ある方にマージしてもらってください。

part 1 ↓
git初心者デザイナー向けSourceTreeの使い方2019（図説付き）for MAC

■問題点
git bash を使っていて、
「develop」ブランチに切り替える時、「git checkout de」でTabキーを押すと「git checkout develop」まで予測変換してくれる。

「dev-2」というブランチを適当に作ってしまい、そのブランチはマージ後削除（リモート/ローカルともに）。
しかし、削除したのにも関わらず、予測変換には相変わらず出てきてしまい、予測変換の邪魔をする。地味にイラッとする。

■解決策
「.git\refs\remotes\origin」内に、ブランチ名のファイルがある。
そのファイルを削除すると、予測変換からいなくなる。

※「.git\logs\refs\remotes\origin」内にあるファイルも消す必要があるかも

先日8/16にGitバージョン2.23.0がリリースされました。
今回の目玉機能と言えば、新しいコマンド git switch と git restore ですね！
本稿ではこちらの2つに絞ってどういう役割・位置づけの機能なのか英語ソースの引用も含めてご説明します。

TL;DL

• ブランチの変更は git switch
• ファイルの変更は git restore
• 今まで通り git checkout は使える
• 新機能は「実験的機能」なので今後変更の可能性あり

新機能が追加された背景

Highlights from Git 2.23によると、 git checkout に出来ることがあまりに多いため（ブランチ操作のほか、indexされたファイルの復旧、履歴上のファイルの取得など）、役割を明確に分けるためのコマンドが追加されたとのことです。

It turns out git checkout can do quite a lot.
(中略)
The new commands, by contrast, aim to clearly separate the responsibilities of git checkout into two narrower categories: operations which change branches and operations which change files. To that end, git switch takes care of the former, and git restore the latter.

ブランチの変更は git switch に、ファイルの変更は git restore に役割を分けています。
git 2.23.0のドキュメントを見ても、各コマンドの役割が分けられたことで分かりやすくなっています。

公式ドキュメント(英語)
git-checkout | git-switch | git-restore

git checkoutのオプション

git checkout [-q] [-f] [-m] [<branch>]
git checkout [-q] [-f] [-m] --detach [<branch>]
git checkout [-q] [-f] [-m] [--detach] <commit>
git checkout [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
git checkout [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>…​
git checkout [<tree-ish>] [--] <pathspec>…​
git checkout (-p|--patch) [<tree-ish>] [--] [<paths>…​]

git switch

git switch [<options>] [--no-guess] <branch>
git switch [<options>] --detach [<start-point>]
git switch [<options>] (-c|-C) <new-branch> [<start-point>]
git switch [<options>] --orphan <new-branch>

restore

git restore [<options>] [--source=<tree>] [--staged] [--worktree] <pathspec>…​
git restore (-p|--patch) [<options>] [--source=<tree>] [--staged] [--worktree] [<pathspec>…​]

特に git restore についてはオプションも含めて意味が明確で分かりやすくなったと感じます。

各コマンドと git checkout との比較

基本的には「機能を分けること」が目的であり、使い勝手は大きく変わらないです。

git switch

git switch はその名の通り、 checkout で行っていたブランチの変更を担当します。

# ブランチの切り替え
git checkout <branch>
git switch <branch>

# ブランチを新規作成して切り替え
git checkout -b <branch>
git switch -c <branch>

git restore

git retore はファイルの変更に使用します。ファイルを復旧させる時に使うことが多そうなので、良いネーミングですね。

# ファイルの変更を取り消す
git checkout -- <filename>
git restore <filename>

# 特定ファイルを特定のコミットの状態にする
git checkout <commit> -- <filename>
git restore --source <commit> <filename>

--worktree と --staged オプション

git restore コマンドは git reset のようにステージングエリアも変更出来るようになっています。

# ステージングエリアにあるファイルを復旧する（実ファイルへの変更はそのまま）
git reset <filename>
git restore --staged <filename>

# ワークツリー上のファイルを復旧する（実ファイルの変更がリセットされる。checkoutの例と同様）
git reset --hard <filename>
git restore --worktree <filename> # オプションがない場合、デフォルトで --worktree オプションが付きます

まとめ

個人的には git checkout の「機能全部乗せ感」がちょっと使いづらく感じていたので、今回の新機能は率先して使っていくつもりです。
ただ、これらの機能はあくまで "Experimental alternatives(実験的な代替手段)" ということなので（マニュアルにも書いてある）、今後仕様変更される可能性もありますので、使用される方は気に留めるようにしてください。