21/10/17 13:11:42.80 Zl984gEM.net
svnはマージがアホ
813:デフォルトの名無しさん
21/10/17 13:55:53.46 2tMovdDG.net
個人でやってるならリモートリポジトリを使う必要ないよ
別の場所にバックアップしたいときだけ稀にプッシュしておいてもいいかな程度
Gitはブランチ開発が圧倒的に便利
次バージョンの開発をしながら、ヤバいバグを見つけたらスイッチして現行リリースにパッチを当てるなんて作業がやりやすい
コミット等の操作を間違えたときの復元方法も充実してるからガンガンコミットするスタイルが身についてロスがない
あまりにも小規模な開発しかしてないならGitに移行したところで便利さに気付かないかもね
814:デフォルトの名無しさん
21/10/17 14:17:13.86 4gFBmPmU.net
svnはもう使わなくなってから何年も立つけど、ローカルブランチ作るのに全コピーが発生する問題は改善されたん？
gitは瞬間的にローカルブランチ作れることが、当時、最大のメリットだと個人的には感じてたけど
815:デフォルトの名無しさん
21/10/17 14:18:42.77 4gFBmPmU.net
あ、ローカルって書いちゃったけどリモートも同様
816:デフォルトの名無しさん
21/10/17 15:15:03.36 2tMovdDG.net
svnも物理コピーしてるわけじゃなくポインタをコピーしてるだけだからそこは別にデメリットではないと思う
817:デフォルトの名無しさん
21/10/17 15:26:46.35 4gFBmPmU.net
じゃあそこは改善されたんだね
818:デフォルトの名無しさん
21/10/17 15:29:30.74 QJpjjZiJ.net
ローカルで何でもできるのとrebaseできるのが大きいな。
819:デフォルトの名無しさん
21/10/17 16:36:16.01 2tMovdDG.net
svnのコピーは最初からそういう設計思想だよ
強いて言うならCVSに対しての改善点
URLﾘﾝｸ(subversion.apache.org)
820:デフォルトの名無しさん
21/10/20 03:48:00.82 fM0zKRFM.net
--filter=blob:noneでcloneしたレポで久しぶりにpullすると
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 334 bytes | 334.00 KiB/s, done.
remote: Enumerating objects: 1, done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (1/1), 413 bytes | 413.00 KiB/s, done.
が延々続く
.git/configのpromiser=trueとpartialclonefilter=blob:noneを消すと秒で終わる
これは仕様？
821:デフォルトの名無しさん
21/10/31 11:33:48.76 08bIR5oT.net
Git v2.34.0-rc0
822:デフォルトの名無しさん
21/11/04 09:59:24.05 RuoxMXd8.net
Git v2.34.0-rc1
823:デフォルトの名無しさん
21/11/07 11:40:46.01 khCyKtci.net
MSに握られたくないなら、cvs か svn
824:デフォルトの名無しさん
21/11/07 11:42:30.89 QVBUkb8D.net
>>798
git使うとmsに握られるというのが意味不明なんだが
825:デフォルトの名無しさん
21/11/07 12:37:05.54 UQcl36Q5.net
gitとgithubの区別がつかない人がMSアレルギーをこじらせている姿はもう見飽きた
情報のアップデートをできずに屈折した持論を垂れ流すから老害の部類かな
826:デフォルトの名無しさん
21/11/08 21:23:48.94 Tlvj8hhG.net
それはもはやチテキショウ害なのでは
827:デフォルトの名無しさん
21/11/11 10:05:05.74 SpIFedoW.net
わろす
828:デフォルトの名無しさん
21/11/16 08:19:16.49 nj7ybZ5p.net
Git v2.34.0
829:デフォルトの名無しさん
21/11/25 08:42:00.93 +EmkPByH.net
Git v2.34.1
830:デフォルトの名無しさん
21/11/25 12:21:37.68 F3lCPX8r.net
すぐキレるLinusも若手から老害と言われてるんだろうな。
831:デフォルトの名無しさん
2021/11/27(土
832:) 18:33:16.18 ID:EO01MlFX.net
833:デフォルトの名無しさん
21/11/30 21:35:19.46 a/ltCSu7.net
10年程昔からの自作のフリーウェアを git で公開しようとしているんだけど
あまり昔の version はもう環境が変わっていて動かない
動くものだけを公開した方が良いのかな
それとも最新のものだけにした方がいいですか
834:デフォルトの名無しさん
21/11/30 21:59:48.42 29wtvv9O.net
好きにしろ
835:デフォルトの名無しさん
21/11/30 22:33:45.81 a/ltCSu7.net
わかりました
どうも
836:デフォルトの名無しさん
21/12/09 01:56:53.52 8VFa9Xh4.net
gitの変更履歴より細かい単位で変更を戻したいとき、うまい方法はありますかね。
例えば一つのファイルの中で3つの関数を変更してコミットした後、1つの関数だけ
元に戻したくなった場合などに。
837:デフォルトの名無しさん
21/12/09 06:55:22.90 CTJ8MnG2.net
>>810
その関数を変更した後にコミット
838:デフォルトの名無しさん
21/12/09 07:23:14.89 nPf7xXRe.net
>>810
git rebase
1
2
3 ← ここで止める
4
5
1
2
3.1
3.2
3.3 ← こんな感じにコミット
git rebase --continue でリベース完了
あと慣れたら 2つの関数だけコミットして、
1つは戻ればいい
839:デフォルトの名無しさん
21/12/09 08:05:36.93 Rbrjprb1.net
>>810
pushする前ならcommit amend して修正してからrebase。
push後なら新たにcommit。
840:デフォルトの名無しさん
21/12/09 08:13:38.11 nPf7xXRe.net
あめんどは、あ、めんどう～だ、なぁ～
841:デフォルトの名無しさん
21/12/09 08:15:15.22 ETLEJYpI.net
求めてるのはadd -pじゃないのかな
842:デフォルトの名無しさん
21/12/09 08:22:24.08 zGaqleE8.net
>>813
わかりづらいな……試してないけど
…56 3関数commit abc……master
ここをchechout -b mod
…56 3関数commit abc……master
[mod:2関数commit]
元に戻してcommit amend
…56 3関数commit abc……
mod abc……[master]
masterをchechoutしてmodにrebase
ただし、コミットを他人と共有済みなら混乱の元なので禁止。
843:デフォルトの名無しさん
21/12/09 08:58:11.54 Dni9SPWj.net
>>810
履歴改変をするわけじゃないんだよね？それならば、
git revert -n でindexに三つの関数の修正を打ち消す修正を持ってきて、git reset -p でindexの余分な修正を取り除いて、git commit
844:804
21/12/09 09:39:57.87 rmYbkO4s.net
どうも>>810です。プッシュはしてませんのでアメンドないしリセットとしてやり直すことは
可能です（よね?）
なんというか、作業方法なども含めてキレイ&楽にやる方法はどんな感じかなと。
例えばそもそも論だと、最初からこういう場合に備えてコミットを関数1個毎とか細かくしておく?
アメンドないしリセットしてやり直す場合も、どうやって変更を用意しようかなと... もう一回
同じ変更を入力したくはないし危険... とかなんとか。
845:デフォルトの名無しさん
21/12/09 10:00:49.33 z12/cdNE.net
>>818
だから何をしたいのかはっきりしろ
pushしてないのは分かった
pushしてないローカルな履歴を改変したいのか？
pushしてないローカルな履歴に関数の修整を無効化するコミットを追加したいのか？
846:デフォルトの名無しさん
21/12/09 10:05:24.50 Dni9SPWj.net
>>818
変更の用意はrevert -nとreset -pでいいだろ
この2つを使えば自分でコードを入力する必要は無い
847:デフォルトの名無しさん
21/12/09 11:35:29.86 nPf7xXRe.net
>>818
だから>>812だって
rebaseで過去の歴史の途中に戻って
そこでコミットを分けるなりして
再び歴史を
848:再生する
849:デフォルトの名無しさん
21/12/09 11:36:08.99 nPf7xXRe.net
正確には git rebase -i な
850:デフォルトの名無しさん
21/12/09 13:53:35.69 CTJ8MnG2.net
もう面倒くさいから一か所もどしましたってコミットしたらいいやん
851:デフォルトの名無しさん
21/12/09 14:15:33.20 SnlJ6hdA.net
rebaseは悪い文化
852:デフォルトの名無しさん
21/12/09 14:50:31.70 nPf7xXRe.net
>>824
必要なのは結果だけ
お前が試行錯誤した後なんかどうでもいい
853:デフォルトの名無しさん
21/12/09 14:51:34.29 Dni9SPWj.net
>>823
そのコミットを簡単に作る方法が知りたいのだと思う
854:デフォルトの名無しさん
21/12/09 15:05:38.49 FiTzWudg.net
>>826
Winmergeをdiffツールに設定して
git windiff HEAD^^^
で戻してcommitだな俺なら
855:デフォルトの名無しさん
21/12/09 15:28:07.01 1oFDwxyl.net
>>818
そもそも論の部分に回答すると、意思決定の基本は発生率とコストを掛け合わせた期待値次第
いちいち細分化しすぎてもYAGNIの法則で言われるような無駄が多くなるだけ
でも後から部分的に採用する可能性もそれなりにあるのであれば分けてコミットしておくことでコストを抑えられる可能性が増す
856:デフォルトの名無しさん
21/12/09 18:55:14.96 lg/9Dj4Y.net
>>818
そもそも論で言うなら、追加・修正する機能ごとにブランチを切って、完成したブランチを別々にコミットすればいい。gitはブランチが軽量という強みもあるし。
機能をマージするときにコンフリクトを修正する面倒くささはあるけど、見通しは良くなる。
857:デフォルトの名無しさん
21/12/09 20:50:07.62 ejbJEiiI.net
コミットの粒度の話じゃないの？
858:デフォルトの名無しさん
21/12/09 22:51:55.36 EKItVGZE.net
追えてないけど、どれか。
・そもそもコミットきれいにしても結局使わないから作り直さない
・頻繁にコンパイル？して頻繁にコミットしておく
・もう最初から作り直せよ派: git reset $(git merge-base origin/master) → 気に入るコミット作っていく。
・ツールに関数単位で切り出させて、差分をうまいことやる。VisualStudioならこのメソッドをクラス化、みたいなやつがあったような。それ以外は知らん。
859:デフォルトの名無しさん
21/12/09 23:49:30.01 Fvd6f3uE.net
コミットをセーブ機能だと思うからだめなんだよ
袋だと思え袋
コードを書くたびに適切な袋に入れろ
860:デフォルトの名無しさん
21/12/10 11:49:29.41 5non8kx0.net
>>831
・追加機能ごとにブランチ切る
も追加で。
861:デフォルトの名無しさん
21/12/10 15:18:37.19 dSCEiiiB.net
最近では、機能ブランチは問題を先送りにしているだけだという批判もある
機能ブランチはすぐにリリースして消せ、作りかけならフィーチャートグルで蓋をしろというスタイルもあるぞ
それは一理あって、実際複数のチームでそれぞれフィーチャーブランチを担当してリリース時に一気にマージするスタイルの大規模サービス開発やってたときには
マージの失敗でトラブルが起こることは日常茶飯事だったね
862:デフォルトの名無しさん
21/12/11 00:15:15.28 L5jxStGt.net
それは機能ブランチが悪って話じゃなくて、機能ブランチをやたらと長期間分離しておくのが悪って話じゃね
何事もトレードオフだから機能がでかいならイテレーションを小さく取るし、リリースギリギリまでマージしなければ泣きを見るので頃合いを見て合流してテスト始める
互いに影響し合う部分についてはコミュニケーション取りつつ適宜ソースをやり取りしろというのがGitの指針だったと思うし
863:デフォルトの名無しさん
22/01/12 10:21:41.75 mFIs9bfU.net
Git v2.35.0-rc0
864:デフォルトの名無しさん
22/01/12 19:57:57.27 IbSx3jpA.net
こういうコミットをしてたと�
865:ｵて $ git log --oneline commit_id_5 やっぱり××を復活させる(2021/05/01) commit_id_4 □□を修正(2021/04/01) commit_id_3 ××を削除(2021/03/01) commit_id_2 △△を修正(2021/02/01) commit_id_1 〇〇を修正(2021/01/01) 「commit_id_3 と commit_id_5 を消して、コミットログをきれいにした状態でリモートブランチにpushする」というようなことは可能ですか？ こういう場合にgit rebaseが使われるんですかね？
866:デフォルトの名無しさん
22/01/12 21:08:30.47 et9b++qr.net
>>837
はい。そうです。
867:デフォルトの名無しさん
22/01/12 21:16:41.65 IbSx3jpA.net
>>838
ありがとうございます
てか真上に同じような質問ありましたね…
868:デフォルトの名無しさん
22/01/15 22:30:31.28 mgu84OGw.net
Git v2.35.0-rc1
869:デフォルトの名無しさん
22/01/16 00:47:01.30 hYWYL0RZ.net
>>837
俺は作りながら片付ける
作ってる途中で、この修正はこのコミットに含めよう
などと考えならが小さくコミットし
適度なタイミングでrebaseする
870:デフォルトの名無しさん
22/01/17 06:52:31.08 pA35C6jo.net
>>837
別ブランチでcommitして、masterにまとめてmergeしてpushする、って方法もあるよ
これだとrebaseは不要
871:デフォルトの名無しさん
22/01/23 09:44:11.74 6R0k9GT3.net
gitもcvs,svnと同じ運命をたどるだろう
私の企業は次世代バージョン管理システムfossilに切り替えました
872:デフォルトの名無しさん
22/01/24 13:46:51.63 2I6HNHFB.net
化石？
873:デフォルトの名無しさん
22/01/24 15:13:36.64 TB1mn4oZ.net
次世代って書いてるけどGitやMercurialと同期だね
統合が特徴みたいだけど、少なくとも統合指向＝先進的というのは言えない
昔のMSや古いエンタープライズシステムが通ってきた道
874:デフォルトの名無しさん
22/01/24 20:03:13.29 T/bW8QxB.net
sqlite以外に使ってるプロジェクトあるの？
875:デフォルトの名無しさん
22/01/25 09:41:06.99 lI80daK7.net
Git v2.35.0
876:デフォルトの名無しさん
22/01/27 23:05:55.20 5JD4ntnW.net
「Git 2.35」が公開
URLﾘﾝｸ(mag.osdn.jp)
877:デフォルトの名無しさん
22/01/29 22:24:24.64 DKHpcK/K.net
Git v2.35.1
878:デフォルトの名無しさん
22/02/04 16:36:05.63 57NC5giI.net
Git 日本語翻訳チーム
URLﾘﾝｸ(github.com)
879:デフォルトの名無しさん
22/02/04 16:53:15.37 ldQUlQ88.net
>>850
gitを業務で使われている方は翻訳に参加してください
880:デフォルトの名無しさん
22/02/08 12:18:02.21 nuxork7Z.net
ウクライナのGitLabがやばいな
881:デフォルトの名無しさん
22/03/16 08:10:03.07 3iPp8Jr+.net
ゲイツもgit 作者も ワクチン派=ナチス
882:デフォルトの名無しさん
22/03/20 18:56:58.51 oCBKTdlK.net
すみません、git pushをこっそりキャンセルしたく
$ git reset --hard HEAD^; git push -f origin HEAD をしたのですが
To prevent you from losing history, non-fast-forward updates were rejected.
と言われてpushが失敗します。
もしかしてリポジトリの設定でこういう強制pushが禁止されていたりしますかね?
883:デフォルトの名無しさん
22/03/20 20:08:48.92 pStA9jik.net
サーバー側の receive.denyNonFastForwards の設定で禁止されてる
884:デフォルトの名無しさん
22/03/20 20:17:36.65 XwFj+GPH.net
>>854
git push --delete ～ でリモートブランチ消してpushしなおせばまだワンチャンある
885:デフォルトの名無しさん
22/03/22 00:18:15.54 G4hvFEyv.net
強制pushまだ禁じてるところあるんやね
886:デフォルトの名無しさん
22/03/22 08:24:32.98 OaCGWLhd.net
馬鹿がいるんだから当たり前やろ
887:デフォルトの名無しさん
22/03/22 15:19:11.35 Oh3PkPXA.net
ブランチにアクセス権を設定できるサーバ
888:なら、メインのブランチにはプルリクエスト処理する人だけがアクセス可能にして、強制push禁止と強制ブランチ削除禁止の設定はいらん気もするね でも本家gitにはブランチ単位のアクセス権は無いよね確か
889:デフォルトの名無しさん
22/03/22 18:39:39.96 GWInnMJp.net
>>854
プロジェクトメンバーに周知すればいいんでないの？
890:デフォルトの名無しさん
22/03/25 05:31:45.01 VoO+G8uZ.net
こっそりと周知、ってのは難易度高いな
891:デフォルトの名無しさん
22/03/25 07:14:27.74 iMzzdMMk.net
こっそりする必要はないでしょ
892:デフォルトの名無しさん
22/03/30 21:00:41.82 pZIqlelO.net
pullする前にどれが変更されているか知ることは出来ないの
893:デフォルトの名無しさん
22/03/30 21:03:54.04 sFfsK7BI.net
git ls-remote
894:デフォルトの名無しさん
22/03/30 21:50:58.83 sIJSREW7.net
fetch
895:デフォルトの名無しさん
22/04/01 00:22:46.86 46G1puQR.net
totoiesegit使ってんですけ、コミットしただけでチェックアイコンに変わるんで
pushし忘れることが多いんですけど、区別できないんですか？
896:デフォルトの名無しさん
22/04/01 04:32:18.73 w7Dm7PZW.net
>>866
うん
897:デフォルトの名無しさん
22/04/01 05:21:04.10 vPqr4MnO.net
尊いーぜgit
ごめん言ってみただけ
898:デフォルトの名無しさん
22/04/01 08:03:05.39 4o646iU1.net
Gitsだぜ
すいもあまいもー
899:デフォルトの名無しさん
22/04/01 10:30:17.09 L8R+vRlu.net
トータス使うよりSoucetree使う
900:デフォルトの名無しさん
22/04/02 16:17:20.40 y/uyzFp6.net
リポジトリにあさんが変更をプッシュしたことをいさんはどうやって知れるのですか？
あさんからいさんへメールなりで連絡？
いさんがフェッチなり、プルすれば分かるんですが・・・
901:デフォルトの名無しさん
22/04/02 16:43:53.49 66/F4m6m.net
>>871
本来gitで想定されている正しい使い方としてはメールで連絡
今時の普通のチームならGitHubでpull requestを出す
902:デフォルトの名無しさん
22/04/02 16:46:06.34 eQjRdGtS.net
共有するリポジトリの置き場所に素のgitを使ってない限り、何らかの通知する仕組みはあるだろ？
素のgitでもスクリプト仕込めばできるけど面倒だな「git hooks 通知」でぐぐれ
903:デフォルトの名無しさん
22/04/02 17:04:36.48 y/uyzFp6.net
totoiesSVNの時はフォルダのアイコンが！に変わるから
logを表示させればだれが、どこを変更したか分かるけど
gitの場合、アイコン変わっていないから何時フェッチ、プルすればいいかわからない
こういうもの？
904:デフォルトの名無しさん
22/04/02 17:20:12.10 66/F4m6m.net
>>874
Gitでは、同じブランチの上で複数人が作業することは普通しない
905:デフォルトの名無しさん
22/04/02 17:22:26.59 a7IS8KL2.net
同じことだよ
TortoiseSVNを使っていても他人の変更が勝手に降ってくることはないぞ
これまでほぼ無意識にときどき更新コマンドを実行してたんだろ
Gitでもそれと同じように無意識にときどきフェッチすればいい
リポジトリが新しかったりローカルが汚れているときにコンソールが赤とか黄色とかになる環境を作っておけばさらに分かりやすくなる
906:デフォルトの名無しさん
22/04/02 17:33:56.91 y/uyzFp6.net
>>876
その「更新コマンド」を実行すべきタイミングが分からないんですよ
とりあえずプルすれば、変更されていれば更新されるけど
変更されていなければ更新されない
いちいちメールかなにかで連絡もらえれば、プルするから実害はないんだけど
907:デフォルトの名無しさん
22/04/02 17:37:22.85 OkBLvXjb.net
git push したらｖｐｓのソースが更新されるようにしたのに、ヒミツ鍵でログインするタイプのvpsに変えたらgit pushでエラーが出るようになったわ
908:デフォルトの名無しさん
22/04/02 17:50:45.78 ofyuLHc/.net
>>877
気になった時fetchすりゃいいんだよ。
909:デフォルトの名無しさん
22/04/02 18:18:39.57 y/uyzFp6.net
>>879
１分おきにfetchするアルバ
910:イト雇ったほうが工数的にはいいですね
911:デフォルトの名無しさん
22/04/02 23:09:26.57 ofyuLHc/.net
変な質問だと思ったがネタだったか。四ね。
912:デフォルトの名無しさん
22/04/03 00:33:31.34 TSy6KLqO.net
git reflogを時間指定して実行すると上手くログが取得できないんだが、自分だけ？
git logは普通に動く
913:デフォルトの名無しさん
22/04/03 09:55:27.42 sNbs7j4z.net
>>881
釣られましたねｗ
914:デフォルトの名無しさん
22/04/03 11:58:15.04 YOg/TQMm.net
気になったらエッチとな？
915:デフォルトの名無しさん
22/04/04 18:26:27.90 uBqMrhkR.net
>>882
reflogで表示される時間はその操作が行われた時間ではなくてその操作の結果のHEADのコミットの時間で、reflogの--afterとかによる表示範囲判定は操作が行われた時間に基づいて判定されるぽいから、変な風に感じる？
HEADのコミットの時間でなくて操作した時間をreflogで表示する方法はあるのかな
916:デフォルトの名無しさん
22/04/05 06:52:00.45 HDipRGT6.net
>>877
俺は開発ブランチにcommitした後にmasterをfetchしてる
で、マージすべき内容ならmergeする
917:デフォルトの名無しさん
22/04/05 06:57:58.21 qPBzPdZO.net
>>886
こういうのが居ると無駄なマージ履歴が残る。
コミットまたはプッシュする前にプルしてマージ完了した状態でプルするルールにしてる。
918:デフォルトの名無しさん
22/04/05 06:58:45.84 qPBzPdZO.net
×プルするルール
◯プッシュするルール
919:デフォルトの名無しさん
22/04/05 07:02:20.74 HDipRGT6.net
>>887
これはfetchかpullのタイミングの話であって、それとこれとは別の話だよ
それはpull request用のブランチにsquashなりすれば解決することだろ
920:デフォルトの名無しさん
22/04/05 07:09:17.66 LSxkXP/U.net
squashするとまた意味が変わってくる
無駄なマージコミットを気にするならpull --rebaseするといい
921:デフォルトの名無しさん
22/04/05 08:27:03.94 Tv9hyPpM.net
内容ごとにブランチを切って、実装完了後にマージしたほうがいい。
こまめにマージする必要あるけど。
922:デフォルトの名無しさん
22/04/05 08:37:26.26 VZWFnuGC.net
rebaseすると途中のコミットが見たことないスナップショットに化けるから諦めてmergeする派
923:デフォルトの名無しさん
22/04/05 10:22:46.93 Ti8ZULSh.net
どうせマージコミットしか見ないからどうでもいいわ
924:デフォルトの名無しさん
22/04/05 12:59:38.64 HRL2Dhl7.net
Git v2.36.0-rc0
925:デフォルトの名無しさん
22/04/10 12:29:54.84 /cWGM6C3.net
Git v2.36.0-rc1
926:デフォルトの名無しさん
22/04/10 12:43:00.27 gTtQQEaq.net
今からGitを始めます初心者の質問です。
Gitに設定するユーザー名、メールアドレスと
GitHubのアカウント作成で指定するユーザー名、メールアドレスは
同じものでないといけないのでしょうか？
927:デフォルトの名無しさん
22/04/10 23:00:07.32 TJ08CsNt.net
ネットでgitをググると
コミットしたらﾌﾟｯｼｭっする癖をつけようなんて見かけるけど
それなら意味なくね
928:デフォルトの名無しさん
22/04/10 23:03:53.52 OSeViOAV.net
>>897
なんの意味？
929:デフォルトの名無しさん
22/04/10 23:58:14.27 ZMrXNR+Y.net
分散型リポジトリの意味かな？
つーかcommit→pushの流れが癖になるとまずいぞ
develop or masterで作業してるかfeatureブランチをpushすることになる
930:デフォルトの名無しさん
22/04/11 00:51:42.12 1i0W5uZP.net
>>896
同じにしないといけない
違ってるとGitHub上でコミットとユーザーが紐付かない
なおGitHubのメールアドレスは複数設定できる
931:デフォルトの名無しさん
22/04/11 01:06:26.04 Ip9E4gkF.net
いつプルすべきなのかさっぱり分からないんだけど
いちいちフェッチして更新されてたらプルなの？
svnの時はフォルダのアイコンが変わるから、すぐ分かったんだけど
ｇｉｔはめんどくさくてしかたねー
932:デフォルトの名無しさん
22/04/11 01:21:42.99 IXb9iAbb.net
>>901
フォルダーのアイコンが変わるのはsvnの機能ではないだろw
933:デフォルトの名無しさん
22/04/11 01:26:34.08 FKgiTkDa.net
ちんちんシュッ！シュッ！シュッ！
934:デフォルトの名無しさん
22/04/11 03:26:40.92 UsZcfkXO.net
>>901
そもそもsvnの挙動を勘違いしてん�
935:ｶゃん
936:890
22/04/11 07:24:40.88 pyEhSslH.net
>>900
レスありがとうございます。
そうしますと、
複数のメンバーでGitHubの一つのアカウント(リポジトリ)を共有する時の
各メンバーを識別するIDは、どこで指定するのでしょうか？
937:デフォルトの名無しさん
22/04/11 07:35:11.19 IXb9iAbb.net
どんなメールアドレスでもpushできるよ
938:デフォルトの名無しさん
22/04/11 08:54:42.93 Ip9E4gkF.net
>>902
>>904
本筋には触れずに、否定をするﾜﾗ
939:デフォルトの名無しさん
22/04/11 09:14:16 1i0W5uZP.net
>>905
関係ない。各自が自分のGitHub userに設定済みのメールアドレスでコミットすればいい。
GitHub上で制御できるのは「誰がリポジトリにpushできるか」までで、>>906も言ってるがどんなメールアドレスのコミットが含まれていてもpushできる。
たまたまコミットのメールアドレスがGitHub userと同じならGitHub上でそのユーザーがコミットしたように見えるというただそれだけのこと。
940:デフォルトの名無しさん
22/04/11 14:06:10.85 MP0q4WMO.net
>>905
githubでプライベートリポジトリを複数ユーザで共有する場合は、共有するユーザみんな別々のアカウント作って、誰かが作ったレポジトリに他のユーザを招待して、pushするときにはそれぞれ各ユーザのアカウントで認証された状態ですることになるよね
だから上でもだれか言ってるように、コミットのメールアドレスは認証で使われるわけじゃないから、どんなメールアドレスでもpushできる
しかし、コミットのメールアドレスは重要でないというわけでもなくて、コミット一覧とか表示させたときにコミットのメールアドレスに基づいてユーザ名とか写真を表示したりするので、githubのアカウントに登録してあるメールアドレスをgitの方にも登録しておくほうが良い
941:デフォルトの名無しさん
22/04/11 20:59:30.97 voKtAiO9.net
>>907
少し上のレスを見ればわかるけど、その質問は「また釣りか」と思われてまともなレスは付かない。
942:デフォルトの名無しさん
22/04/13 01:15:32.19 TZC3qPMK.net
とある本の不要になったブランチを削除する手順で
①リモートリポジトリの消したいブランチを削除
②Sourcetreeのフェッチのリモートで消えた追跡ブランチを消去(Prune)
③Sourcetreeの消したいローカルブランチを右クリックして削除
とありますが、①がリモートリポジトリのブランチを削除、
③がローカルのそれだとすると
②の手順にはどんな意味があるのでしょうか
943:デフォルトの名無しさん
22/04/13 02:12:16.50 eS/flNB4.net
ブランチには①リモートブランチ ②(リモート)追跡ブランチ ③ローカルブランチの3種類がある
文脈によってこれらはしばしば混同されるので気をつけていないと混乱する
①はサーバー側にあり、②③はクライアント側にある
②は常に①のコピーで、フェッチするたびに①の最新と同期される
だからネットワークに繋がっていなくてもいつでもリモートのログが見れる
「リモートブランチのログを見る」というとき、正確には①ではなく②のログを見る行為を指す
フェッチしていなければ①②③が全て別のコミットを指すこともある
②を消し忘れると、サーバー側のブランチは削除済みなのに、そのクライアントからはまだリモートブランチが消えていないように見える
944:デフォルトの名無しさん
22/04/13 03:53:52.80 TZC3qPMK.net
>>912
詳しいご説明ありがとうございます！
945:デフォルトの名無しさん
22/04/13 21:31:02.16 Pux5Tg8M.net
Git v2.35.2
946:デフォルトの名無しさん
22/04/13 21:31:48.03 Pux5Tg8M.net
Git v2.36.0-rc2
947:デフォルトの名無しさん
22/04/14 12:56:35.38 DFKHhlAT.net
Git v2.35.3
948:デフォルトの名無しさん
22/04/14 14:21:34.39 yss7HMyT.net
Git v2.36.0-rc3
949:デフォルトの名無しさん
22/04/14 14:56:42.75 5RufjXVH.net
「Git for Windows」のシェルが「bash 4.4」から「bash 5.1」へ ～Vista対応も終了
URLﾘﾝｸ(forest.watch.impress.co.jp)
Windowsで使ってる人（居る？）注意な
950:デフォルトの名無しさん
22/04/14 21:19:31.45 b6yuiJ9V.net
居る？ってどういう意味？
951:デフォルトの名無しさん
22/04/14 21:40:37.08
952:8uWvcswO.net
953:デフォルトの名無しさん
22/04/14 22:20:35.99 iEpp8WdZ.net
折るかーー？
よーし、折るな！ボキッ
954:デフォルトの名無しさん
22/04/14 22:52:34.66 3PT3emFr.net
ここやでトントン
955:デフォルトの名無しさん
22/04/14 23:33:30.30 UyRHFpqd.net
まさかMacなんて使ってんの？
956:デフォルトの名無しさん
22/04/15 00:07:36.02 ssUN7i/L.net
>>923
Windows Mac Linux
全部使ってる
957:デフォルトの名無しさん
22/04/15 00:18:20.61 zUdxudaZ.net
>>924
いいなぁ
958:デフォルトの名無しさん
22/04/15 18:54:21.17 C9bHMdiD.net
GUIのGitクライアントは面倒だよ
なんて言ってる先輩いるだけど
ほとんどコードは書けなくて、コピペしてそのコピペしたコードの意味も分かってない
そんなので、いくらgitが使えても意味なくね
959:デフォルトの名無しさん
22/04/15 19:37:30.49 h1UMySwV.net
>>926
何が言いたいのがわからんが、コマンドラインでGitが使いこなせなくて悔しいの？
コードが書けるのとGitを使いこなせるかどうかは直接は関係無いし、コピペとGitを使いこなして目的が達成できてるのならばそれは意味があることだよ
960:デフォルトの名無しさん
22/04/15 20:07:56.61 PiHpabQE.net
CUIなら同じことを繰り返したり再現するのも容易いし、スクリプトに組み込んで自動化したり本番処理を分けたり他人に渡すのも容易。
GUIも便利だけどCUIにもたくさんメリットがあるのよ
961:デフォルトの名無しさん
22/04/15 21:12:39.95 u9UTRnBL.net
僕も全くプログラム書けないけど
フリーランスのGit屋だぞ
962:デフォルトの名無しさん
22/04/15 21:35:15.77 0DFy/IGY.net
GUIのgit使おうとしたけどわけわからんくて投げたわ
やっぱコマンドラインよ
963:デフォルトの名無しさん
22/04/15 23:40:55 yVftr7r6.net
GUIもせめて自動実行マクロがあればマシなんだけどな。
OfficeのVBAみたいなやつ。
964:デフォルトの名無しさん
22/04/15 23:52:35.13 ssUN7i/L.net
>>931
それgitコマンド使ったバッチファイルやスクリプトでよくね？
965:デフォルトの名無しさん
22/04/16 00:02:24.87 gsNTgUrB.net
コマンドを打ってるだけで仕事してるフリしてる奴いるわ
たかがステージングするのに何分かかってんだよ
それならGUI使ったほうがグイっと終わるだろ
966:デフォルトの名無しさん
22/04/16 00:03:11.07 R5AqqekO.net
gitkだっけ
967:デフォルトの名無しさん
22/04/16 00:17:37.39 pQ5jcgqa.net
CUIだろうとGUIだろうと、どのファイルのどの行をコミットに含めるかは慎重に選べ
ゴミみたいなコミット作ってんじゃねぇ
968:デフォルトの名無しさん
22/04/16 01:06:24.34 dfz3lFMa.net
>>926
gitを否定しようと思ったけどできなかったんだよね？
だからgitを使ってる人を変わりに叩いて
自己満足してるでしょ？バレバレｗ
969:デフォルトの名無しさん
22/04/16 01:08:00 dfz3lFMa.net
>>933
CUIのほうがGUIよりも快適だからCUIを使ってるんだよ
文字使えば相手に意味を伝えられるのに
絵を書いて伝えたいなんて思わないでしょ？
970:デフォルトの名無しさん
22/04/16 02:42:04 Cn08VBkB.net
GUIで確認してCUIで実行するのが一番効率良くね？
GUIは一覧性が高いが、作業効率はCUIの方が良い
971:デフォルトの名無しさん
22/04/16 03:09:40.28 +A5PZLb9.net
st=status -s とか
ll=log --date-order --oneline --graphとか
alias設定すれば一覧性で困ることはないぞ
972:デフォルトの名無しさん
22/04/16 03:40:01.37 gsNTgUrB.net
それくらいのタイプ量ならエイリアス設定する方が面倒だわ
973:デフォルトの名無しさん
22/04/16 03:55:07.91 MmeJHHfa.net
道具の方にこだわってる奴って本業は全然できない奴多いよな
この5番、30万だぞってイキってて100程度で回ってるガキ多すぎ宿題
974:デフォルトの名無しさん
22/04/16 05:50:52 pQ5jcgqa.net
道具にこだわらないからCUIでgit�
975:ﾈんだろ GUIのはOSによっては使えない場合もあるしいちいち覚えるの面倒だし CUIなら設定ファイルちょろっとコピーすればいつもと同じ感覚で使えるし git使わないって選択肢はもう無しな gitはもう道具というより共通フォーマットだ
976:デフォルトの名無しさん
22/04/16 05:56:08 pQ5jcgqa.net
>>939
その辺は頻繁に使うんでエイリアスじゃなくて3～4文字のシェル関数だわ
とくにgit logの方は--pretty=format:～も指定したいんで手打ちはありえん
977:デフォルトの名無しさん
22/04/16 10:28:49.22 pKuJ7S+c.net
基本的にCUI派だけどログ出していくつかdiffを見るみたいな操作はGUI使うなあ
これをCUIで高効率でやる手段があるなら知りたい
978:デフォルトの名無しさん
22/04/16 11:07:45.89 gsNTgUrB.net
>>942
CUIかGUIかなんて問題なのか
どっちでも同じじゃん
やっぱりコマンドをタイプしてる方がカッコいいと思うタイプ？w
979:デフォルトの名無しさん
22/04/16 11:10:09.03 smzxZJvo.net
>>945
コマンドをタイプするのはかっこいいと思ってしまったから
お前はそんな書き込みをしたんだよね？
980:デフォルトの名無しさん
22/04/16 11:12:54.01 gsNTgUrB.net
いや俺はvscode一択
981:デフォルトの名無しさん
22/04/16 11:16:03 qSyY7sm9.net
あるある
コマンドを使ってるカッコイイと勘違い
Linuxを使ってるカッコイイと勘違い
ダークテーマを使ってるカッコイイと勘違い
vi emacsを使ってるカッコイイと勘違い
982:デフォルトの名無しさん
22/04/16 12:28:47.16 NWlFBoGL.net
TortoiseGitしか使ってなくてすいません
983:デフォルトの名無しさん
22/04/16 12:44:01.14 gsNTgUrB.net
ｶｺｲｲ
984:デフォルトの名無しさん
22/04/18 20:18:29.80 lvtGJgyq.net
CUIかGUIかなんてどーでも良いことには一切こだわらず
俺にとって使いやすい方法を採用してる俺様ｶｺｲｲ
985:デフォルトの名無しさん
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:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています