22/04/19 12:06:40 +aQMqQh4.net
>>948
そのとおり、何かを使っているからカッコイイのではない
俺だからカッコいいのだ
986:デフォルトの名無しさん
22/04/19 17:55:42.79 2NjgmpR8.net
Git v2.36.0
987:デフォルトの名無しさん
22/04/19 23:15:59 fQcWHs5l.net
プルリクって要る？
製品名出せば誰でも知ってるソフトの開発でも
目クラマージだぞ
正直、いちいちプルリク出すくらいなら、そっちでマージしてほしい
権限考え直してほしいわ
988:デフォルトの名無しさん
22/04/19 23:29:05.23 CsQiBOLb.net
>>954
gitにそんな機能はありません
989:デフォルトの名無しさん
22/04/20 15:44:31 9cmYpPww.net
エビル(evil)マージ
990:デフォルトの名無しさん
22/04/20 18:45:19.22 aTy1WRu8.net
アークマージって要る？メリットは何ですか？
→ イオナズンが使えます
991:デフォルトの名無しさん
22/04/21 15:42:47.36 Ex423fK8.net
先輩「CUIのほうがgitの機能をすべて使えるからいいよ」
おれ「pullするときにディレクトリを指定するのは、どんなコマンドを実行すればいいですか？」
先輩「git pullしかやったことないから分からない」
おれ「・・・」
992:デフォルトの名無しさん
22/04/21 17:41:01.53 haKrn/PJ.net
>>958
別に先輩おかしくないけど
993:デフォルトの名無しさん
22/04/21 18:49:26.99 BFaC4LhO.net
ディレクトリを指定してpullする機能なんて無いし
pullに引数指定しなければいけないような状況はfetchとmergeを使うから、おれもgit pullの引数有りの挙動は把握してない
994:デフォルトの名無しさん
22/04/21 18:55:10.99 Ex423fK8.net
おまえらって本質がわかないのか？
pullかどうかなんてのは本質でない
git hoge
でも論理は同じ
995:デフォルトの名無しさん
22/04/21 19:16:46.07 KtzHzoax.net
ちょっと例えがアレだったね
シニカルなことを表現するときはバシッと一発で決めてかないとこういう残念な雰囲気になる
それもまた世のことわり
996:デフォルトの名無しさん
22/04/21 19:27:25.31 BFaC4LhO.net
CUIの方がgitの機能がすべて使えるのは正しい
CUIで使う人が全てのコマンドのオプションを知ってる必要なんてない
CUIで使うのを難しく考え過ぎじゃないかな？
どのgitコマンドで何ができるかを把握できてれば十分で、細かい指定は大雑把に覚えてればいいよ
良く使う操作は短いエイリアスやシェル関数にしてしまうし、普段あまりやらない操作はコピペでもいいし、man見て調べればいいし、いまのシェルは履歴も補完も使いやすいからgitの長いオプション名なんて覚える必要も無い
997:デフォルトの名無しさん
22/04/21 19:27:50.71 BFaC4LhO.net
別にCUI/GUIに限らないけど、どのgitコマンドで何ができるか何が起こるかを理解できているのが重要
gitのコマンドは後戻りできるものが多くて、その方法を理解できてると楽に使える
後戻りする系の手段はあれこれ用意されてるけど、CUIの方が充実してるかな
998:デフォルトの名無しさん
22/04/21 21:14:31.11 Ex423fK8.net
git pullしか実行したことないなら、GUI使ってもボタン一発だろｗ
999:デフォルトの名無しさん
22/04/21 21:34:43.05 F4v8aJSe.net
git pull はコンフリクトで失敗することがあるからボタン一発で済むとは限らない
1000:デフォルトの名無しさん
22/04/21 21:37:37.80 ZCLpZV4/.net
CUIに劣等感感じる必要ないんやで
どっちも便利だから好きな方使え
1001:デフォルトの名無しさん
22/04/21 21:46:02.93 FUPABV2N.net
GUIとCUIの併用だな
なんでどっちかしか使えないと考えるんだろう
1002:デフォルトの名無しさん
22/04/22 00:44:19.39 a+ReXgZI.net
ブランチが必要な理由が分からない
リモートからクローンしてきている時点で、origin/masterとは別のリポジトリが個々人に存在するんだし
コミットも個々人のリポジトリに対して行うわけでしょ
一度もブランチ生やしてなんて一度も指示されたことないわ
1003:デフォルトの名無しさん
22/04/22 02:04:37.85 /nIvhavJ.net
ブランチがないとお互いのコミットを観測することができない
人の変更を見ようと互いにpush+pullすると常にmergeが伴うので、いわゆる観測者効果みたいな面倒くささが生まれる
プロジェクトの規模やリリースの複雑性が増すにつれてより困る
よくある例では、次バージョンの開発を初めている人がいるときhotfixを出せない
featureブランチのpushはオアズケを命じられて、その間ソースレビューも滞る
ブランチをforkに置き換えても同じ
1004:デフォルトの名無しさん
22/04/22 09:52:33.39 ZbT6iK7O.net
各個人のGitHubアカウントにforkしてリポジトリ間のpull requestでマージしていく流派も存在する
本来のGitやGitHubの想定する使い方としては正しくてOSS文化的にも好ましいやり方ではあるんだが、企業での開発ではほとんど採用されない
単一のGitHubリポジトリで中央集権的に管理した方が楽だからね
1005:デフォルトの名無しさん
22/04/22 12:20:17.30 dVlUoLXX.net
AからA'とBの2つを作りたくなったときって、
ブランチなしでどうやるんだろうな
1006:デフォルトの名無しさん
22/04/22 12:30:42.99 wri6W8iQ.net
>>969
ブランチは「実装していること」を表すので、複数の機能を並行して開発するときは必須。
よくあるのは
・通常の開発版とリリース版／デバッグ版を分けて、デバッグリリースを早くする＆開発版への取り込みを管理しやすくする
・開発する機能ごとにブランチを用意して、互いの干渉を減らす＆マージをやりやすくする
あたり。
1007:デフォルトの名無しさん
22/04/22 14:20:44.25 QpAASndC.net
自分のアカウントにforkするスタイルの開発しか経験ない人が
単一GitHubリポジトリ運用な会社に入ってforkして怒られるのはGitHubあるある
1008:デフォルトの名無しさん
22/04/22 21:56:45.85 RSUrvfLc.net
fork って
1009:何？ git 用語に翻訳して。
1010:デフォルトの名無しさん
22/04/22 22:05:44.96 0DWZpb5V.net
clone
1011:デフォルトの名無しさん
22/04/22 22:16:51.65 RSUrvfLc.net
>>976
clone したら怒られるの？ マジか？ それ本当に git 使ってるの？
1012:デフォルトの名無しさん
22/04/22 22:48:01 4bmaw9DX.net
forkがcloneだからといってcloneがすべてforkなわけがない
1013:デフォルトの名無しさん
22/04/22 23:04:27 a+ReXgZI.net
おまえらって、gitについて講釈ばかりたれてるけど
全く本業ができないわけじゃないよなｗ
うちの会社にもいるわ
講釈たれてる暇があるならさっさとコーディング終わらせろよｗｗｗｗｗ
1014:デフォルトの名無しさん
22/04/22 23:12:27.31 UMBGLRP1.net
根拠のないレッテル貼りによる謎のマウンティング
1015:デフォルトの名無しさん
22/04/22 23:30:46.77 pOr/JbKA.net
>>977
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したら怒れるということだろう
1016:デフォルトの名無しさん
22/04/23 00:07:18.92 iISBdnEI.net
>>981
何を言ってるかわからない。
pull というのは「 fetch して merge 」という操作をまとめてやるだけのコマンドなので当然 merge の意味を内包してる。
fetch せずに merge って言いたいの？ それってどうやって対象を持ってくるの？
自分のリポジトリから持ってくるだけなら他人から request される必要ないし？
1017:デフォルトの名無しさん
22/04/23 00:13:01.25 iISBdnEI.net
ちなみに push というのは remore への merge を指示するコマンドな。
1018:デフォルトの名無しさん
22/04/23 00:51:13.69 1bxGV6XJ.net
>>982
いや同一のGitHubリポジトリ上でpull requestをマージするときにfetchは要らないでしょ
>>981の言うとおり、本来リポジトリを跨がるからfetch+mergeでpullなんだよ
1019:デフォルトの名無しさん
22/04/23 00:59:48.76 HOOXt/T3.net
>>982
「本来のgithubのpull requestはforkした自分のアカウント下のリポジトリのブランチをpullしてmergeしてもらうことをrequestする 」
これはちょっと間違えた
fetchしてmergeしてもらうことをrequestするからpull requestね
それでmerge requestだけど、>>984の言うようにすでに共有ブランチへpush済みのブランチをmergeすることをrequestするから、mergeだけrequestでfetchはrequestしない
自分が仕事で使うのは主にこっち
>>983
pushは厳密に言えばFastForwardのmergeだけど、pushのことをmergeとはあまり呼ばないな
1020:デフォルトの名無しさん
22/04/23 01:35:18.29 iISBdnEI.net
>>985
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 が必要になるので普通やらないし、できない。
1021:デフォルトの名無しさん
22/04/23 01:58:40.02 HOOXt/T3.net
あれ？もしかして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してもいい
1022:デフォルトの名無しさん
22/04/23 02:02:56.04 HOOXt/T3.net
>>986
1023:pushでFFじゃないmergeってできるの？できても今は普通しないでしょ FFでmergeできない場合には、ローカルでmergeしてFFにしてpushするか、push -sで上書きが普通だし
1024:デフォルトの名無しさん
22/04/23 02:12:55.85 iISBdnEI.net
>>988
できるけど、おすすめではない。
ただ push は merge と同じ機構という点が理解できてれば良い。
1025:デフォルトの名無しさん
22/04/23 02:14:20.66 XK6u/IcU.net
普通はローカルでマージしたものをプッシュする
1026:デフォルトの名無しさん
22/04/23 02:23:24.07 iISBdnEI.net
>>987
いきなり共用リポジトリ上でマージしたりしない。そういう運用ルールの組織があるとしたらかなり頭悪い。git の使い方が半分しか理解できてない。
共用リポジトリは問題があってもロールバックできない(超めんどう)なので、共用リポジトリの master には手元でのテスト等が終わって問題ないもののみを入れるのが普通。
1027:デフォルトの名無しさん
22/04/23 02:38:54.73 HOOXt/T3.net
ローカルでマージしてmasterへpushするって言ってる人たちはmasterへのpush権限をみんなが持ってるの？
1028:デフォルトの名無しさん
22/04/23 02:43:01.86 iISBdnEI.net
master へ push する権限を持ってる人がローカルで master に merge する作業をする。当然の話。
1029:デフォルトの名無しさん
22/04/23 02:47:09 1bxGV6XJ.net
分野にもよるのかもしれんが、少なくともWeb系はGitHub上でマージするのが普通
直接mainにマージしたくないなら
1030:デフォルトの名無しさん
22/04/23 02:49:26.76 HOOXt/T3.net
>>991
もちろんプルリクエスト出す段階でローカルにテストは済んでる前提だし、masterへマージされた後にそれがダメならrevertするよ？
プルリクエストを承認できてmasterへマージできる人は特定の人だけだし、それをマージする前にテストが済んでるかどうかとかをリクエスト者に確認する
そのためにプルリクエスト上でいろいろやりとりできるようになってるわけだし
というか>>986とかはgithubを単にgitのリポジトリとして利用するだけのやりかただよね？別にgithub使う必要無くない？なんでgithub使ってるの？
1031:988
22/04/23 02:51:33.02 1bxGV6XJ.net
失礼
直接mainにマージしたくないならdevelopブランチ等を間に置く
各自がいちいちローカルでマージして手元でテストなんてしてたら、みんなそれぞれ状態がバラバラで何テストしてるのか分からなくならないか？
特定の一人だけがmainにマージできるような超集権的な体制でないと成立しないと思う
1032:デフォルトの名無しさん
22/04/23 02:52:15.37 HOOXt/T3.net
>>995
うちのやり方では「master へ push する権限を持ってる人がローカルで master に merge する作業をする。」か「ブラウザ上でマージしてしまうか」はその権限持ちがプルリクエストを見て判断する
1033:デフォルトの名無しさん
22/04/23 03:00:56.62 HOOXt/T3.net
統合的なテストはmasterにマージされた後に動かして、それでダメならrevert
統合的なテストが済んだところはtagが打たれてリリースはそのtagがあるとこまでしか行われない
1034:デフォルトの名無しさん
22/04/23 03:22:27.74 HOOXt/T3.net
久しぶりだけど次スレ立ててみる
1035:デフォルトの名無しさん
22/04/23 03:27:15.61 HOOXt/T3.net
次スレ
Git 18
URLﾘﾝｸ(mevius.2ch.sc)
1036:デフォルトの名無しさん
22/04/23 03:39:41.93 /lJ77CU4.net
>>1000
乙
1037:デフォルトの名無しさん
22/04/23 09:32:57.73 3glRXhKn.net
>>979
劣等感抱いてるんだね。わかるよ
1038:デフォルトの名無しさん
22/04/23 09:43:28.49 aEJ0G9VA.net
未だsvnから離れられない人かな
1039:デフォルトの名無しさん
22/04/23 11:37:43.64 BMKo0y1z.net
いえ、ディレクトリコピーで済ませています
1040:デフォルトの名無しさん
22/04/23 14:25:06.82 tAGVUJOK.net
Git 18
ｽﾚﾘﾝｸ(tech板)
1041:デフォルトの名無しさん
22/04/23 14:36:55.00 BMKo0y1z.net
質問いいですか？
1042:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 598日 2時間 18分 27秒
1043:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています