■出典： [Git] Gitで用いるGit-Flowまとめ

目標

このポストでは、Git Flowの概念と必要性、作業にとって理解が必要な機能の用語と全体的な進行の流れについて説明します。

目次

1. Git Flow
2. Git Flowを考慮したきっかけ
3. 事前準備
4. Branch
   ①Branchのライフサイクル
   ②Branchの命名規則（Naming Convention）
   ③Branch作業に必要なコマンド
5. Merge
   ①Branchマージ（merge）際、mergeの方向
   ②Conflict減らし方
   ③Conflictが出た状況の対策
6. Pull
7. Pull Request
8. まとめ

1. Gitフロー

Git flowとは、Gitのブランチ_branchを活用して、実行する作業の流れだと言います。どのような種類のブランチを作成して、一緒にマージ_mergeすべきかを方法論的に提案します。

■参考
Vincent DriessenのA successful Git branching model
：https://nvie.com/posts/a-successful-git-branching-model/

2. Git Flowを考慮したきっかけ

複数の人とチームとして長期開発をする場合、運用ルールを定めずにGitを使用すると、競合_conflictが度々起こるし、マージ_mergeのミスなどのハプニングがよくあります。Gitを使用するときに発生するミスを減らすために採用する案が「Git flow」です。

3.事前準備

1）複数の人が共有することができるリモートリポジトリ_{remote repository}を作成し、プロジェクトのソースコードをアップロードします。
2）必要があれば「.gitignore」を作成します。
3）ローカルPC上で動作するローカリポジトリ_{local repository}を作成し、リモートリポジトリのプロジェクトをcloneします。

*「 .gitignore」
：変更履歴を無視したいファイルやディレクトリをまとめておいたリストです。リスト内のファイルおよびディレクトリの変更は、git addの際スキップされます。（しかし、思ったより適用ができない場合がよくあります。）

4.ブランチ

Branchは  master、release、 develop、feature、hot-fixで、5つの開発実行ポイントを区分して進行します。

• feature
  ...... 個別機能の実装とバグを解決するブランチ
• develop
  ...... リリースのための開発を進めているブランチ
• release
  ...... リリースの前に活用するブランチで、最小限の調整だけするブランチ
• master
  ...... 最上位のブランチで、プロジェクトを格納します。原本ソースコードを保存するため、ソースの修正をしない
• hot-fix
  ...... リリースが終わったプロジェクトの緊急修正対応（バグ等）をするためのブランチ

Masterブランチの場合は、プロジェクトのバージョンをTagで付けてプロジェクトのバージョンを管理します。

①Branchのライフサイクル

1. 一度生成がされると、削除されないブランチ
   ：master、develop
2. 目的にとって使用された後に削除されるブランチ
   ：feature、release、hotfix

②Branchの命名規則_{Naming Convention}

： "[branch name] - [日付、あるいはバージョンなど]"
（ex：realease-1.2もしくはdev01-200730）

③Branch作業に必要なコマンド

$ git checkout master 
 //「master」branchに切り替え
（check out：現在のユーザが関与しているbranchで他のbranchへの移行）
$ git merge --no-ff release-1.2 
//「merge」（branchのマージ* merge方向については、4番（Mergeについて）を参照）
$ git tag -a 1.2 
//バージョン名などのプロジェクトの説明を付ける

5.Merge

ブランチ間の変更事項を1つのブランチに結合することを言います。

_{gitチュートリアルに示されているmerge状況}

上記の状況を解決するプロセスは、チュートリアルを参照してください（ブランチとMergeの基礎）

①Branchマージ_merge時、マージの方向

[Case]
hotfixブランチを作成して、バグを正しく直したのかを確認し、
最終的に運用環境にリリースするためにhotfixブランチをmasterブランチにマージ_mergeする状況

git merge コマンドで次のようにします。

$ git checkout master // branchのヘッドをmasterへ置く
$ git merge hotfix

masterのソースを元にしたhotfifxブランチのソースコードに、最新のコミット_commitを持ってくるため、マスターにヘッドを置いてhotfixとマージします。このようなマージをfast-forwardです。

②Conflict減らし方

Conflictは、mergeする際に発生するソースコード間の衝突です。

• 開発開始前に、最新のソースをpullして取得します（pullは6番を参照）
• 適正な時期にmergeをします（merge時期を遅らせるとconflictの修正が多くなるので）

masterブランチの変更を継続的に自分のローカルブランチに更新することが重要で、更新した後に自分のブランチをマージすれば衝突を最小限に抑えることができます。

③Conflictが出た状況の対策

• <基本>衝突された部分を修正することができる場合には、コードを変更した後、結合を試みます。
• マージする前の状態に戻します。

$ git merge --abort

• コードを変更した後、マージする前に戻したい場合

$ git reset --hard HEAD

以外にもrevert _{（コミット後の記録を残したままマージ前に戻す）}、reset _{（コミット後の記録を残さず、マージ前に戻す）}のコマンドがあります。

マージが終わったら、あるブランチの中で必要ないものを削除します。

6.Pull

pullコマンドは
1）fetch _{（リモートリポジトリの変更をインポートして、マージはしないこと）}を実行した後、
2）マージ_mergeするコマンド
です。

• pull：リモートリポジトリのコミット_commit履歴と私のローカルリポジトリのデータを結合したい時
• fetch：リモートリポジトリのコミット履歴だけを確認したい時
  （このとき、リモートリポジトリから取得した最新のコミット履歴は、自分のローカルリポジトリに「FETCH_HEAD」でインポートします。）

したがって、コミットされていない変更があるままでPullをしたら、マージが失敗することになりますので注意してください。

7.Pull Request

Pull Requestとは、チームプロジェクトを進める際、開発者のローカルリポジトリの変更を他のメンバーに共有することです。ソースコードの変更内容を見やすく表示し、マージ予定事実をお知らせします。また、ソースコードのマージのコミュニケーションを行うことができ、問題発生時の履歴も確認することができます。

[開発時に進行されるPull Requestプロセス]

1. [開発者]機能の追加などの開発を進めます。
2. [開発者]機能追加が完了したら、pushします。
3. [開発者] Pull Requestを作成します。
4. [担当者] Pull Requestで変更を確認します。
5. [担当者]ソースコードの問題がなければマージします。
   もし、確認の結果、ソースコードのマージが必要ない場合には、クローズします。

8.まとめ

Git Flowは、チームとして長期開発をする際に必要な効果的なプロジェクトのバージョン管理戦略です。

• 開発が終わったソースコードを無理なくマージし、正しく動作するソースコードをリリース環境のブランチで管理することを目指しています。
• developブランチのソースコードをrelease直前の状態で管理するのに無理がある場合は、中間検証のためのStagingのブランチを作成してリリース直前のソースコードを管理する方法があります。
  （staging用ブランチを作成するのは、開発に集中ができる環境を構成するという利点があります。）
• Gitの操作を開始する前に、各作業の予想順序をシートにまとめた後作業に入れば、ミスを減らすことができると思います。

今日学んだGit情報を、Outputするだけの簡素な投稿。?
今後Gitを学ぶときの為の、自分用リンクとかも貼る。

　ターミナル、要らないのかな。

先程、こちらの記事を読みました。
Xcode9時代のゆるふわGitHub生活

先日こんな記事を書いたけど、やはりコマンドは要らないのかな。
GitHub奮闘記②【手順まとめ】

でも、iOS以外の場合や、Xcode内の Git機能でも出来ないこともある場合を考えると、
コマンドは依然必要だったりするのでしょうか。

ご意見あればコメントください。

　鍵作成。

リモートリポジトリへのアクセス権限がなく失敗したので、鍵作成しました。
とても簡単に出来た。?

Permission denied (publickey). fatal: Could not read from remote repository. 

　「鍵」とは

公開鍵（英：public key）とは?

　作成手順

【git エラー解決策】Permission denied (publickey).

　git pullは使う必要がないらしい。（fetchとmergeを使う）

pull = fetch + merge origin/master

git fetchの理解からgit mergeとpullの役割

Git pullを使うべきでない３つの理由

git fetchと git merge [リモートブランチ] で最新版を取得する。

コマンドは増えますが、より「今自分が何をやっているのか」という事が明確になり、

初心者キラーのConflictが起きた時も、具体的に何と何が衝突しているのか分かりやすくなります。

Gitの理解も深まるので、ぜひfetch - mergeの手順を覚えましょう！

　UserNameと、Nameの違い。

左側のプロフィール欄にて、

Kazuki Matsumotoが「Name」で、
kazuki-userが「UserName」です。

　結論。

• UsernameはID、
• Nameは本名やニックネーム。

　細かく。

• Usernameは重複不可で、ユーザー識別子としてプロフィールページのURLなどにも。
• Nameは重複可で、システム的にはユーザー検索時くらいにしか使われていないらしい。

　ちなみに。

GithubのリポジトリURLは、https://github.com/アカウント名/リポジトリ名の形で構成されています。

おしまい。

単刀直入に

Personal Access Tokensの設定をしなければならない。
まずサイドバーのAccess Tokensを開く。

以下の項目に入力し、トークンを生成する

• Name(任意の名前を入力)
• Scope(任意のものをチェック。自分はapiにチェックした)
• Create Personal accese tokenを押下

生成されたトークンを使う

• 資格情報マネージャーを開く
• Windows資格情報の汎用資格情報を開き、gitlabの情報を選択
• 編集のリンクを押下し、パスワードを生成されたトークンに変更する

もう一度pushすると正常にpushできる

• セキュリティ上画面を載せられませんが、ご自分の画面でご確認くださいm(_ _)m

参考サイト

• https://hawksnowlog.blogspot.com/2018/02/gitlab-clone-with-token.html
• https://gitlab.com/gitlab-org/gitlab-foss/-/issues/21246
• https://www.it-swarm.dev/ja/git/gitlab-remote%EF%BC%9Ahttp-basic%EF%BC%9A%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E3%81%8C%E6%8B%92%E5%90%A6%E3%81%95%E3%82%8C%E8%87%B4%E5%91%BD%E7%9A%84%E3%81%AA%E8%AA%8D%E8%A8%BC/836697672/

起きたエラー

GitHubでレポジトリを作成後、初回コミットとして以下のコマンドを実行した。

git branch
echo "# project名" >> README.md
git init
git add README.md
git commit -m "first commit"

実行すると、以下のエラーコードが発生（一部抜粋）。

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for project) not allowed

解決方法

まだまだ、黒い画面での作業に抵抗あり、あたふたしていましたが、
冷静に読んでみると、ヒントがありました。

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

gitは、私が誰だかわかっていなかったようで、
ヒントのとおり、自分のメールアドレスとユーザー名をコマンドたたく。

その後、再び、初回のinitのコマンドを実行したら問題なく初回コミットができました。