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/10(日) 23:03:53.52

>>891
なんの意味？

**デフォルトの名無しさん** · 2022/04/10(日) 23:58:14.27

分散型リポジトリの意味かな？

つーかcommit→pushの流れが癖になるとまずいぞ

develop or masterで作業してるかfeatureブランチをpushすることになる

**デフォルトの名無しさん** · 2022/04/11(月) 00:51:42.12

>>890
同じにしないといけない
違ってるとGitHub上でコミットとユーザーが紐付かない
なおGitHubのメールアドレスは複数設定できる

**デフォルトの名無しさん** · 2022/04/11(月) 01:06:26.04

いつプルすべきなのかさっぱり分からないんだけど
いちいちフェッチして更新されてたらプルなの？
svnの時はフォルダのアイコンが変わるから、すぐ分かったんだけど
ｇｉｔはめんどくさくてしかたねー

**デフォルトの名無しさん** · 2022/04/11(月) 01:21:42.99

>>895
フォルダーのアイコンが変わるのはsvnの機能ではないだろw

**デフォルトの名無しさん** · 2022/04/11(月) 01:26:34.08

ちんちんシュッ！シュッ！シュッ！

**デフォルトの名無しさん** · 2022/04/11(月) 03:26:40.92

>>895
そもそもsvnの挙動を勘違いしてんじゃん

**890** · 2022/04/11(月) 07:24:40.88

>>894
レスありがとうございます。

そうしますと、
複数のメンバーでGitHubの一つのアカウント(リポジトリ)を共有する時の
各メンバーを識別するIDは、どこで指定するのでしょうか？

**デフォルトの名無しさん** · 2022/04/11(月) 07:35:11.19

どんなメールアドレスでもpushできるよ

**デフォルトの名無しさん** · 2022/04/11(月) 08:54:42.93

>>896
>>898

本筋には触れずに、否定をするﾜﾗ

**デフォルトの名無しさん** · 2022/04/11(月) 09:14:16.92

>>899
関係ない。各自が自分のGitHub userに設定済みのメールアドレスでコミットすればいい。
GitHub上で制御できるのは「誰がリポジトリにpushできるか」までで、>>900も言ってるがどんなメールアドレスのコミットが含まれていてもpushできる。
たまたまコミットのメールアドレスがGitHub userと同じならGitHub上でそのユーザーがコミットしたように見えるというただそれだけのこと。

**デフォルトの名無しさん** · 2022/04/11(月) 14:06:10.85

>>899
githubでプライベートリポジトリを複数ユーザで共有する場合は、共有するユーザみんな別々のアカウント作って、誰かが作ったレポジトリに他のユーザを招待して、pushするときにはそれぞれ各ユーザのアカウントで認証された状態ですることになるよね
だから上でもだれか言ってるように、コミットのメールアドレスは認証で使われるわけじゃないから、どんなメールアドレスでもpushできる

しかし、コミットのメールアドレスは重要でないというわけでもなくて、コミット一覧とか表示させたときにコミットのメールアドレスに基づいてユーザ名とか写真を表示したりするので、githubのアカウントに登録してあるメールアドレスをgitの方にも登録しておくほうが良い

**デフォルトの名無しさん** · 2022/04/11(月) 20:59:30.97

>>901
少し上のレスを見ればわかるけど、その質問は「また釣りか」と思われてまともなレスは付かない。

**デフォルトの名無しさん** · 2022/04/13(水) 01:15:32.19

とある本の不要になったブランチを削除する手順で
①リモートリポジトリの消したいブランチを削除
②Sourcetreeのフェッチのリモートで消えた追跡ブランチを消去(Prune)
③Sourcetreeの消したいローカルブランチを右クリックして削除
とありますが、①がリモートリポジトリのブランチを削除、
③がローカルのそれだとすると
②の手順にはどんな意味があるのでしょうか

**デフォルトの名無しさん** · 2022/04/13(水) 02:12:16.50

ブランチには①リモートブランチ ②(リモート)追跡ブランチ ③ローカルブランチの3種類がある
文脈によってこれらはしばしば混同されるので気をつけていないと混乱する
①はサーバー側にあり、②③はクライアント側にある
②は常に①のコピーで、フェッチするたびに①の最新と同期される
だからネットワークに繋がっていなくてもいつでもリモートのログが見れる
「リモートブランチのログを見る」というとき、正確には①ではなく②のログを見る行為を指す
フェッチしていなければ①②③が全て別のコミットを指すこともある
②を消し忘れると、サーバー側のブランチは削除済みなのに、そのクライアントからはまだリモートブランチが消えていないように見える

**デフォルトの名無しさん** · 2022/04/13(水) 03:53:52.80

>>906
詳しいご説明ありがとうございます！

**デフォルトの名無しさん** · 2022/04/13(水) 21:31:02.16

Git v2.35.2

**デフォルトの名無しさん** · 2022/04/13(水) 21:31:48.03

Git v2.36.0-rc2

**デフォルトの名無しさん** · 2022/04/14(木) 12:56:35.38

Git v2.35.3

**デフォルトの名無しさん** · 2022/04/14(木) 14:21:34.39

Git v2.36.0-rc3

**デフォルトの名無しさん** · 2022/04/14(木) 14:56:42.75

「Git for Windows」のシェルが「bash 4.4」から「bash 5.1」へ～Vista対応も終了
https://forest.watch.impress.co.jp/docs/news/1402/011/

Windowsで使ってる人（居る？）注意な

**デフォルトの名無しさん** · 2022/04/14(木) 21:19:31.45

居る？ってどういう意味？

**デフォルトの名無しさん** · 2022/04/14(木) 21:40:37.08

おるかーー？
よーし、おるな！

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

折るかーー？
よーし、折るな！ボキッ

**デフォルトの名無しさん** · 2022/04/14(木) 22:52:34.66

ここやでトントン

**デフォルトの名無しさん** · 2022/04/14(木) 23:33:30.30

まさかMacなんて使ってんの？

**デフォルトの名無しさん** · 2022/04/15(金) 00:07:36.02

>>917
Windows Mac Linux
全部使ってる

**デフォルトの名無しさん** · 2022/04/15(金) 00:18:20.61

>>918
いいなぁ

**デフォルトの名無しさん** · 2022/04/15(金) 18:54:21.17

GUIのGitクライアントは面倒だよ
なんて言ってる先輩いるだけど
ほとんどコードは書けなくて、コピペしてそのコピペしたコードの意味も分かってない

そんなので、いくらgitが使えても意味なくね

**デフォルトの名無しさん** · 2022/04/15(金) 19:37:30.49

>>920
何が言いたいのがわからんが、コマンドラインでGitが使いこなせなくて悔しいの？
コードが書けるのとGitを使いこなせるかどうかは直接は関係無いし、コピペとGitを使いこなして目的が達成できてるのならばそれは意味があることだよ

**デフォルトの名無しさん** · 2022/04/15(金) 20:07:56.61

CUIなら同じことを繰り返したり再現するのも容易いし、スクリプトに組み込んで自動化したり本番処理を分けたり他人に渡すのも容易。
GUIも便利だけどCUIにもたくさんメリットがあるのよ

**デフォルトの名無しさん** · 2022/04/15(金) 21:12:39.95

僕も全くプログラム書けないけど
フリーランスのGit屋だぞ

**デフォルトの名無しさん** · 2022/04/15(金) 21:35:15.77

GUIのgit使おうとしたけどわけわからんくて投げたわ

やっぱコマンドラインよ

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

GUIもせめて自動実行マクロがあればマシなんだけどな。
OfficeのVBAみたいなやつ。

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

>>925
それgitコマンド使ったバッチファイルやスクリプトでよくね？

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

コマンドを打ってるだけで仕事してるフリしてる奴いるわ
たかがステージングするのに何分かかってんだよ
それならGUI使ったほうがグイっと終わるだろ

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

gitkだっけ

**デフォルトの名無しさん** · 2022/04/16(土) 00:17:37.39

CUIだろうとGUIだろうと、どのファイルのどの行をコミットに含めるかは慎重に選べ
ゴミみたいなコミット作ってんじゃねぇ

**デフォルトの名無しさん** · 2022/04/16(土) 01:06:24.34

>>920
gitを否定しようと思ったけどできなかったんだよね？
だからgitを使ってる人を変わりに叩いて
自己満足してるでしょ？バレバレｗ

**デフォルトの名無しさん** · 2022/04/16(土) 01:08:00.12

>>927
CUIのほうがGUIよりも快適だからCUIを使ってるんだよ
文字使えば相手に意味を伝えられるのに
絵を書いて伝えたいなんて思わないでしょ？

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

GUIで確認してCUIで実行するのが一番効率良くね？
GUIは一覧性が高いが、作業効率はCUIの方が良い

**デフォルトの名無しさん** · 2022/04/16(土) 03:09:40.28

st=status -s とか
ll=log --date-order --oneline --graphとか
alias設定すれば一覧性で困ることはないぞ

**デフォルトの名無しさん** · 2022/04/16(土) 03:40:01.37

それくらいのタイプ量ならエイリアス設定する方が面倒だわ

**デフォルトの名無しさん** · 2022/04/16(土) 03:55:07.91

道具の方にこだわってる奴って本業は全然できない奴多いよな
この5番、30万だぞってイキってて100程度で回ってるガキ多すぎ宿題

**デフォルトの名無しさん** · 2022/04/16(土) 05:50:52.44

道具にこだわらないからCUIでgitなんだろ
GUIのはOSによっては使えない場合もあるしいちいち覚えるの面倒だし
CUIなら設定ファイルちょろっとコピーすればいつもと同じ感覚で使えるし
git使わないって選択肢はもう無しな
gitはもう道具というより共通フォーマットだ

**デフォルトの名無しさん** · 2022/04/16(土) 05:56:08.79

>>933
その辺は頻繁に使うんでエイリアスじゃなくて3～4文字のシェル関数だわ
とくにgit logの方は--pretty=format:～も指定したいんで手打ちはありえん

**デフォルトの名無しさん** · 2022/04/16(土) 10:28:49.22

基本的にCUI派だけどログ出していくつかdiffを見るみたいな操作はGUI使うなあ
これをCUIで高効率でやる手段があるなら知りたい

**デフォルトの名無しさん** · 2022/04/16(土) 11:07:45.89

>>936
CUIかGUIかなんて問題なのか
どっちでも同じじゃん

やっぱりコマンドをタイプしてる方がカッコいいと思うタイプ？w

**デフォルトの名無しさん** · 2022/04/16(土) 11:10:09.03

>>939
コマンドをタイプするのはかっこいいと思ってしまったから
お前はそんな書き込みをしたんだよね？

**デフォルトの名無しさん** · 2022/04/16(土) 11:12:54.01

いや俺はvscode一択

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

あるある

コマンドを使ってるカッコイイと勘違い
Linuxを使ってるカッコイイと勘違い
ダークテーマを使ってるカッコイイと勘違い
vi emacsを使ってるカッコイイと勘違い

**デフォルトの名無しさん** · 2022/04/16(土) 12:28:47.16

TortoiseGitしか使ってなくてすいません

**デフォルトの名無しさん** · 2022/04/16(土) 12:44:01.14

ｶｺｲｲ

**デフォルトの名無しさん** · 2022/04/18(月) 20:18:29.80

CUIかGUIかなんてどーでも良いことには一切こだわらず
俺にとって使いやすい方法を採用してる俺様ｶｺｲｲ

**デフォルトの名無しさん** · 2022/04/19(火) 12:06:40.00

>>942
そのとおり、何かを使っているからカッコイイのではない
俺だからカッコいいのだ

**デフォルトの名無しさん** · 2022/04/19(火) 17:55:42.79

Git v2.36.0

**デフォルトの名無しさん** · 2022/04/19(火) 23:15:59.06

プルリクって要る？
製品名出せば誰でも知ってるソフトの開発でも
目クラマージだぞ
正直、いちいちプルリク出すくらいなら、そっちでマージしてほしい
権限考え直してほしいわ

**デフォルトの名無しさん** · 2022/04/19(火) 23:29:05.23

>>948
gitにそんな機能はありません

**デフォルトの名無しさん** · 2022/04/20(水) 15:44:31.97

エビル(evil)マージ

**デフォルトの名無しさん** · 2022/04/20(水) 18:45:19.22

アークマージって要る？メリットは何ですか？
→ イオナズンが使えます

**デフォルトの名無しさん** · 2022/04/21(木) 15:42:47.36

先輩「CUIのほうがgitの機能をすべて使えるからいいよ」

おれ「pullするときにディレクトリを指定するのは、どんなコマンドを実行すればいいですか？」

先輩「git pullしかやったことないから分からない」

おれ「・・・」

**デフォルトの名無しさん** · 2022/04/21(木) 17:41:01.53

>>952
別に先輩おかしくないけど

**デフォルトの名無しさん** · 2022/04/21(木) 18:49:26.99

ディレクトリを指定してpullする機能なんて無いし
pullに引数指定しなければいけないような状況はfetchとmergeを使うから、おれもgit pullの引数有りの挙動は把握してない

**デフォルトの名無しさん** · 2022/04/21(木) 18:55:10.99

おまえらって本質がわかないのか？

pullかどうかなんてのは本質でない

git hoge

でも論理は同じ

**デフォルトの名無しさん** · 2022/04/21(木) 19:16:46.07

ちょっと例えがアレだったね
シニカルなことを表現するときはバシッと一発で決めてかないとこういう残念な雰囲気になる
それもまた世のことわり

**デフォルトの名無しさん** · 2022/04/21(木) 19:27:25.31

CUIの方がgitの機能がすべて使えるのは正しい
CUIで使う人が全てのコマンドのオプションを知ってる必要なんてない

CUIで使うのを難しく考え過ぎじゃないかな？
どのgitコマンドで何ができるかを把握できてれば十分で、細かい指定は大雑把に覚えてればいいよ
良く使う操作は短いエイリアスやシェル関数にしてしまうし、普段あまりやらない操作はコピペでもいいし、man見て調べればいいし、いまのシェルは履歴も補完も使いやすいからgitの長いオプション名なんて覚える必要も無い

**デフォルトの名無しさん** · 2022/04/21(木) 19:27:50.71

別にCUI/GUIに限らないけど、どのgitコマンドで何ができるか何が起こるかを理解できているのが重要
gitのコマンドは後戻りできるものが多くて、その方法を理解できてると楽に使える
後戻りする系の手段はあれこれ用意されてるけど、CUIの方が充実してるかな

**デフォルトの名無しさん** · 2022/04/21(木) 21:14:31.11

git pullしか実行したことないなら、GUI使ってもボタン一発だろｗ

**デフォルトの名無しさん** · 2022/04/21(木) 21:34:43.05

git pull はコンフリクトで失敗することがあるからボタン一発で済むとは限らない

**デフォルトの名無しさん** · 2022/04/21(木) 21:37:37.80

CUIに劣等感感じる必要ないんやで
どっちも便利だから好きな方使え

**デフォルトの名無しさん** · 2022/04/21(木) 21:46:02.93

GUIとCUIの併用だな
なんでどっちかしか使えないと考えるんだろう

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

ブランチが必要な理由が分からない
リモートからクローンしてきている時点で、origin/masterとは別のリポジトリが個々人に存在するんだし
コミットも個々人のリポジトリに対して行うわけでしょ

一度もブランチ生やしてなんて一度も指示されたことないわ

**デフォルトの名無しさん** · 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 する作業をする。」か「ブラウザ上でマージしてしまうか」はその権限持ちがプルリクエストを見て判断する