プルリク時にコンフリクトが発生したときの対応について

[wako-p]

フォークチャレンジのSTEP7でのプルリク時にコンフリクトが発生したので以下の手順で解決しました。

1. 自分のプルリクページで[Resolve conflicts]をクリック

2. GitHub上のエディタでファイル内のコンフリクトをすべて解決してから[Mark as resolved] > [Commit merge]をクリック

ただ、GitHub上での修正は、自動補完/構文チェックなどの恩恵が受けられなかったり、強制的に(リベースしたいのに)マージになっちゃったりと、もしかして、あまりメジャーな対応方法ではなかった？って思ってます。

なので、私なりに考えてみた結果、以下の手順が妥当かなと思っているんですが、実際どうあるべきなんでしょうか？
※作業ブランチを切っている前提の説明です

1. フォーク元の変更をフォーク先のリポジトリに取り込む(GitHubのフォーク先のリポジトリの[fetch]ボタンをクリック？)

2. 1の変更をローカルのmainブランチに取り込む

3. mainブランチの最新を作業ブランチにマージなりリベースなりしてコンフリクトを解決する

4. 作業ブランチの変更をリモートにプッシュする

5. 1回目のプルリクを取り消して、再度プルリクを送る？

そもそも、プルリクを送る前に1-4の手順であらかじめコンフリクトを解消しておくべき？とも思ったり、、、

よろしくお願いします！

[monsat]

コンフリクト解消ありがとうございますー

ふたつの視点で回答しますね

1. 一般的なプルリクエストの場合
2. commit-mate.net の新規参加時の場合

以下、説明にあたり、つぎのようにします。
（分かりづらいという方は、検索で調べつつ、ぜひこちらでも質問してください）

• フォーク元のGitHubリポジトリ: upstream (ex commit-mate/commit-mate.net )
• フォークしたGitHubリポジトリ: origin (ex your-account/commit-mate.net )
• ローカルマシンのリポジトリ: ここでは仮に ローカル といいます

一般的なプルリクエストの場合

可能な限り、upstream の最新の main ブランチの内容をもとにプルリクエストを作成します。
フォーク後等に upstream/main が更新された場合はたとえば次のように解消することになります。

1. git switch -c fix-issue-123 ローカルに新しいブランチを作成（このブランチのコミットがプルリクエスト対象）
2. 適宜 Issue を解消し git commit をする（コミットは複数に分けても構いません）
3. git fetch upstream（upstream の main ブランチが更新されたか確認する。事前に git remote add upstream [email protected]:commit-mate/commit-mate.net.git し upstream という名前をつけておく）
4. （更新されていたら）git rebase upstream/main で upstream の main ブランチの最新の内容を反映する（mergeと同様のことをしますので、場合によってはコンフリクトが発生します）
5. （コンフリクトしていたら）コンフリクトを解消し git commit
6. git push -u origin fix-issue-123 GitHub上の自分のリポジトリ (origin) にプッシュする
7. プルリクエストを作成

commit-mate.net の新規参加時の場合

今回は大体の流れを知ってもらうこと・体験してもらうことを目的としているので、あまり厳密にコンフリクトの解消を行っていただくことまでは求めていません。
ですので、そのままプルリクエストを送ってもらっても大丈夫です。
余裕のある方は、たとえば次のような手順で、解消していただけると助かります。

1. 自分のメンバーカードを作成しコミット（ main ブランチの作業でも構いません）
2. プッシュする前にGitHubの自分のアカウントのリポジトリ (origin) で [fetch] ボタンをクリックし、upstream/main の変更を取得（反映）
3. upsteam/main に更新があった場合はローカルにも取得 git fetch origin
4. git pull もしくは git merge origin/main （コンフリクトしている場合は次のステップで解消してください）
5. （コンフリクトしていた場合）修正し git commit
6. git push もしくは git push -u origin main
7. プルリクエストを作成

こんな感じでしょうか。

質問への回答

基本的に 1~5 の流れのとおりです。
なお最後の 5 について、すでにプルリクエストが作成されていれば、同じブランチをプッシュすると、自動的にそのプルリクエストに追加コミットされますので、特段別PRにする必要はありません。

[monsat]

前者は、慣例ですね。わりとそのように説明している記事多いと思うので、僕はとくに理由がなければそうしてます。
もしくは、たとえば commit-mate のように、意味のある名前にすることもあります。

後者は、、ちょっと調べてみますねー
fetch できませんでしたか（上記は試さず書いたので、すみませんー）

[monsat]

質問ですー

この記事のような、公開鍵の登録って GitHub 上でやってますか？
https://monsat.hatenablog.com/entry/generating-ssh-keys-for-github

もしまだでしたら、登録してから、fetch してみてください。
もし済んでるようでしたら、その旨おしえてくださいー

[wako-p]

前者は、慣例ですね。わりとそのように説明している記事多いと思うので、僕はとくに理由がなければそうしてます。

もしくは、たとえば commit-mate のように、意味のある名前にすることもあります。

後者は、、ちょっと調べてみますねー

fetch できませんでしたか（上記は試さず書いたので、すみませんー）

おー、そうなんですね！
では、特に理由がなければ先人にならって、upstreamにするのが無難そうですねー

ありがとうございます！

[wako-p]

質問ですー

この記事のような、公開鍵の登録って GitHub 上でやってますか？

https://monsat.hatenablog.com/entry/generating-ssh-keys-for-github

もしまだでしたら、登録してから、fetch してみてください。

もし済んでるようでしたら、その旨おしえてくださいー

ありがとうございます！
こちらは既に登録済みでしたー

さっき、ローカルからupstreamのフェッチを試してみたところ、無事に成功できました！

んー、コントリビューターとして参加できていない状態？だと拒否されしちゃう仕様とかだったり？

[monsat]

おおーできましたか。よかったです！
もともと公開鍵は登録されてたのですね。だとすると謎ですね…
なぜですかねえ🤔