■ このスレッドは過去ログ倉庫に格納されています
Git 17
- 1 :デフォルトの名無しさん:2020/09/02(水) 12:18:30 ID:XN0SxNMq.net
- ソースコード管理を行う分散型バージョン管理システム、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
- 958 :デフォルトの名無しさん:2022/04/21(木) 15:42:47.36 ID:Ex423fK8.net
- 先輩「CUIのほうがgitの機能をすべて使えるからいいよ」
おれ「pullするときにディレクトリを指定するのは、どんなコマンドを実行すればいいですか?」
先輩「git pullしかやったことないから分からない」
おれ「・・・」
- 959 :デフォルトの名無しさん:2022/04/21(木) 17:41:01.53 ID:haKrn/PJ.net
- >>958
別に先輩おかしくないけど
- 960 :デフォルトの名無しさん:2022/04/21(木) 18:49:26.99 ID:BFaC4LhO.net
- ディレクトリを指定してpullする機能なんて無いし
pullに引数指定しなければいけないような状況はfetchとmergeを使うから、おれもgit pullの引数有りの挙動は把握してない
- 961 :デフォルトの名無しさん:2022/04/21(木) 18:55:10.99 ID:Ex423fK8.net
- おまえらって本質がわかないのか?
pullかどうかなんてのは本質でない
git hoge
でも論理は同じ
- 962 :デフォルトの名無しさん:2022/04/21(木) 19:16:46.07 ID:KtzHzoax.net
- ちょっと例えがアレだったね
シニカルなことを表現するときはバシッと一発で決めてかないとこういう残念な雰囲気になる
それもまた世のことわり
- 963 :デフォルトの名無しさん:2022/04/21(木) 19:27:25.31 ID:BFaC4LhO.net
- CUIの方がgitの機能がすべて使えるのは正しい
CUIで使う人が全てのコマンドのオプションを知ってる必要なんてない
CUIで使うのを難しく考え過ぎじゃないかな?
どのgitコマンドで何ができるかを把握できてれば十分で、細かい指定は大雑把に覚えてればいいよ
良く使う操作は短いエイリアスやシェル関数にしてしまうし、普段あまりやらない操作はコピペでもいいし、man見て調べればいいし、いまのシェルは履歴も補完も使いやすいからgitの長いオプション名なんて覚える必要も無い
- 964 :デフォルトの名無しさん:2022/04/21(木) 19:27:50.71 ID:BFaC4LhO.net
- 別にCUI/GUIに限らないけど、どのgitコマンドで何ができるか何が起こるかを理解できているのが重要
gitのコマンドは後戻りできるものが多くて、その方法を理解できてると楽に使える
後戻りする系の手段はあれこれ用意されてるけど、CUIの方が充実してるかな
- 965 :デフォルトの名無しさん:2022/04/21(木) 21:14:31.11 ID:Ex423fK8.net
- git pullしか実行したことないなら、GUI使ってもボタン一発だろw
- 966 :デフォルトの名無しさん:2022/04/21(木) 21:34:43.05 ID:F4v8aJSe.net
- git pull はコンフリクトで失敗することがあるからボタン一発で済むとは限らない
- 967 :デフォルトの名無しさん:2022/04/21(木) 21:37:37.80 ID:ZCLpZV4/.net
- CUIに劣等感感じる必要ないんやで
どっちも便利だから好きな方使え
- 968 :デフォルトの名無しさん:2022/04/21(木) 21:46:02.93 ID:FUPABV2N.net
- GUIとCUIの併用だな
なんでどっちかしか使えないと考えるんだろう
- 969 :デフォルトの名無しさん:2022/04/22(金) 00:44:19.39 ID:a+ReXgZI.net
- ブランチが必要な理由が分からない
リモートからクローンしてきている時点で、origin/masterとは別のリポジトリが個々人に存在するんだし
コミットも個々人のリポジトリに対して行うわけでしょ
一度もブランチ生やしてなんて一度も指示されたことないわ
- 970 :デフォルトの名無しさん:2022/04/22(金) 02:04:37.85 ID:/nIvhavJ.net
- ブランチがないとお互いのコミットを観測することができない
人の変更を見ようと互いにpush+pullすると常にmergeが伴うので、いわゆる観測者効果みたいな面倒くささが生まれる
プロジェクトの規模やリリースの複雑性が増すにつれてより困る
よくある例では、次バージョンの開発を初めている人がいるときhotfixを出せない
featureブランチのpushはオアズケを命じられて、その間ソースレビューも滞る
ブランチをforkに置き換えても同じ
- 971 :デフォルトの名無しさん:2022/04/22(金) 09:52:33.39 ID:ZbT6iK7O.net
- 各個人のGitHubアカウントにforkしてリポジトリ間のpull requestでマージしていく流派も存在する
本来のGitやGitHubの想定する使い方としては正しくてOSS文化的にも好ましいやり方ではあるんだが、企業での開発ではほとんど採用されない
単一のGitHubリポジトリで中央集権的に管理した方が楽だからね
- 972 :デフォルトの名無しさん:2022/04/22(金) 12:20:17.30 ID:dVlUoLXX.net
- AからA'とBの2つを作りたくなったときって、
ブランチなしでどうやるんだろうな
- 973 :デフォルトの名無しさん:2022/04/22(金) 12:30:42.99 ID:wri6W8iQ.net
- >>969
ブランチは「実装していること」を表すので、複数の機能を並行して開発するときは必須。
よくあるのは
・通常の開発版とリリース版/デバッグ版を分けて、デバッグリリースを早くする&開発版への取り込みを管理しやすくする
・開発する機能ごとにブランチを用意して、互いの干渉を減らす&マージをやりやすくする
あたり。
- 974 :デフォルトの名無しさん:2022/04/22(金) 14:20:44.25 ID:QpAASndC.net
- 自分のアカウントにforkするスタイルの開発しか経験ない人が
単一GitHubリポジトリ運用な会社に入ってforkして怒られるのはGitHubあるある
- 975 :デフォルトの名無しさん:2022/04/22(金) 21:56:45.85 ID:RSUrvfLc.net
- fork って何? git 用語に翻訳して。
- 976 :デフォルトの名無しさん:2022/04/22(金) 22:05:44.96 ID:0DWZpb5V.net
- clone
- 977 :デフォルトの名無しさん:2022/04/22(金) 22:16:51.65 ID:RSUrvfLc.net
- >>976
clone したら怒られるの? マジか? それ本当に git 使ってるの?
- 978 :デフォルトの名無しさん:2022/04/22(金) 22:48:01 ID:4bmaw9DX.net
- forkがcloneだからといってcloneがすべてforkなわけがない
- 979 :デフォルトの名無しさん:2022/04/22(金) 23:04:27 ID:a+ReXgZI.net
- おまえらって、gitについて講釈ばかりたれてるけど
全く本業ができないわけじゃないよなw
うちの会社にもいるわ
講釈たれてる暇があるならさっさとコーディング終わらせろよwwwww
- 980 :デフォルトの名無しさん:2022/04/22(金) 23:12:27.31 ID:UMBGLRP1.net
- 根拠のないレッテル貼りによる謎のマウンティング
- 981 :デフォルトの名無しさん:2022/04/22(金) 23:30:46.77 ID: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したら怒れるということだろう
- 982 :デフォルトの名無しさん:2022/04/23(土) 00:07:18.92 ID:iISBdnEI.net
- >>981
何を言ってるかわからない。
pull というのは「 fetch して merge 」という操作をまとめてやるだけのコマンドなので当然 merge の意味を内包してる。
fetch せずに merge って言いたいの? それってどうやって対象を持ってくるの?
自分のリポジトリから持ってくるだけなら他人から request される必要ないし?
- 983 :デフォルトの名無しさん:2022/04/23(土) 00:13:01.25 ID:iISBdnEI.net
- ちなみに push というのは remore への merge を指示するコマンドな。
- 984 :デフォルトの名無しさん:2022/04/23(土) 00:51:13.69 ID:1bxGV6XJ.net
- >>982
いや同一のGitHubリポジトリ上でpull requestをマージするときにfetchは要らないでしょ
>>981の言うとおり、本来リポジトリを跨がるからfetch+mergeでpullなんだよ
- 985 :デフォルトの名無しさん:2022/04/23(土) 00:59:48.76 ID: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とはあまり呼ばないな
- 986 :デフォルトの名無しさん:2022/04/23(土) 01:35:18.29 ID: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 が必要になるので普通やらないし、できない。
- 987 :デフォルトの名無しさん:2022/04/23(土) 01:58:40.02 ID: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してもいい
- 988 :デフォルトの名無しさん:2022/04/23(土) 02:02:56.04 ID:HOOXt/T3.net
- >>986
pushでFFじゃないmergeってできるの?できても今は普通しないでしょ
FFでmergeできない場合には、ローカルでmergeしてFFにしてpushするか、push -sで上書きが普通だし
- 989 :デフォルトの名無しさん:2022/04/23(土) 02:12:55.85 ID:iISBdnEI.net
- >>988
できるけど、おすすめではない。
ただ push は merge と同じ機構という点が理解できてれば良い。
- 990 :デフォルトの名無しさん:2022/04/23(土) 02:14:20.66 ID:XK6u/IcU.net
- 普通はローカルでマージしたものをプッシュする
- 991 :デフォルトの名無しさん:2022/04/23(土) 02:23:24.07 ID:iISBdnEI.net
- >>987
いきなり共用リポジトリ上でマージしたりしない。そういう運用ルールの組織があるとしたらかなり頭悪い。git の使い方が半分しか理解できてない。
共用リポジトリは問題があってもロールバックできない(超めんどう)なので、共用リポジトリの master には手元でのテスト等が終わって問題ないもののみを入れるのが普通。
- 992 :デフォルトの名無しさん:2022/04/23(土) 02:38:54.73 ID:HOOXt/T3.net
- ローカルでマージしてmasterへpushするって言ってる人たちはmasterへのpush権限をみんなが持ってるの?
- 993 :デフォルトの名無しさん:2022/04/23(土) 02:43:01.86 ID:iISBdnEI.net
- master へ push する権限を持ってる人がローカルで master に merge する作業をする。当然の話。
- 994 :デフォルトの名無しさん:2022/04/23(土) 02:47:09 ID:1bxGV6XJ.net
- 分野にもよるのかもしれんが、少なくともWeb系はGitHub上でマージするのが普通
直接mainにマージしたくないなら
- 995 :デフォルトの名無しさん:2022/04/23(土) 02:49:26.76 ID:HOOXt/T3.net
- >>991
もちろんプルリクエスト出す段階でローカルにテストは済んでる前提だし、masterへマージされた後にそれがダメならrevertするよ?
プルリクエストを承認できてmasterへマージできる人は特定の人だけだし、それをマージする前にテストが済んでるかどうかとかをリクエスト者に確認する
そのためにプルリクエスト上でいろいろやりとりできるようになってるわけだし
というか>>986とかはgithubを単にgitのリポジトリとして利用するだけのやりかただよね?別にgithub使う必要無くない?なんでgithub使ってるの?
- 996 :988:2022/04/23(土) 02:51:33.02 ID:1bxGV6XJ.net
- 失礼
直接mainにマージしたくないならdevelopブランチ等を間に置く
各自がいちいちローカルでマージして手元でテストなんてしてたら、みんなそれぞれ状態がバラバラで何テストしてるのか分からなくならないか?
特定の一人だけがmainにマージできるような超集権的な体制でないと成立しないと思う
- 997 :デフォルトの名無しさん:2022/04/23(土) 02:52:15.37 ID:HOOXt/T3.net
- >>995
うちのやり方では「master へ push する権限を持ってる人がローカルで master に merge する作業をする。」か「ブラウザ上でマージしてしまうか」はその権限持ちがプルリクエストを見て判断する
- 998 :デフォルトの名無しさん:2022/04/23(土) 03:00:56.62 ID:HOOXt/T3.net
- 統合的なテストはmasterにマージされた後に動かして、それでダメならrevert
統合的なテストが済んだところはtagが打たれてリリースはそのtagがあるとこまでしか行われない
- 999 :デフォルトの名無しさん:2022/04/23(土) 03:22:27.74 ID:HOOXt/T3.net
- 久しぶりだけど次スレ立ててみる
- 1000 :デフォルトの名無しさん:2022/04/23(土) 03:27:15.61 ID:HOOXt/T3.net
- 次スレ
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945
- 1001 :デフォルトの名無しさん:2022/04/23(土) 03:39:41.93 ID:/lJ77CU4.net
- >>1000
乙
- 1002 :デフォルトの名無しさん:2022/04/23(土) 09:32:57.73 ID:3glRXhKn.net
- >>979
劣等感抱いてるんだね。わかるよ
- 1003 :デフォルトの名無しさん:2022/04/23(土) 09:43:28.49 ID:aEJ0G9VA.net
- 未だsvnから離れられない人かな
- 1004 :デフォルトの名無しさん:2022/04/23(土) 11:37:43.64 ID:BMKo0y1z.net
- いえ、ディレクトリコピーで済ませています
- 1005 :デフォルトの名無しさん:2022/04/23(土) 14:25:06.82 ID:tAGVUJOK.net
- Git 18
https://mevius.5ch.net/test/read.cgi/tech/1631002816/
- 1006 :デフォルトの名無しさん:2022/04/23(土) 14:36:55.00 ID:BMKo0y1z.net
- 質問いいですか?
- 1007 :2ch.net投稿限界:Over 1000 Thread
- 2ch.netからのレス数が1000に到達しました。
総レス数 1007
246 KB
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★