回答編集履歴

勘違いしてた

2022/02/14 14:06

投稿

miyabi-sun

スコア21158

test CHANGED Viewed

@@ -1,6 +1,14 @@
-不可能です。
+可能です。
+参考記事: [【Git】別のブランチにpushしたいとき - Qiita](https://qiita.com/yonce/items/b09f35ab301befde7803)
+pushコマンドのブランチ名を省略無しにする必要があります。
+`git push origin test:master`
+Gitにおける`push`コマンドはのブランチ名の箇所に関しては
+省略せずに記述すると`ローカルのブランチ名:リモートのブランチ名`となります。
+省略してブランチ名だけ記述すると勝手に`master:master`等のようになります。
-実際に私がローカルで適当なファイルをコミットして試した履歴が下記になります
+失敗パターンとして実際に私がローカルで適当なファイルをコミットして試した履歴が下記になります
 (一部マスキングしています)
 ```bash
@@ -20,10 +28,24 @@
 Total 0 (delta 0), reused 0 (delta 0)
 To github.com:xxxx/xxxx.git
    ef3ba37..8b7ef5f  master -> master
 ```
 このようにtest -> masterはPushが出来ませんでしたが、
 master -> masterのPushは成功しました。
+なので一旦状況を戻して`test:master`のブランチ指定を試してみます。
+```bash
+# masterを元のコミットに復旧させtestブランチにカレントブランチを変更
-これは単にGitHubのセキュリティ上の制約として
+$ git reset [元のコミットID]
+$ git push -f origin master
+$ git checkout test
-別ブランチからのPushを許さないようにしているだけだと考えられます。
+$ git push origin test:master
+Total 0 (delta 0), reused 0 (delta 0)
+To github.com:xxxx/xxxx.git
+   ef3ba37..8b7ef5f  test -> master
+```
+無事成功しました。

冒頭の説明文を改良

2022/02/14 13:58

投稿

miyabi-sun

スコア21158

test CHANGED Viewed

@@ -1,106 +1,29 @@
-プルリクエストというのはGitHubというSNSサービスの機能を利用した
-「マージしてくれ頼む」という依頼ですので
-マージが出来る状況ならば使えます。
+不可能です。
-`test`→`master`ならば
-`test`は`master`が所持していないコミット履歴を所持している必要があります。
+実際に私がローカルで適当なファイルをコミットして試した履歴が下記になります
-`master`→`test`ならばその逆ですね。
-`master`は`test`が所持していないコミット履歴を所持している必要があります。
----
-基本的には開発初期のタイミングでなければ、
-masterブランチは本番環境や客先等で既に稼働しているものを指します。
-受け専みたいなところがあるので多くの場面ではmasterから他のブランチへPRを出すような状況になる事はほぼありません。
-ただし、あるかもしれないというケースはあります。
-git-flowというブランチ戦略ではmasterから別ブランチへマージするフローが存在します。
-master環境で出た緊急性の高い不具合を修正する為に、master→hotfix→masterという別口でmasterブランチのコミット履歴を進める事があります。
-なのでmasterとdevelopが相互で所持していないコミット履歴が生まれるので、master→developのマージが発生します。
-これをPRでやる現場ルールがあれば、masterからPRを出す唯一のレアケースになりえます。
----
-ここからはどういう状況でマージが必要な状況になるのかを
-ストーリー仕立てで解説していきます。
+(一部マスキングしています)
-> ローカル側に、masterとtestとの２つのブランチがあり、GitHub側にもmasterとtestの２つのブランチがあります。
-ローカルにあるmasterとtestのブランチはGitHubにPush済みであり、
-それぞれのmasterとtestの同一ブランチ名同士は全く同じコミット履歴になっているとします。
-プロジェクトというのは全くファイルがない真っ白な状態から、
-ファイルを追加・変更するコミット履歴を1個ずつ積み上げて
-最終的に顧客の要望しているシステム、自社製品としてマネタイズ出来るシステムを目指すものです。
-この1個1個の積み上げる「コミット履歴」が「≒目的」と言える状態なわけですね。
-こいつらを例として使う為に連番として「コミット履歴A」「コミット履歴B」と名付けて行きます。
-ブランチ管理戦略の「git-flow」「GitHub Flow」はどちらも`master`ブランチが本番環境で動作している
-表に出せる最新のファイル構造である状態であるべきです。
-`master`ブランチは真っ白な何もファイルが存在しない状態から始まり、
-「コミット履歴A」から順番に積み上げられ、
-A、B、C、D、Eが含まれた状態になっています。
-ここまでが前提条件
-`test`コード書いて自動テストがしたいよね。
-こういう目的で`A、B、C、D、E`のコミット履歴が詰まった`master`ブランチから枝分かれさせて作りました。
-テストコードを追加して自動テストが出来るじゃんやったね！これで「コミット履歴F」を作って積み上げました。
-この「コミット履歴F」を追加した状態の`test`ブランチをGitHubにPushしました。
-この状態であれば、`test`→`master`にプルリクエストを飛ばす事が可能です。
-その目的はテストコードを追加した「コミット履歴F」を`master`ブランチに入れてくれ。というものになります。
-しかし逆の`master`→`test`のプルリクエストは出来ません。何故か？
-`master`ブランチがこれまで積み重ねた歴史「A、B、C、D、E」は全て`test`ブランチに含まれています。
-何のコミット履歴を`test`ブランチへ追加してほしいんだい？何も無ければマージ出来ないんだからPRも出せないぞ。
-これを「`test`ブランチは`master`ブランチよりも進んでいる」と表現したりします。
----
-次に`master`から`test`ブランチPRが出せるケースに関して考えていきましょう。
-Gitではブランチを分けることで同時並行の開発が可能となります。
-いちいちファイルをロックしなくて良いのは便利ですね。
-あなたがテストコードを追加する`test`ブランチを枝分かれさせ「コミット履歴F」を作っている間に、
-別作業者の方が新機能の`feature`ブランチを作って「コミット履歴G」を作って
-`feature`→`master`ブランチにプルリクエストを作って、無事マージされました。
-この場合状況が込み入った事になります。
-- master: A, B, C, D, E, G
-- test: A, B, C, D, E, F
-お互いがお互いに存在しないコミット履歴が積み上がった状態になっているわけですね。
-この時Gitでは双方向でマージすることが可能となりますし、
-プルリクエストも双方向で飛ばす事が可能となります。
-でもまぁ、基本的には`test`は`master`から一時的にファイルを作る為に枝分かれさせた存在です。
-なので「なんでコミット履歴Gを持ってないんだい？」と言われる立場です。
-`master`から`test`に「このコミット履歴Gを追加してくださいお願いします！」という立場ではないので、依頼する事はgit-flowでもない限り基本的にはありえないと言って良いでしょう。
-この場合、`test`ブランチは`master`ブランチにあるコミット履歴を落としてきて下に滑り込ませ、
-A, B, C, D, E, G, Fのコミット履歴の並びを作って、改めて`test`→`master`にPRを飛ばす事になるでしょう。
-コマンドの流れはこんな感じになります。
 ```bash
+# テストブランチ作ってコミット履歴を進めてみる
+$ git checkout -b test
-$ git branch
+$ git add .
-* test
+$ git commit -m "tmp"
-  master
-# masterブランチを更新
+# 別ブランチからのPushを試してみる
+$ git push origin master
+Everything up-to-date
+# testブランチの情報を取り込みmasterブランチでのPushを試してみる
 $ git checkout master
+$ git merge test
-$ git pull origin master
+$ git push origin master
+Total 0 (delta 0), reused 0 (delta 0)
-$ git checkout test
+To github.com:xxxx/xxxx.git
+   ef3ba37..8b7ef5f  master -> master
+```
+このようにtest -> masterはPushが出来ませんでしたが、
-# masterが持っている新しいコミット履歴を、testブランチの下に滑り込ませる
+master -> masterのPushは成功しました。
-$ git rebase master
-# testブランチのコミット履歴の下にぶら下げたことでコミット履歴の改ざんがされているので
+これは単にGitHubのセキュリティ上の制約として
-# testブランチをForceオプションを利用して強制Pushする
+別ブランチからのPushを許さないようにしているだけだと考えられます。
-$ git push -f origin test
-```

2022/02/14 10:29

投稿

miyabi-sun

スコア21158

test CHANGED Viewed

@@ -1,17 +1,30 @@
+プルリクエストというのはGitHubというSNSサービスの機能を利用した
-実はgit-flowというブランチ戦略では
+「マージしてくれ頼む」という依頼ですので
-`master`から別ブランチへマージするケースがあります。
-hotfix適用が行われる度にそうなりますしね。
+マージが出来る状況ならば使えます。
+`test`→`master`ならば
-プルリクエストというのは「マージしてくれ頼む」というSNS機能を利用した依頼ですので
+`test`は`master`が所持していないコミット履歴を所持している必要があります。
-マージがあるなら可能性としてあるよねって話ですね。
+`master`→`test`ならばその逆ですね。
+`master`は`test`が所持していないコミット履歴を所持している必要があります。
+---
+基本的には開発初期のタイミングでなければ、
+masterブランチは本番環境や客先等で既に稼働しているものを指します。
+受け専みたいなところがあるので多くの場面ではmasterから他のブランチへPRを出すような状況になる事はほぼありません。
+ただし、あるかもしれないというケースはあります。
+git-flowというブランチ戦略ではmasterから別ブランチへマージするフローが存在します。
+master環境で出た緊急性の高い不具合を修正する為に、master→hotfix→masterという別口でmasterブランチのコミット履歴を進める事があります。
+なのでmasterとdevelopが相互で所持していないコミット履歴が生まれるので、master→developのマージが発生します。
+これをPRでやる現場ルールがあれば、masterからPRを出す唯一のレアケースになりえます。
+---
-じゃあどういう場面で出来るのか？
+ここからはどういう状況でマージが必要な状況になるのかを
-ケースバイケースです。で終わってしまうと学びがないので分解していきます。
+ストーリー仕立てで解説していきます。
 > ローカル側に、masterとtestとの２つのブランチがあり、GitHub側にもmasterとtestの２つのブランチがあります。
-ケースバイケースなので噛み砕く必要があるので、
-前提条件を整理していきます。
 ローカルにあるmasterとtestのブランチはGitHubにPush済みであり、
 それぞれのmasterとtestの同一ブランチ名同士は全く同じコミット履歴になっているとします。
@@ -29,6 +42,8 @@
 `master`ブランチは真っ白な何もファイルが存在しない状態から始まり、
 「コミット履歴A」から順番に積み上げられ、
 A、B、C、D、Eが含まれた状態になっています。
+ここまでが前提条件
 `test`コード書いて自動テストがしたいよね。
 こういう目的で`A、B、C、D、E`のコミット履歴が詰まった`master`ブランチから枝分かれさせて作りました。