[過去ﾛｸﾞ] Git 17 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
963(1): 2022/04/22(金)00:44 ID:a+ReXgZI(1/2) AAS
ブランチが必要な理由が分からない
リモートからクローンしてきている時点で、origin/masterとは別のリポジトリが個々人に存在するんだし
コミットも個々人のリポジトリに対して行うわけでしょ
一度もブランチ生やしてなんて一度も指示されたことないわ
964: 2022/04/22(金)02:04 ID:/nIvhavJ(1) AAS
ブランチがないとお互いのコミットを観測することができない
人の変更を見ようと互いにpush+pullすると常にmergeが伴うので、いわゆる観測者効果みたいな面倒くささが生まれる
プロジェクトの規模やリリースの複雑性が増すにつれてより困る
よくある例では、次バージョンの開発を初めている人がいるときhotfixを出せない
featureブランチのpushはオアズケを命じられて、その間ソースレビューも滞る
ブランチをforkに置き換えても同じ
965: 2022/04/22(金)09:52 ID:ZbT6iK7O(1) AAS
各個人のGitHubアカウントにforkしてリポジトリ間のpull requestでマージしていく流派も存在する
本来のGitやGitHubの想定する使い方としては正しくてOSS文化的にも好ましいやり方ではあるんだが、企業での開発ではほとんど採用されない
単一のGitHubリポジトリで中央集権的に管理した方が楽だからね
966: 2022/04/22(金)12:20 ID:dVlUoLXX(1) AAS
AからA'とBの2つを作りたくなったときって、
ブランチなしでどうやるんだろうな
967: 2022/04/22(金)12:30 ID:wri6W8iQ(1) AAS
>>963
ブランチは「実装していること」を表すので、複数の機能を並行して開発するときは必須。
よくあるのは
・通常の開発版とリリース版／デバッグ版を分けて、デバッグリリースを早くする＆開発版への取り込みを管理しやすくする
・開発する機能ごとにブランチを用意して、互いの干渉を減らす＆マージをやりやすくする
あたり。
968: 2022/04/22(金)14:20 ID:QpAASndC(1) AAS
自分のアカウントにforkするスタイルの開発しか経験ない人が
単一GitHubリポジトリ運用な会社に入ってforkして怒られるのはGitHubあるある
969: 2022/04/22(金)21:56 ID:RSUrvfLc(1/2) AAS
fork って何？ git 用語に翻訳して。
970(1): 2022/04/22(金)22:05 ID:0DWZpb5V(1) AAS
clone
971(1): 2022/04/22(金)22:16 ID:RSUrvfLc(2/2) AAS
>>970
clone したら怒られるの？ マジか？ それ本当に git 使ってるの？
972: 2022/04/22(金)22:48 ID:4bmaw9DX(1) AAS
forkがcloneだからといってcloneがすべてforkなわけがない
973(1): 2022/04/22(金)23:04 ID:a+ReXgZI(2/2) AAS
おまえらって、gitについて講釈ばかりたれてるけど
全く本業ができないわけじゃないよなｗ
うちの会社にもいるわ
講釈たれてる暇があるならさっさとコーディング終わらせろよｗｗｗｗｗ
974: 2022/04/22(金)23:12 ID:UMBGLRP1(1) AAS
根拠のないレッテル貼りによる謎のマウンティング
975(2): 2022/04/22(金)23:30 ID:pOr/JbKA(1) AAS
>>971
forkはgithubの別アカウントへリポジトリをcloneする
俺らはpushしてpull requestするとか素人さんを混乱させる戯言をよく使うが、本来のgithubのpull requestはforkした自分のアカウント下のリポジトリのブランチをpullしてmergeしてもらうことをrequestする
pushしてpull requestは正しくはpushしてmerge requestと言うべきで、Gitlabは正しくmerge requestと呼んでいたと思う
merge requestで作業してる職場で、pull requestしたら怒れるということだろう
976(2): 2022/04/23(土)00:07 ID:iISBdnEI(1/6) AAS
>>975
何を言ってるかわからない。
pull というのは「 fetch して merge 」という操作をまとめてやるだけのコマンドなので当然 merge の意味を内包してる。
fetch せずに merge って言いたいの？ それってどうやって対象を持ってくるの？
自分のリポジトリから持ってくるだけなら他人から request される必要ないし？
977(1): 2022/04/23(土)00:13 ID:iISBdnEI(2/6) AAS
ちなみに push というのは remore への merge を指示するコマンドな。
978(1): 2022/04/23(土)00:51 ID:1bxGV6XJ(1/3) AAS
>>976
いや同一のGitHubリポジトリ上でpull requestをマージするときにfetchは要らないでしょ
>>975の言うとおり、本来リポジトリを跨がるからfetch+mergeでpullなんだよ
979(1): 2022/04/23(土)00:59 ID:HOOXt/T3(1/9) AAS
>>976
「本来のgithubのpull requestはforkした自分のアカウント下のリポジトリのブランチをpullしてmergeしてもらうことをrequestする 」
これはちょっと間違えた
fetchしてmergeしてもらうことをrequestするからpull requestね
それでmerge requestだけど、>>978の言うようにすでに共有ブランチへpush済みのブランチをmergeすることをrequestするから、mergeだけrequestでfetchはrequestしない
自分が仕事で使うのは主にこっち
>>977
pushは厳密に言えばFastForwardのmergeだけど、pushのことをmergeとはあまり呼ばないな
980(2): 2022/04/23(土)01:35 ID:iISBdnEI(3/6) AAS
>>979
push した時点で merge されてるんでは？
push はデフォルトでは fast foward のみだけど、remote の設定によって普通の merge もいける。
共有リポジトリ上の feature branch を共有リポジトリ上の master branch に merge みたいな話をしたいのかもしれないけど、通常は共有リポジトリ上で完結させたりしない。
1) 共有リポジトリ上の feature branch を手元に fetch
2) fetch した feature branch を手元の master btanch に merge
3) 手元の master branch を共有リポジトリへの push
という手順を取る。
1) + 2) が pull 動作。fetch 無しは個人の作業リポジトリへの push が必要になるので普通やらないし、できない。
981(1): 2022/04/23(土)01:58 ID:HOOXt/T3(2/9) AAS
あれ？もしかしてgithubだと違うのかな？自分が仕事で使うbitbucketの共有リポジトリでやる場合のデフォルトでは、プルリクエストの承認とマージは共有リポジトリ上で完結する
もちろんローカルでfeature branchをmasterへマージしてmasterをpushしてもいいんだけど、それは正式な手順では無い
githubでも同じことできるよね？
1) 共有リポジトリ上に feature branch を作成
2) 共有リポジトリ上の feature branch を手元にfetchしてcheckoutして修正をコミット
4) 手元の feature branch を共有リポジトリ上の feature branch へ push
5) プルリクエスト(マージリクエストだけど)をブラウザ上で作成
6) マージ権限者がブラウザ上でリクエストを承認してマージする
feture branchは正式にはブラウザで共有リポジトリ上に作るけど、ローカルで作ってpushしてもいい
982(1): 2022/04/23(土)02:02 ID:HOOXt/T3(3/9) AAS
>>980
pushでFFじゃないmergeってできるの？できても今は普通しないでしょ
FFでmergeできない場合には、ローカルでmergeしてFFにしてpushするか、push -sで上書きが普通だし
上下前次1-新書関写板覧索設栞歴
あと 20 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.735s*