Git 17

1 名前：デフォルトの名無しさん mailto:sage [2020/09/02(水) 12:18:30 ID:XN0SxNMq.net] ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。 Git - Fast Version Control System git-scm.com/ ◆関連サイト Pro Git - Table of Contents git-scm.com/book/ja Git入門 www8.atwiki.jp/git_jp/ ◆前スレ Git 15 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 844 名前：804 mailto:sage [2021/12/09(木) 09:39:57.87 ID:rmYbkO4s.net] どうも>>810です。プッシュはしてませんのでアメンドないしリセットとしてやり直すことは 可能です（よね?） なんというか、作業方法なども含めてキレイ&楽にやる方法はどんな感じかなと。 例えばそもそも論だと、最初からこういう場合に備えてコミットを関数1個毎とか細かくしておく? アメンドないしリセットしてやり直す場合も、どうやって変更を用意しようかなと... もう一回 同じ変更を入力したくはないし危険... とかなんとか。 845 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 10:00:49.33 ID:z12/cdNE.net] >>818 だから何をしたいのかはっきりしろ pushしてないのは分かった pushしてないローカルな履歴を改変したいのか？ pushしてないローカルな履歴に関数の修整を無効化するコミットを追加したいのか？ 846 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 10:05:24.50 ID:Dni9SPWj.net] >>818 変更の用意はrevert -nとreset -pでいいだろ この2つを使えば自分でコードを入力する必要は無い 847 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 11:35:29.86 ID:nPf7xXRe.net] >>818 だから>>812だって rebaseで過去の歴史の途中に戻って そこでコミットを分けるなりして 再び歴史を 848 名前：再生する [] [ここ壊れてます] 849 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 11:36:08.99 ID:nPf7xXRe.net] 正確には git rebase -i な 850 名前：デフォルトの名無しさん [2021/12/09(木) 13:53:35.69 ID:CTJ8MnG2.net] もう面倒くさいから一か所もどしましたってコミットしたらいいやん 851 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 14:15:33.20 ID:SnlJ6hdA.net] rebaseは悪い文化 852 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 14:50:31.70 ID:nPf7xXRe.net] >>824 必要なのは結果だけ お前が試行錯誤した後なんかどうでもいい 853 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 14:51:34.29 ID:Dni9SPWj.net] >>823 そのコミットを簡単に作る方法が知りたいのだと思う 854 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 15:05:38.49 ID:FiTzWudg.net] >>826 Winmergeをdiffツールに設定して git windiff HEAD^^^ で戻してcommitだな俺なら 855 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 15:28:07.01 ID:1oFDwxyl.net] >>818 そもそも論の部分に回答すると、意思決定の基本は発生率とコストを掛け合わせた期待値次第 いちいち細分化しすぎてもYAGNIの法則で言われるような無駄が多くなるだけ でも後から部分的に採用する可能性もそれなりにあるのであれば分けてコミットしておくことでコストを抑えられる可能性が増す 856 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 18:55:14.96 ID:lg/9Dj4Y.net] >>818 そもそも論で言うなら、追加・修正する機能ごとにブランチを切って、完成したブランチを別々にコミットすればいい。gitはブランチが軽量という強みもあるし。 機能をマージするときにコンフリクトを修正する面倒くささはあるけど、見通しは良くなる。 857 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 20:50:07.62 ID:ejbJEiiI.net] コミットの粒度の話じゃないの？ 858 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 22:51:55.36 ID:EKItVGZE.net] 追えてないけど、どれか。 ・そもそもコミットきれいにしても結局使わないから作り直さない ・頻繁にコンパイル？して頻繁にコミットしておく ・もう最初から作り直せよ派: git reset $(git merge-base origin/master) → 気に入るコミット作っていく。 ・ツールに関数単位で切り出させて、差分をうまいことやる。VisualStudioならこのメソッドをクラス化、みたいなやつがあったような。それ以外は知らん。 859 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 23:49:30.01 ID:Fvd6f3uE.net] コミットをセーブ機能だと思うからだめなんだよ 袋だと思え袋 コードを書くたびに適切な袋に入れろ 860 名前：デフォルトの名無しさん mailto:sage [2021/12/10(金) 11:49:29.41 ID:5non8kx0.net] >>831 ・追加機能ごとにブランチ切る も追加で。 861 名前：デフォルトの名無しさん mailto:sage [2021/12/10(金) 15:18:37.19 ID:dSCEiiiB.net] 最近では、機能ブランチは問題を先送りにしているだけだという批判もある 機能ブランチはすぐにリリースして消せ、作りかけならフィーチャートグルで蓋をしろというスタイルもあるぞ それは一理あって、実際複数のチームでそれぞれフィーチャーブランチを担当してリリース時に一気にマージするスタイルの大規模サービス開発やってたときには マージの失敗でトラブルが起こることは日常茶飯事だったね 862 名前：デフォルトの名無しさん mailto:sage [2021/12/11(土) 00:15:15.28 ID:L5jxStGt.net] それは機能ブランチが悪って話じゃなくて、機能ブランチをやたらと長期間分離しておくのが悪って話じゃね 何事もトレードオフだから機能がでかいならイテレーションを小さく取るし、リリースギリギリまでマージしなければ泣きを見るので頃合いを見て合流してテスト始める 互いに影響し合う部分についてはコミュニケーション取りつつ適宜ソースをやり取りしろというのがGitの指針だったと思うし 863 名前：デフォルトの名無しさん mailto:sage [2022/01/12(水) 10:21:41.75 ID:mFIs9bfU.net] Git v2.35.0-rc0 864 名前：デフォルトの名無しさん mailto:sage [2022/01/12(水) 19:57:57.27 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/01/12(水) 21:08:30.47 ID:et9b++qr.net] >>837 はい。そうです。 867 名前：デフォルトの名無しさん mailto:sage [2022/01/12(水) 21:16:41.65 ID:IbSx3jpA.net] >>838 ありがとうございます てか真上に同じような質問ありましたね… 868 名前：デフォルトの名無しさん mailto:sage [2022/01/15(土) 22:30:31.28 ID:mgu84OGw.net] Git v2.35.0-rc1 869 名前：デフォルトの名無しさん mailto:sage [2022/01/16(日) 00:47:01.30 ID:hYWYL0RZ.net] >>837 俺は作りながら片付ける 作ってる途中で、この修正はこのコミットに含めよう などと考えならが小さくコミットし 適度なタイミングでrebaseする 870 名前：デフォルトの名無しさん mailto:sage [2022/01/17(月) 06:52:31.08 ID:pA35C6jo.net] >>837 別ブランチでcommitして、masterにまとめてmergeしてpushする、って方法もあるよ これだとrebaseは不要 871 名前：デフォルトの名無しさん mailto:sage [2022/01/23(日) 09:44:11.74 ID:6R0k9GT3.net] gitもcvs,svnと同じ運命をたどるだろう 私の企業は次世代バージョン管理システムfossilに切り替えました 872 名前：デフォルトの名無しさん mailto:sage [2022/01/24(月) 13:46:51.63 ID:2I6HNHFB.net] 化石？ 873 名前：デフォルトの名無しさん mailto:sage [2022/01/24(月) 15:13:36.64 ID:TB1mn4oZ.net] 次世代って書いてるけどGitやMercurialと同期だね 統合が特徴みたいだけど、少なくとも統合指向＝先進的というのは言えない 昔のMSや古いエンタープライズシステムが通ってきた道 874 名前：デフォルトの名無しさん mailto:sage [2022/01/24(月) 20:03:13.29 ID:T/bW8QxB.net] sqlite以外に使ってるプロジェクトあるの？ 875 名前：デフォルトの名無しさん mailto:sage [2022/01/25(火) 09:41:06.99 ID:lI80daK7.net] Git v2.35.0 876 名前：デフォルトの名無しさん mailto:sage [2022/01/27(木) 23:05:55.20 ID:5JD4ntnW.net] 「Git 2.35」が公開 https://mag.osdn.jp/22/01/26/225600 877 名前：デフォルトの名無しさん mailto:sage [2022/01/29(土) 22:24:24.64 ID:DKHpcK/K.net] Git v2.35.1 878 名前：デフォルトの名無しさん mailto:sage [2022/02/04(金) 16:36:05.63 ID:57NC5giI.net] Git 日本語翻訳チーム https://github.com/vargaspeniel/git-l10n-ja 879 名前：デフォルトの名無しさん [2022/02/04(金) 16:53:15.37 ID:ldQUlQ88.net] >>850 gitを業務で使われている方は翻訳に参加してください 880 名前：デフォルトの名無しさん [2022/02/08(火) 12:18:02.21 ID:nuxork7Z.net] ウクライナのGitLabがやばいな 881 名前：デフォルトの名無しさん mailto:sage [2022/03/16(水) 08:10:03.07 ID:3iPp8Jr+.net] ゲイツもgit 作者も ワクチン派=ナチス 882 名前：デフォルトの名無しさん mailto:sage [2022/03/20(日) 18:56:58.51 ID: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 名前：デフォルトの名無しさん mailto:sage [2022/03/20(日) 20:08:48.92 ID:pStA9jik.net] サーバー側の receive.denyNonFastForwards の設定で禁止されてる 884 名前：デフォルトの名無しさん mailto:sage [2022/03/20(日) 20:17:36.65 ID:XwFj+GPH.net] >>854 git push --delete 〜 でリモートブランチ消してpushしなおせばまだワンチャンある 885 名前：デフォルトの名無しさん mailto:sage [2022/03/22(火) 00:18:15.54 ID:G4hvFEyv.net] 強制pushまだ禁じてるところあるんやね 886 名前：デフォルトの名無しさん mailto:sage [2022/03/22(火) 08:24:32.98 ID:OaCGWLhd.net] 馬鹿がいるんだから当たり前やろ 887 名前：デフォルトの名無しさん mailto:sage [2022/03/22(火) 15:19:11.35 ID:Oh3PkPXA.net] ブランチにアクセス権を設定できるサーバ 888 名前：なら、メインのブランチにはプルリクエスト処理する人だけがアクセス可能にして、強制push禁止と強制ブランチ削除禁止の設定はいらん気もするね でも本家gitにはブランチ単位のアクセス権は無いよね確か [] [ここ壊れてます] 889 名前：デフォルトの名無しさん mailto:sage [2022/03/22(火) 18:39:39.96 ID:GWInnMJp.net] >>854 プロジェクトメンバーに周知すればいいんでないの？ 890 名前：デフォルトの名無しさん mailto:sage [2022/03/25(金) 05:31:45.01 ID:VoO+G8uZ.net] こっそりと周知、ってのは難易度高いな 891 名前：デフォルトの名無しさん mailto:sage [2022/03/25(金) 07:14:27.74 ID:iMzzdMMk.net] こっそりする必要はないでしょ 892 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:00:41.82 ID:pZIqlelO.net] pullする前にどれが変更されているか知ることは出来ないの 893 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:03:54.04 ID:sFfsK7BI.net] git ls-remote 894 名前：デフォルトの名無しさん mailto:sage [2022/03/30(水) 21:50:58.83 ID:sIJSREW7.net] fetch 895 名前：デフォルトの名無しさん mailto:sage [2022/04/01(金) 00:22:46.86 ID:46G1puQR.net] totoiesegit使ってんですけ、コミットしただけでチェックアイコンに変わるんで pushし忘れることが多いんですけど、区別できないんですか？ 896 名前：デフォルトの名無しさん mailto:sage [2022/04/01(金) 04:32:18.73 ID:w7Dm7PZW.net] >>866 うん 897 名前：デフォルトの名無しさん mailto:sage [2022/04/01(金) 05:21:04.10 ID:vPqr4MnO.net] 尊いーぜgit ごめん言ってみただけ 898 名前：デフォルトの名無しさん mailto:sage [2022/04/01(金) 08:03:05.39 ID:4o646iU1.net] Gitsだぜ すいもあまいもー 899 名前：デフォルトの名無しさん mailto:sage [2022/04/01(金) 10:30:17.09 ID:L8R+vRlu.net] トータス使うよりSoucetree使う 900 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 16:17:20.40 ID:y/uyzFp6.net] リポジトリにあさんが変更をプッシュしたことをいさんはどうやって知れるのですか？ あさんからいさんへメールなりで連絡？ いさんがフェッチなり、プルすれば分かるんですが・・・ 901 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 16:43:53.49 ID:66/F4m6m.net] >>871 本来gitで想定されている正しい使い方としてはメールで連絡 今時の普通のチームならGitHubでpull requestを出す 902 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 16:46:06.34 ID:eQjRdGtS.net] 共有するリポジトリの置き場所に素のgitを使ってない限り、何らかの通知する仕組みはあるだろ？ 素のgitでもスクリプト仕込めばできるけど面倒だな「git hooks 通知」でぐぐれ 903 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 17:04:36.48 ID:y/uyzFp6.net] totoiesSVNの時はフォルダのアイコンが！に変わるから logを表示させればだれが、どこを変更したか分かるけど gitの場合、アイコン変わっていないから何時フェッチ、プルすればいいかわからない こういうもの？ 904 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 17:20:12.10 ID:66/F4m6m.net] >>874 Gitでは、同じブランチの上で複数人が作業することは普通しない 905 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 17:22:26.59 ID:a7IS8KL2.net] 同じことだよ TortoiseSVNを使っていても他人の変更が勝手に降ってくることはないぞ これまでほぼ無意識にときどき更新コマンドを実行してたんだろ Gitでもそれと同じように無意識にときどきフェッチすればいい リポジトリが新しかったりローカルが汚れているときにコンソールが赤とか黄色とかになる環境を作っておけばさらに分かりやすくなる 906 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 17:33:56.91 ID:y/uyzFp6.net] >>876 その「更新コマンド」を実行すべきタイミングが分からないんですよ とりあえずプルすれば、変更されていれば更新されるけど 変更されていなければ更新されない いちいちメールかなにかで連絡もらえれば、プルするから実害はないんだけど 907 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 17:37:22.85 ID:OkBLvXjb.net] git push したらｖｐｓのソースが更新されるようにしたのに、ヒミツ鍵でログインするタイプのvpsに変えたらgit pushでエラーが出るようになったわ 908 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 17:50:45.78 ID:ofyuLHc/.net] >>877 気になった時fetchすりゃいいんだよ。 909 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 18:18:39.57 ID:y/uyzFp6.net] >>879 １分おきにfetchするアルバ 910 名前：イト雇ったほうが工数的にはいいですね [] [ここ壊れてます] 911 名前：デフォルトの名無しさん mailto:sage [2022/04/02(土) 23:09:26.57 ID:ofyuLHc/.net] 変な質問だと思ったがネタだったか。四ね。 912 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 00:33:31.34 ID:TSy6KLqO.net] git reflogを時間指定して実行すると上手くログが取得できないんだが、自分だけ？ git logは普通に動く 913 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 09:55:27.42 ID:sNbs7j4z.net] >>881 釣られましたねｗ 914 名前：デフォルトの名無しさん mailto:sage [2022/04/03(日) 11:58:15.04 ID:YOg/TQMm.net] 気になったらエッチとな？ 915 名前：デフォルトの名無しさん mailto:sage [2022/04/04(月) 18:26:27.90 ID:uBqMrhkR.net] >>882 reflogで表示される時間はその操作が行われた時間ではなくてその操作の結果のHEADのコミットの時間で、reflogの--afterとかによる表示範囲判定は操作が行われた時間に基づいて判定されるぽいから、変な風に感じる？ HEADのコミットの時間でなくて操作した時間をreflogで表示する方法はあるのかな 916 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 06:52:00.45 ID:HDipRGT6.net] >>877 俺は開発ブランチにcommitした後にmasterをfetchしてる で、マージすべき内容ならmergeする 917 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 06:57:58.21 ID:qPBzPdZO.net] >>886 こういうのが居ると無駄なマージ履歴が残る。 コミットまたはプッシュする前にプルしてマージ完了した状態でプルするルールにしてる。 918 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 06:58:45.84 ID:qPBzPdZO.net] ×プルするルール ◯プッシュするルール 919 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 07:02:20.74 ID:HDipRGT6.net] >>887 これはfetchかpullのタイミングの話であって、それとこれとは別の話だよ それはpull request用のブランチにsquashなりすれば解決することだろ 920 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 07:09:17.66 ID:LSxkXP/U.net] squashするとまた意味が変わってくる 無駄なマージコミットを気にするならpull --rebaseするといい 921 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 08:27:03.94 ID:Tv9hyPpM.net] 内容ごとにブランチを切って、実装完了後にマージしたほうがいい。 こまめにマージする必要あるけど。 922 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 08:37:26.26 ID:VZWFnuGC.net] rebaseすると途中のコミットが見たことないスナップショットに化けるから諦めてmergeする派 923 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 10:22:46.93 ID:Ti8ZULSh.net] どうせマージコミットしか見ないからどうでもいいわ 924 名前：デフォルトの名無しさん mailto:sage [2022/04/05(火) 12:59:38.64 ID:HRL2Dhl7.net] Git v2.36.0-rc0 925 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 12:29:54.84 ID:/cWGM6C3.net] Git v2.36.0-rc1 926 名前：デフォルトの名無しさん [2022/04/10(日) 12:43:00.27 ID:gTtQQEaq.net] 今からGitを始めます初心者の質問です。 Gitに設定するユーザー名、メールアドレスと GitHubのアカウント作成で指定するユーザー名、メールアドレスは 同じものでないといけないのでしょうか？ 927 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 23:00:07.32 ID:TJ08CsNt.net] ネットでgitをググると コミットしたらﾌﾟｯｼｭっする癖をつけようなんて見かけるけど それなら意味なくね 928 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 23:03:53.52 ID:OSeViOAV.net] >>897 なんの意味？ 929 名前：デフォルトの名無しさん mailto:sage [2022/04/10(日) 23:58:14.27 ID:ZMrXNR+Y.net] 分散型リポジトリの意味かな？ つーかcommit→pushの流れが癖になるとまずいぞ develop or masterで作業してるかfeatureブランチをpushすることになる 930 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 00:51:42.12 ID:1i0W5uZP.net] >>896 同じにしないといけない 違ってるとGitHub上でコミットとユーザーが紐付かない なおGitHubのメールアドレスは複数設定できる 931 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 01:06:26.04 ID:Ip9E4gkF.net] いつプルすべきなのかさっぱり分からないんだけど いちいちフェッチして更新されてたらプルなの？ svnの時はフォルダのアイコンが変わるから、すぐ分かったんだけど ｇｉｔはめんどくさくてしかたねー 932 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 01:21:42.99 ID:IXb9iAbb.net] >>901 フォルダーのアイコンが変わるのはsvnの機能ではないだろw 933 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 01:26:34.08 ID:FKgiTkDa.net] ちんちんシュッ！シュッ！シュッ！ 934 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 03:26:40.92 ID:UsZcfkXO.net] >>901 そもそもsvnの挙動を勘違いしてん� 935 名前：ｶゃん [] [ここ壊れてます] 936 名前：890 [2022/04/11(月) 07:24:40.88 ID:pyEhSslH.net] >>900 レスありがとうございます。 そうしますと、 複数のメンバーでGitHubの一つのアカウント(リポジトリ)を共有する時の 各メンバーを識別するIDは、どこで指定するのでしょうか？ 937 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 07:35:11.19 ID:IXb9iAbb.net] どんなメールアドレスでもpushできるよ 938 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 08:54:42.93 ID:Ip9E4gkF.net] >>902 >>904 本筋には触れずに、否定をするﾜﾗ 939 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 09:14:16 ID:1i0W5uZP.net] >>905 関係ない。各自が自分のGitHub userに設定済みのメールアドレスでコミットすればいい。 GitHub上で制御できるのは「誰がリポジトリにpushできるか」までで、>>906も言ってるがどんなメールアドレスのコミットが含まれていてもpushできる。 たまたまコミットのメールアドレスがGitHub userと同じならGitHub上でそのユーザーがコミットしたように見えるというただそれだけのこと。 940 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 14:06:10.85 ID:MP0q4WMO.net] >>905 githubでプライベートリポジトリを複数ユーザで共有する場合は、共有するユーザみんな別々のアカウント作って、誰かが作ったレポジトリに他のユーザを招待して、pushするときにはそれぞれ各ユーザのアカウントで認証された状態ですることになるよね だから上でもだれか言ってるように、コミットのメールアドレスは認証で使われるわけじゃないから、どんなメールアドレスでもpushできる しかし、コミットのメールアドレスは重要でないというわけでもなくて、コミット一覧とか表示させたときにコミットのメールアドレスに基づいてユーザ名とか写真を表示したりするので、githubのアカウントに登録してあるメールアドレスをgitの方にも登録しておくほうが良い 941 名前：デフォルトの名無しさん mailto:sage [2022/04/11(月) 20:59:30.97 ID:voKtAiO9.net] >>907 少し上のレスを見ればわかるけど、その質問は「また釣りか」と思われてまともなレスは付かない。 942 名前：デフォルトの名無しさん mailto:sage [2022/04/13(水) 01:15:32.19 ID:TZC3qPMK.net] とある本の不要になったブランチを削除する手順で �@リモートリポジトリの消したいブランチを削除 �ASourcetreeのフェッチのリモートで消えた追跡ブランチを消去(Prune) �BSourcetreeの消したいローカルブランチを右クリックして削除 とありますが、�@がリモートリポジトリのブランチを削除、 �Bがローカルのそれだとすると �Aの手順にはどんな意味があるのでしょうか 943 名前：デフォルトの名無しさん mailto:sage [2022/04/13(水) 02:12:16.50 ID:eS/flNB4.net] ブランチには�@リモートブランチ �A(リモート)追跡ブランチ �Bローカルブランチの3種類がある 文脈によってこれらはしばしば混同されるので気をつけていないと混乱する �@はサーバー側にあり、�A�Bはクライアント側にある �Aは常に�@のコピーで、フェッチするたびに�@の最新と同期される だからネットワークに繋がっていなくてもいつでもリモートのログが見れる 「リモートブランチのログを見る」というとき、正確には�@ではなく�Aのログを見る行為を指す フェッチしていなければ�@�A�Bが全て別のコミットを指すこともある �Aを消し忘れると、サーバー側のブランチは削除済みなのに、そのクライアントからはまだリモートブランチが消えていないように見える 944 名前：デフォルトの名無しさん mailto:sage [2022/04/13(水) 03:53:52.80 ID:TZC3qPMK.net] >>912 詳しいご説明ありがとうございます！

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef