Git 17

**デフォルトの名無しさん** · 2020/09/02(水) 12:18:30.39

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
-
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2022/04/22(金) 02:04:37.85

ブランチがないとお互いのコミットを観測することができない
人の変更を見ようと互いにpush+pullすると常にmergeが伴うので、いわゆる観測者効果みたいな面倒くささが生まれる
プロジェクトの規模やリリースの複雑性が増すにつれてより困る
よくある例では、次バージョンの開発を初めている人がいるときhotfixを出せない
featureブランチのpushはオアズケを命じられて、その間ソースレビューも滞る
ブランチをforkに置き換えても同じ

**デフォルトの名無しさん** · 2022/04/22(金) 09:52:33.39

各個人のGitHubアカウントにforkしてリポジトリ間のpull requestでマージしていく流派も存在する
本来のGitやGitHubの想定する使い方としては正しくてOSS文化的にも好ましいやり方ではあるんだが、企業での開発ではほとんど採用されない
単一のGitHubリポジトリで中央集権的に管理した方が楽だからね

**デフォルトの名無しさん** · 2022/04/22(金) 12:20:17.30

AからA'とBの2つを作りたくなったときって、
ブランチなしでどうやるんだろうな

**デフォルトの名無しさん** · 2022/04/22(金) 12:30:42.99

>>963
ブランチは「実装していること」を表すので、複数の機能を並行して開発するときは必須。
よくあるのは
・通常の開発版とリリース版／デバッグ版を分けて、デバッグリリースを早くする＆開発版への取り込みを管理しやすくする
・開発する機能ごとにブランチを用意して、互いの干渉を減らす＆マージをやりやすくする
あたり。

**デフォルトの名無しさん** · 2022/04/22(金) 14:20:44.25

自分のアカウントにforkするスタイルの開発しか経験ない人が
単一GitHubリポジトリ運用な会社に入ってforkして怒られるのはGitHubあるある

**デフォルトの名無しさん** · 2022/04/22(金) 21:56:45.85

fork って何？ git 用語に翻訳して。

**デフォルトの名無しさん** · 2022/04/22(金) 22:05:44.96

clone

**デフォルトの名無しさん** · 2022/04/22(金) 22:16:51.65

>>970
clone したら怒られるの？マジか？それ本当に git 使ってるの？

**デフォルトの名無しさん** · 2022/04/22(金) 22:48:01.99

forkがcloneだからといってcloneがすべてforkなわけがない

**デフォルトの名無しさん** · 2022/04/22(金) 23:04:27.06

おまえらって、gitについて講釈ばかりたれてるけど
全く本業ができないわけじゃないよなｗ

うちの会社にもいるわ
講釈たれてる暇があるならさっさとコーディング終わらせろよｗｗｗｗｗ

**デフォルトの名無しさん** · 2022/04/22(金) 23:12:27.31

根拠のないレッテル貼りによる謎のマウンティング

**デフォルトの名無しさん** · 2022/04/22(金) 23:30:46.77

>>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したら怒れるということだろう

**デフォルトの名無しさん** · 2022/04/23(土) 00:07:18.92

>>975
何を言ってるかわからない。
pull というのは「 fetch して merge 」という操作をまとめてやるだけのコマンドなので当然 merge の意味を内包してる。
fetch せずに merge って言いたいの？それってどうやって対象を持ってくるの？
自分のリポジトリから持ってくるだけなら他人から request される必要ないし？

**デフォルトの名無しさん** · 2022/04/23(土) 00:13:01.25

ちなみに push というのは remore への merge を指示するコマンドな。

**デフォルトの名無しさん** · 2022/04/23(土) 00:51:13.69

>>976
いや同一のGitHubリポジトリ上でpull requestをマージするときにfetchは要らないでしょ
>>975の言うとおり、本来リポジトリを跨がるからfetch+mergeでpullなんだよ

**デフォルトの名無しさん** · 2022/04/23(土) 00:59:48.76

>>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とはあまり呼ばないな

**デフォルトの名無しさん** · 2022/04/23(土) 01:35:18.29

>>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 が必要になるので普通やらないし、できない。

**デフォルトの名無しさん** · 2022/04/23(土) 01:58:40.02

あれ？もしかして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してもいい

**デフォルトの名無しさん** · 2022/04/23(土) 02:02:56.04

>>980
pushでFFじゃないmergeってできるの？できても今は普通しないでしょ
FFでmergeできない場合には、ローカルでmergeしてFFにしてpushするか、push -sで上書きが普通だし

**デフォルトの名無しさん** · 2022/04/23(土) 02:12:55.85

>>982
できるけど、おすすめではない。
ただ push は merge と同じ機構という点が理解できてれば良い。

**デフォルトの名無しさん** · 2022/04/23(土) 02:14:20.66

普通はローカルでマージしたものをプッシュする

**デフォルトの名無しさん** · 2022/04/23(土) 02:23:24.07

>>981
いきなり共用リポジトリ上でマージしたりしない。そういう運用ルールの組織があるとしたらかなり頭悪い。git の使い方が半分しか理解できてない。
共用リポジトリは問題があってもロールバックできない(超めんどう)なので、共用リポジトリの master には手元でのテスト等が終わって問題ないもののみを入れるのが普通。

**デフォルトの名無しさん** · 2022/04/23(土) 02:38:54.73

ローカルでマージしてmasterへpushするって言ってる人たちはmasterへのpush権限をみんなが持ってるの？

**デフォルトの名無しさん** · 2022/04/23(土) 02:43:01.86

master へ push する権限を持ってる人がローカルで master に merge する作業をする。当然の話。

**デフォルトの名無しさん** · 2022/04/23(土) 02:47:09.01

分野にもよるのかもしれんが、少なくともWeb系はGitHub上でマージするのが普通
直接mainにマージしたくないなら

**デフォルトの名無しさん** · 2022/04/23(土) 02:49:26.76

>>985
もちろんプルリクエスト出す段階でローカルにテストは済んでる前提だし、masterへマージされた後にそれがダメならrevertするよ？

プルリクエストを承認できてmasterへマージできる人は特定の人だけだし、それをマージする前にテストが済んでるかどうかとかをリクエスト者に確認する
そのためにプルリクエスト上でいろいろやりとりできるようになってるわけだし

というか>>980とかはgithubを単にgitのリポジトリとして利用するだけのやりかただよね？別にgithub使う必要無くない？なんでgithub使ってるの？

**988** · 2022/04/23(土) 02:51:33.02

失礼
直接mainにマージしたくないならdevelopブランチ等を間に置く
各自がいちいちローカルでマージして手元でテストなんてしてたら、みんなそれぞれ状態がバラバラで何テストしてるのか分からなくならないか？
特定の一人だけがmainにマージできるような超集権的な体制でないと成立しないと思う

**デフォルトの名無しさん** · 2022/04/23(土) 02:52:15.37

>>989
うちのやり方では「master へ push する権限を持ってる人がローカルで master に merge する作業をする。」か「ブラウザ上でマージしてしまうか」はその権限持ちがプルリクエストを見て判断する

**デフォルトの名無しさん** · 2022/04/23(土) 03:00:56.62

統合的なテストはmasterにマージされた後に動かして、それでダメならrevert
統合的なテストが済んだところはtagが打たれてリリースはそのtagがあるとこまでしか行われない

**デフォルトの名無しさん** · 2022/04/23(土) 03:22:27.74

久しぶりだけど次スレ立ててみる

**デフォルトの名無しさん** · 2022/04/23(土) 03:27:15.61

次スレ

Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945

**デフォルトの名無しさん** · 2022/04/23(土) 03:39:41.93

>>994
乙

**デフォルトの名無しさん** · 2022/04/23(土) 09:32:57.73

>>973
劣等感抱いてるんだね。わかるよ

**デフォルトの名無しさん** · 2022/04/23(土) 09:43:28.49

未だsvnから離れられない人かな

**デフォルトの名無しさん** · 2022/04/23(土) 11:37:43.64

いえ、ディレクトリコピーで済ませています

**デフォルトの名無しさん** · 2022/04/23(土) 14:25:06.82

Git 18
https://mevius.5ch.net/test/read.cgi/tech/1631002816/

**デフォルトの名無しさん** · 2022/04/23(土) 14:36:55.00

質問いいですか？

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 598日 2時間 18分 27秒