コンフリクトが起きた！

前提
・featureブランチで作業
・プルリクを出した
・リモートブランチにてdevelopにマージする
事象
・コンフリクトが起きた！
対応

$ git checkout master
$ git pull origin master
$ git checkout develop
$ git pull origin develop
$ git checkout feature
$ git merge develop
コンフリクト解消する
$ git push origin feature

GitとGitHubに関して簡単にまとめていきます。
随時加筆予定。

用語説明

Git

バージョン管理システム。
(コンピュータ上で作成および編集されるファイルの変更履歴を管理するためのシステム)

GitHub

GitをベースにしたWebサービス。
コードレビューしたり、議論をしたり、並行的に異なる開発をしてマージする一連の流れを簡単に行うことができる。
(マージ・・・結合、統合、合体)

リポジトリ

ソースコードを格納する入れ物。
チームでソースコードを管理する為には、GitHubリポジトリを作成する。

GitHubリポジトリの作成

※まずはGitHubアカウントを作成してください。

①GitHubページのヘッダーより「New repository」を選択。
②リポジトリ名 (+リポジトリ説明文)を入力。
③Createボタンを押す。

Git, GitHubで管理したいディレクトリの設定 (Macの場合)

※ローカル環境にGitをインストールし、初期設定を行ってください。

①ターミナル上で、管理したいディレクトリに移動。
②「git init」コマンドを実行。
「Initialized empty Git repository in /Users/ユーザー名/ディレクトリ名/.git/」みたいな文言が表示される (ローカルリポジトリが作成される)。
③「git remote add origin [URL]」コマンドを実行。
ローカルリポジトリとGitHubリポジトリ (リモートリポジトリ)が連携される。
[URL]の部分はGitHubリポジトリのページにある「https://github.com/ユーザー名/リポジトリ名.git」というURLを指定。

GitHubリポジトリにソースコードをプッシュする

プッシュ

コミットをローカルリポジトリからリモートリポジトリに送る操作。
コミットとは、ファイルの追加や変更の履歴をリポジトリに保存すること。

---

①「git status」コマンドを実行。変更したファイルの一覧を確認。
②「git add ファイル名」コマンドを実行。
指定したファイルの変更内容をインデックス (ステージングエリアとも呼ばれる)に追加し、コミットの対象にする。
(「git add -A」コマンドでディレクトリ内全てのファイルを対象にできる。)
③「git commit -m "コミットメッセージ"」を実行。
指定したファイルの変更内容がコミットされる。
コミットメッセージはチーム内で決まりがあったりする。
「git log」コマンドでコミットされたか確認ができる。
「git commit --amend」コマンドで直前のコミットのコミットメッセージを修正できる。
④「git push origin master」コマンドを実行。

ブランチの作成方法とプルリクエスト

ブランチ

リポジトリ内でコードのバリエーションを複数保持しながら開発する際に、1つのバリエーションを管理する単位となっている概念。
新しい開発を行う場合、「master」と呼ばれるメインのブランチから枝分かれした新しいブランチ (ブランチAとする)を作成し、
ブランチA上で機能追加等を行った際は、最終的にブランチAをmasterブランチに取り込むことになる。

プルリクエスト

あるブランチに、別のブランチをマージしてもらうことの要求 (提案)。

---

①「git checkout -b ブランチ名」コマンドを実行し、ブランチ作成とそこに移動。
②変更内容がコミットできたら、「git push origin HEAD」コマンドを実行。
現在のブランチと同じブランチがGitHub上に作成され、そこにプッシュされる。
③GitHubのリポジトリページに表示されたプルリクエストを作成するリンクを使い、プルリクエスト作成。
プルリクエストからコードの変更内容を確認できたり、変更箇所やプルリクエスト全体にコメントできたりする。
レビューを受け、コードを修正したくなった場合はブランチに修正コミットを積んで新たにプッシュする。
④最終的にその変更を取り込もうという段階になったら、GitHubの画面からブランチのマージを行う。
⑤ローカルリポジトリのmasterブランチに移動し、「git merge ブランチ名」コマンドを実行。
指定した作業ブランチの内容で現在のブランチ (masterブランチ)を上書きして最新の状態に更新しておく。

参考文献

現場で使えるRuby on Rails5 速習実践ガイド

マージコンクリフトの解決方法

マージコンクリフト( Merge Conflict )には２種類の場合がある。
１、同じファイルの同じ行の競合
２、削除したファイルと編集されたファイルの競合

※「競合」( Conflict )とは、言葉の通り互いに競り合うことを意味する。

同じファイルの同じ行の競合

developブランチとfeatureブランチが存在していて、それぞれのブランチの同じ名前のファイルの記載内容が異なっている場合。
例えば、作業ブランチで編集したconfig/routes.rbを編集してマージした際、

$ git merge <ブランチ名>
Auto-merging config/routes.rb
CONFLICT (content): Merge conflict in config/routes.rb
Automatic merge failed; fix conflicts and then commit the result.

表示されている通り、自動マージが失敗したので、競合を修正してから手動でコミットしてください。と言われる。
以下のコマンドでどのファイルを編集すればいいか確認。

$ git stutas
On branch develop
Your branch is up to date with 'origin/develop'.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Changes to be committed:
        new file:   app/assets/javascripts/reviews.coffee

     ~  省略  ~  #これらのファイルはコンフリクト起こさずに自動マージできたファイル

        new file:   spec/views/reviews/show.html.slim_spec.rb

Unmerged paths:
  (use "git add <file>..." to mark resolution)
        both modified:   config/routes.rb  #このファイルを修正する

マージを中止する場合 → $git merge --abort
コンフリクトを解消したら → $git add <file>
対象ファイルを開くと、コンクリフトを起こしている部分は以下のように表示される

<<<<<<< HEAD
  root to: 'static_pages#top'   |
  root to: 'static_pages#home'  |   #作業ブランチでの変更内容
  resources :static_pages       |
                                |
  # get 'static_pages/top'      |
  # get 'static_pages/home'     |
=======
  root to: 'reviews#index'      |   #マージ先のブランチでの変更内容
  resources :reviews            |
>>>>>>> feature/branch
end

今回は作業ブランチでの変更内容は全部消して問題なかったので削除
編集したファイルをステージングする(これをしないとGitがコンクリフトを解消したことに気づけない)

$ git add config/routes.rb

$git statusでUnmerged paths:の警告が消えているのを確認
ファイルはChanges to be committed:の一覧に追加されている
そして、コッミトしてプッシュすれば完了！

$ git commit -m "コンフリクト解消"

$ git push origin develop

削除されたファイルと編集されたファイルの競合

developブランチのXXXファイルは削除したけど、featureブランチのXXXファイルは削除することなく編集した場合。

$ git merge feature
CONFLICT (modify/delete): XXXファイル deleted in HEAD and modified in feature. Version feature of XXXファイル left in tree.
Automatic merge failed; fix conflicts and then commit the result.

メッセージ内容は(同じファイルの同じ行の競合と)少し異なりますが、言いたいことは同じで自動的なマージは失敗したので、適性に競合してからコミットしてくださいということ。

$ git status
You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add/rm <file>..." as appropriate to mark resolution)

        deleted by us:   XXXファイル

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

こちらのコンフリクトも$git merge --abortでマージを取り消すことができる
今回はファイルを削除したままにしたいので、以下のコマンドを入力する。

$ git rm XXXファイル
XXXファイル: needs merge
rm 'XXXファイル'

$ git rmはgitの管理下にあるファイルを削除するコマンド。標準のUNIXコマンドにあるrmのgit版にあたるもの。

On branch master
All conflicts fixed but you are still merging.
  (use "git commit" to conclude merge)

あとは同じようにコミットするだけ

mergeとrebase

どちらもブランチ元に統合する機能。

• merge

  • 非破壊的操作(情報が消えることはない)
  • 既存のブランチは変更されない
  • 頻繁にブランチしたりmasterが動いたりする場合だと、コミットグラフが乱雑する

• rebase

  • コミットグラフはきれいになるが、消える情報がある
  • pushされたブランチをrebaseすとるpushできなくなる

コミットログが綺麗になるのは一見するといいことのように思えるが、そもそも Git はブランチが分岐するような非直線的な履歴のために作られ、またそれを推奨している。リポジトリにおいて大切なのは履歴の正確性。不具合が起きた時に不必要な履歴は存在しない。
ただどちらのコマンドが有用的になるのかは、開発環境・状況によって異なるだろうし、そこの判断は追々学んでいきたい。

補足

同じファイルの同じ行の競合については、Ruby on Railsでの開発の時、実際に起こった状況をもとに解決したものです。
削除されたファイルと編集されたファイルの競合に関しては、情報をまとめただけです。

参考
Git のマージコンフリクトを解決する方法
mergeとrebaseの違い
なぜ git rebase をやめるべきか - Frasco

issue管理をすると、積み上げ感が増し、モチベーションが上がります。

現在、未経験からの転職の為、Githubを利用したポートフォリオを作成してます。
漠然と設計を考えて作成していく中で、これいつ終わるんだろう？とか
どれを優先して機能を作成していけば良いのか？など不安ばかりだったので、
設計をタスク化して頭を整理する為、issue機能を取り入れて見ました。
実際にやって見ると徐々に自分のポートフォリオの機能が
積み上がって行くのが、視覚化され、それによりモチベーションが高まるのでご紹介します。

issueって何？

スレッド形式で課題管理が出来、開発における問題点や、課題などを共有したり、議論したり出来る機能です。
僕は、個人でポートフォリオを作成している為、タスク管理をする目的で利用しています。

どういう風に利用するのか？

前提条件として、

• githubアカウントを持っている。

• githubを利用した開発をしている。

• gitの基本的なコマンド操作を理解している。
  おすすめ記事（https://qiita.com/shimotaroo/items/b73d896ace10894fd290#comments）

まず、開発作業に入る前に、何をするのか、計画をタスク化してissueを作る。
例えば、

• ログイン機能を作成する。
• 投稿機能を作成する。
• 投稿一覧を作成する。

など、やりたい事、取り込みたい機能、問題点などをどんどんisuueに書いて行きましょう。
どれぐらいの粒度にするかは自由ですが、大きい単位にすると、完成するのに数日
かかり、気が遠くなるよりかは、なるべく細かい単位に分けて作成した方が、
達成感が生まれやすいです。個人的には数時間で終わりそうな事でもissue書いて
作業する事がおすすめです。

issueを作成する

issuesから、右のNew issueを選択。
例として、『新規登録画面、View調整。』というissueを作成する事にしました。
Titleと、issue内容を記入して、Submit new issueボタンを押すと、

Titleの横に#35という数字が表示されています。これが、issue番号になります。
この番号は今後commit、プルリクでissueを紐付ける事が出来ますので、覚えておきましょう。
https://qiita.com/cotolier_risa/items/210db74e6496d4359be7

ブランチを切って作業開始

issueを作成しましたので、開発に取り掛かります。

$ git checkout -b signup_view_design#35

ブランチ名にissue番号を付け、作業を開始します。
(このブランチにはこのisuueの作業をしているという風に、明示的に分かる様にしています。)

commit作成

$ git commit -m "新規登録画面のデザイン調整。 #35"
　　　　　　　　　　　　　　　　　　　　　　　 ↑
                                    スペースを空けて#issue番号を書く

作業毎に、commitを作成する時、commit名にissue番号を書きます。
＊注意点として、上記の様にスペースを空けて番号を書かないと、commitとissueが紐付きません。

作業終了したらGit push！

$ git push origin signup_view_design#35

issueを確認すると、先程のcommitが表示されて紐付いていますね！

プルリク作成

次は、プルリクを作成してみましょう。

Compare & pull requestボタンが表示されてますので、押します。

コメントに『close #issue番号』を書くと、マージされると自動的にissueもcloseされます！
便利〜！（因みに、他にも色々な書き方があるみたいです。)
https://katsukiniwa.qrunch.io/entries/7t6Nkr6qwOGwKts3

番号がリンクになってますのでクリックすると、issueにジャンプする事が出来ます。

mergeしてclose。

先程のissueがcloseされてますね！

この一連の作業が、僕のやっているissue管理です。
漠然と開発をするよりかは、タスクを作成し、issueで管理してどんどんcloseしていけば
気分的にも気持ちいいし、徐々に機能が積み上がっていく感じでモチベーションが上がる
ので、おすすめします！(issueを作成するとGithubの草も生えるしね)
チーム開発を意識した練習にもなると思うので未経験でポートフォリオを作成している人は
是非、取り入れても良いかもです！

issue管理をすると、積み上げ感が増し、モチベーションが上がります。

現在、未経験からの転職の為、Githubを利用したポートフォリオを作成してます。
漠然と設計を考えて作成していく中で、これいつ終わるんだろう？とか
どれを優先して機能を作成していけば良いのか？など不安ばかりだったので、
設計をタスク化して頭を整理する為、issue機能を取り入れて見ました。
実際にやって見ると徐々に自分のポートフォリオの機能が
積み上がって行くのが、視覚化され、それによりモチベーションが高まるのでご紹介します。

issueって何？

スレッド形式で課題管理が出来、開発における問題点や、課題などを共有したり、議論したり出来る機能です。
僕は、個人でポートフォリオを作成している為、タスク管理をする目的で利用しています。

どういう風に利用するのか？

前提条件として、

• githubアカウントを持っている。

• githubを利用した開発をしている。

• gitの基本的なコマンド操作を理解している。
  おすすめ記事（https://qiita.com/shimotaroo/items/b73d896ace10894fd290#comments）

まず、開発作業に入る前に、何をするのか、計画をタスク化してissueを作る。
例えば、

• ログイン機能を作成する。
• 投稿機能を作成する。
• 投稿一覧を作成する。

など、やりたい事、取り込みたい機能、問題点などをどんどんisuueに書いて行きましょう。
どれぐらいの粒度にするかは自由ですが、大きい単位にすると、完成するのに数日
かかり、気が遠くなるよりかは、なるべく細かい単位に分けて作成した方が、
達成感が生まれやすいです。個人的には数時間で終わりそうな事でもissue書いて
作業する事がおすすめです。

issueを作成する

issuesから、右のNew issueを選択。
例として、『新規登録画面、View調整。』というissueを作成する事にしました。
Titleと、issue内容を記入して、Submit new issueボタンを押すと、

Titleの横に#35という数字が表示されています。これが、issue番号になります。
この番号は今後commit、プルリクでissueを紐付ける事が出来ますので、覚えておきましょう。
https://qiita.com/cotolier_risa/items/210db74e6496d4359be7

ブランチを切って作業開始

issueを作成しましたので、開発に取り掛かります。

$ git checkout -b signup_view_design#35

ブランチ名にissue番号を付け、作業を開始します。
(このブランチにはこのisuueの作業をしているという風に、明示的に分かる様にしています。)

commit作成

$ git commit -m "新規登録画面のデザイン調整。 #35"
　　　　　　　　　　　　　　　　　　　　　　　 ↑
                                    スペースを空けて#issue番号を書く

作業毎に、commitを作成する時、commit名にissue番号を書きます。
＊注意点として、上記の様にスペースを空けて番号を書かないと、commitとissueが紐付きません。

作業終了したらGit push！

$ git push origin signup_view_design#35

issueを確認すると、先程のcommitが表示されて紐付いていますね！

プルリク作成

次は、プルリクを作成してみましょう。
Compare & pull requestボタンが表示されてますので、押します。

コメントに『close #issue番号』を書くと、マージされると自動的にissueもcloseされます！
便利〜！（因みに、他にも色々な書き方があるみたいです。)
https://katsukiniwa.qrunch.io/entries/7t6Nkr6qwOGwKts3

番号がリンクになってますのでクリックすると、issueにジャンプする事が出来ます。

mergeしてclose。

先程のissueがcloseされてますね！

この一連の作業が、僕のやっているissue管理です。
漠然と開発をするよりかは、タスクを作成し、issueで管理してどんどんcloseしていけば
気分的にも気持ちいいし、徐々に機能が積み上がっていく感じでモチベーションが上がる
ので、おすすめします！(issueを作成するとGithubの草も生えるしね)
チーム開発を意識した練習にもなると思うので未経験でポートフォリオを作成している人は
是非、取り入れても良いかもです！

issue管理をすると、積み上げ感が増し、モチベーションが上がります。

現在、未経験からの転職の為、Githubを利用したポートフォリオを作成してます。
漠然と設計を考えて作成していく中で、これいつ終わるんだろう？とか
どれを優先して機能を作成していけば良いのか？など不安ばかりだったので、
設計をタスク化して頭を整理する為、issue機能を取り入れて見ました。
実際にやって見ると徐々に自分のポートフォリオの機能が
積み上がって行くのが、視覚化され、それによりモチベーションが高まるのでご紹介します。

issueって何？

スレッド形式で課題管理が出来、開発における問題点や、課題などを共有したり、議論したり出来る機能です。
僕は、個人でポートフォリオを作成している為、タスク管理をする目的で利用しています。

どういう風に利用するのか？

前提条件として、

• githubアカウントを持っている。

• githubを利用した開発をしている。

• gitの基本的なコマンド操作を理解している。
  おすすめ記事:Gitでやりたいこと、ここで見つかる

まず、開発作業に入る前に、何をするのか、計画をタスク化してissueを作る。
例えば、

• ログイン機能を作成する。
• 投稿機能を作成する。
• 投稿一覧を作成する。

など、やりたい事、取り込みたい機能、問題点などをどんどんisuueに書いて行きましょう。
どれぐらいの粒度にするかは自由ですが、大きい単位にすると、完成するのに数日
かかり、気が遠くなるよりかは、なるべく細かい単位に分けて作成した方が、
達成感が生まれやすいです。個人的には数時間で終わりそうな事でもissue書いて
作業する事がおすすめです。

issueを作成する

issuesから、右のNew issueを選択。
例として、『新規登録画面、View調整。』というissueを作成する事にしました。
Titleと、issue内容を記入して、Submit new issueボタンを押すと、

Titleの横に#35という数字が表示されています。これが、issue番号になります。
この番号は今後commit、プルリクでissueを紐付ける事が出来ますので、覚えておきましょう。
参考:GitHubのissueとcommitを紐付ける

ブランチを切って作業開始

issueを作成しましたので、開発に取り掛かります。

$ git checkout -b signup_view_design#35

ブランチ名にissue番号を付け、作業を開始します。
(このブランチにはこのisuueの作業をしているという風に、明示的に分かる様にしています。)

commit作成

$ git commit -m "新規登録画面のデザイン調整。 #35"
　　　　　　　　　　　　　　　　　　　　　　　 ↑
                                    スペースを空けて#issue番号を書く

作業毎に、commitを作成する時、commit名にissue番号を書きます。
＊注意点として、上記の様にスペースを空けて番号を書かないと、commitとissueが紐付きません。

作業終了したらGit push！

$ git push origin signup_view_design#35

issueを確認すると、先程のcommitが表示されて紐付いていますね！

プルリク作成

次は、プルリクを作成してみましょう。
Compare & pull requestボタンが表示されてますので、押します。

コメントに『close #issue番号』を書くと、マージされると自動的にissueもcloseされます！
便利〜！（因みに、他にも色々な書き方があるみたいです。)
https://katsukiniwa.qrunch.io/entries/7t6Nkr6qwOGwKts3

番号がリンクになってますのでクリックすると、issueにジャンプする事が出来ます。

mergeしてclose。

先程のissueがcloseされてますね！

この一連の作業が、僕のやっているissue管理です。
漠然と開発をするよりかは、タスクを作成し、issueで管理してどんどんcloseしていけば
気分的にも気持ちいいし、徐々に機能が積み上がっていく感じでモチベーションが上がる
ので、おすすめします！(issueを作成するとGithubの草も生えるしね)
チーム開発を意識した練習にもなると思うので未経験でポートフォリオを作成している人は
是非、取り入れても良いかもです！

.sshフォルダを作り、その中に公開鍵と秘密鍵を作る

ターミナル

$ cd
$ mkdir .ssh
$ cd .ssh

下記のコマンドで公開鍵と秘密鍵を作る(公開鍵と秘密鍵はペア)

ターミナル

$ ssh-keygen -t rsa

全てEnterキーで構いません

ターミナル

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/(username)/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

id_rsa(秘密鍵)　とid_rsa.pub(公開鍵)を作ることができました。
id_rsa.pub(公開鍵)の中身を実際にGitに登録していただきます。

ターミナル

$ cat id_rsa.pub

ターミナル

katonoMacBook-puro-4:.ssh katoatsushi$ cat id_rsa.pub 
ssh-rsa AAAAB3NzaC1yc2EAAAADEcpf3vsEk/hFNowzSDRdBIlwU9Q55wRF/5cJNn67X
yF4AH8LdbYh2xzqqh+Q4WfWyb5iZjSVTr7Ncvd0G+iiM0YuHCd+d3WVymbM/Nu
ZJzNZKMxbmR//tZUGcmZ/aPrtUBO4+3S3xkegamAp1VEClydKTTvtSh1Uz4Xx3
590ALo3XccXQS1EXdO8Md9GLte4S4NQfcHrlooVaZyjwWOMbRtkmd1BR+Yw//
jYBSJHZOC8koFGySW8KkxWyVHpGdyD6HkxiBmWg7Dakdaql5n7NWimG0XwEahU
z4BNv5eY+vf4JNkXSBID katoatsushi@katonoMacBook-puro.local

公開鍵は
ssh-rsa AAAAB3NzaC1yc2EAAAADEcpf3vsEk/hFNowzSDRdBIlwU9Q55wRF/5cJNn67XF4AH8LdbYh2xzqqh+Q4WfWyb5iZjSVTr7Ncvd0G+iiM0YuHCd+d3WVymbM/NuZJzNZKMxbmR//tZUGcmZ/aPrtUBO4+3S3xkegamAp1VEClydKTTvtSh1Uz4Xx3590ALo3XccXQS1EXdO8Md9GLte4S4NQfcHrlooVaZyjwWOMbRtkmd1BR+Yw//jYBSJHZOC8koFGSW8KkxWyVHpGdyD6HkxiBmWg7Dakdaql5n7NWimG0XwEahUz4BNv5eY+vf4JNkXSB katoatsushi@katonoMacBook-puro.localになります

ssh-addができないときの解決方法

gitで詰まったところを備忘録的に書いています．

環境

windows 10
git bash

結論

手順をとても簡単にしたものです

#ssh-agentをバックグラウンドで起動
$ eval $(ssh-agent -s)
Agent pid 1440

#ssh key を追加
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /c/Users/Username/.ssh/id_rsa:
Identity added: /c/Users/Username/.ssh/id_rsa (example@mailm)

#確認する
$ ssh-add -l
(あなたのキー)

問題点

ssh公開鍵を毎回パスフレーズ求められるのは面倒くさい，，

$ git pull
Enter passphrase for key '/Users/Username/.ssh/id_rsa':

解決方法

ssh keyを自動で認証できるようにしよう

1.このままだとssh-addできない

$ ssh-add /.ssh/id_rsa
Could not open a connection to your authentication agent.

$ ssh-add -K
Could not open a connection to your authentication agent.

$ ssh-add -l
Could not open a connection to your authentication agent.

2.ssh-agentをバックグラウンドで起動
とりあえずssh-agentすればいいすればいいらしい

//これはできなかった
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-IFr4jBWrz8XT/agent.1429; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1430; export SSH_AGENT_PID;
echo Agent pid 1430;

#これもできなかった
$ eval "ssh-agent"
SSH_AUTH_SOCK=/tmp/ssh-axacGz0TApMp/agent.1434; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1435; export SSH_AGENT_PID;
echo Agent pid 1435;

#これで成功
$ eval $(ssh-agent -s)
Agent pid 1440

3.ssh-addする
こんな感じで返ってきたら毎回パスフレーズを求められなくなる．

$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /c/Users/Username/.ssh/id_rsa:
Identity added: /c/Users/Username/.ssh/id_rsa (example@mailm)

#確認する
$ ssh-add -l
(あなたのキー)

参考文献

新しい SSH キーを生成して ssh-agent に追加する