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

**デフォルトの名無しさん** · 2021/11/25(木) 12:21:37.68

すぐキレるLinusも若手から老害と言われてるんだろうな。

**デフォルトの名無しさん** · 2021/11/27(土) 18:33:16.18

プライベートなリポジトリをローカルにcloneしようとしたら
重いファイル（15MB程度）だけ弾かれる・・どうして・・
ちなみに学習済みの.h5ファイル
何か制限緩和するような手続きしないといけないのかな
（ただ、google経由だと全部cloneできた）
全然わからん・・

**デフォルトの名無しさん** · 2021/11/30(火) 21:35:19.46

10年程昔からの自作のフリーウェアを git で公開しようとしているんだけど
あまり昔の version はもう環境が変わっていて動かない
動くものだけを公開した方が良いのかな
それとも最新のものだけにした方がいいですか

**デフォルトの名無しさん** · 2021/11/30(火) 21:59:48.42

好きにしろ

**デフォルトの名無しさん** · 2021/11/30(火) 22:33:45.81

わかりました
どうも

**デフォルトの名無しさん** · 2021/12/09(木) 01:56:53.52

gitの変更履歴より細かい単位で変更を戻したいとき、うまい方法はありますかね。
例えば一つのファイルの中で3つの関数を変更してコミットした後、1つの関数だけ
元に戻したくなった場合などに。

**デフォルトの名無しさん** · 2021/12/09(木) 06:55:22.90

>>804
その関数を変更した後にコミット

**デフォルトの名無しさん** · 2021/12/09(木) 07:23:14.89

>>804
git rebase

1
2
3 ← ここで止める
4
5

1
2
3.1
3.2
3.3 ← こんな感じにコミット

git rebase --continue でリベース完了

あと慣れたら 2つの関数だけコミットして、
1つは戻ればいい

**デフォルトの名無しさん** · 2021/12/09(木) 08:05:36.93

>>804
pushする前ならcommit amend して修正してからrebase。
push後なら新たにcommit。

**デフォルトの名無しさん** · 2021/12/09(木) 08:13:38.11

あめんどは、あ、めんどう～だ、なぁ～

**デフォルトの名無しさん** · 2021/12/09(木) 08:15:15.22

求めてるのはadd -pじゃないのかな

**デフォルトの名無しさん** · 2021/12/09(木) 08:22:24.08

>>807
わかりづらいな……試してないけど
…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

ただし、コミットを他人と共有済みなら混乱の元なので禁止。

**デフォルトの名無しさん** · 2021/12/09(木) 08:58:11.54

>>804
履歴改変をするわけじゃないんだよね？それならば、
git revert -n でindexに三つの関数の修正を打ち消す修正を持ってきて、git reset -p でindexの余分な修正を取り除いて、git commit

**804** · 2021/12/09(木) 09:39:57.87

どうも>>804です。プッシュはしてませんのでアメンドないしリセットとしてやり直すことは
可能です（よね?）

なんというか、作業方法なども含めてキレイ&楽にやる方法はどんな感じかなと。
例えばそもそも論だと、最初からこういう場合に備えてコミットを関数1個毎とか細かくしておく?
アメンドないしリセットしてやり直す場合も、どうやって変更を用意しようかなと... もう一回
同じ変更を入力したくはないし危険... とかなんとか。

**デフォルトの名無しさん** · 2021/12/09(木) 10:00:49.33

>>812
だから何をしたいのかはっきりしろ
pushしてないのは分かった
pushしてないローカルな履歴を改変したいのか？
pushしてないローカルな履歴に関数の修整を無効化するコミットを追加したいのか？

**デフォルトの名無しさん** · 2021/12/09(木) 10:05:24.50

>>812
変更の用意はrevert -nとreset -pでいいだろ
この2つを使えば自分でコードを入力する必要は無い

**デフォルトの名無しさん** · 2021/12/09(木) 11:35:29.86

>>812
だから>>806だって
rebaseで過去の歴史の途中に戻って
そこでコミットを分けるなりして
再び歴史を再生する

**デフォルトの名無しさん** · 2021/12/09(木) 11:36:08.99

正確には git rebase -i な

**デフォルトの名無しさん** · 2021/12/09(木) 13:53:35.69

もう面倒くさいから一か所もどしましたってコミットしたらいいやん

**デフォルトの名無しさん** · 2021/12/09(木) 14:15:33.20

rebaseは悪い文化

**デフォルトの名無しさん** · 2021/12/09(木) 14:50:31.70

>>818
必要なのは結果だけ
お前が試行錯誤した後なんかどうでもいい

**デフォルトの名無しさん** · 2021/12/09(木) 14:51:34.29

>>817
そのコミットを簡単に作る方法が知りたいのだと思う

**デフォルトの名無しさん** · 2021/12/09(木) 15:05:38.49

>>820
Winmergeをdiffツールに設定して
git windiff HEAD^^^
で戻してcommitだな俺なら

**デフォルトの名無しさん** · 2021/12/09(木) 15:28:07.01

>>812
そもそも論の部分に回答すると、意思決定の基本は発生率とコストを掛け合わせた期待値次第
いちいち細分化しすぎてもYAGNIの法則で言われるような無駄が多くなるだけ
でも後から部分的に採用する可能性もそれなりにあるのであれば分けてコミットしておくことでコストを抑えられる可能性が増す

**デフォルトの名無しさん** · 2021/12/09(木) 18:55:14.96

>>812
そもそも論で言うなら、追加・修正する機能ごとにブランチを切って、完成したブランチを別々にコミットすればいい。gitはブランチが軽量という強みもあるし。

機能をマージするときにコンフリクトを修正する面倒くささはあるけど、見通しは良くなる。

**デフォルトの名無しさん** · 2021/12/09(木) 20:50:07.62

コミットの粒度の話じゃないの？

**デフォルトの名無しさん** · 2021/12/09(木) 22:51:55.36

追えてないけど、どれか。
・そもそもコミットきれいにしても結局使わないから作り直さない
・頻繁にコンパイル？して頻繁にコミットしておく
・もう最初から作り直せよ派: git reset $(git merge-base origin/master) → 気に入るコミット作っていく。
・ツールに関数単位で切り出させて、差分をうまいことやる。VisualStudioならこのメソッドをクラス化、みたいなやつがあったような。それ以外は知らん。

**デフォルトの名無しさん** · 2021/12/09(木) 23:49:30.01

コミットをセーブ機能だと思うからだめなんだよ
袋だと思え袋
コードを書くたびに適切な袋に入れろ

**デフォルトの名無しさん** · 2021/12/10(金) 11:49:29.41

>>825
・追加機能ごとにブランチ切る
も追加で。

**デフォルトの名無しさん** · 2021/12/10(金) 15:18:37.19

最近では、機能ブランチは問題を先送りにしているだけだという批判もある
機能ブランチはすぐにリリースして消せ、作りかけならフィーチャートグルで蓋をしろというスタイルもあるぞ
それは一理あって、実際複数のチームでそれぞれフィーチャーブランチを担当してリリース時に一気にマージするスタイルの大規模サービス開発やってたときには
マージの失敗でトラブルが起こることは日常茶飯事だったね

**デフォルトの名無しさん** · 2021/12/11(土) 00:15:15.28

それは機能ブランチが悪って話じゃなくて、機能ブランチをやたらと長期間分離しておくのが悪って話じゃね
何事もトレードオフだから機能がでかいならイテレーションを小さく取るし、リリースギリギリまでマージしなければ泣きを見るので頃合いを見て合流してテスト始める
互いに影響し合う部分についてはコミュニケーション取りつつ適宜ソースをやり取りしろというのがGitの指針だったと思うし

**デフォルトの名無しさん** · 2022/01/12(水) 10:21:41.75

Git v2.35.0-rc0

**デフォルトの名無しさん** · 2022/01/12(水) 19:57:57.27

こういうコミットをしてたとして

$ 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が使われるんですかね？

**デフォルトの名無しさん** · 2022/01/12(水) 21:08:30.47

>>831
はい。そうです。

**デフォルトの名無しさん** · 2022/01/12(水) 21:16:41.65

>>832
ありがとうございます

てか真上に同じような質問ありましたね…

**デフォルトの名無しさん** · 2022/01/15(土) 22:30:31.28

Git v2.35.0-rc1

**デフォルトの名無しさん** · 2022/01/16(日) 00:47:01.30

>>831
俺は作りながら片付ける

作ってる途中で、この修正はこのコミットに含めよう
などと考えならが小さくコミットし
適度なタイミングでrebaseする

**デフォルトの名無しさん** · 2022/01/17(月) 06:52:31.08

>>831
別ブランチでcommitして、masterにまとめてmergeしてpushする、って方法もあるよ
これだとrebaseは不要

**デフォルトの名無しさん** · 2022/01/23(日) 09:44:11.74

gitもcvs,svnと同じ運命をたどるだろう
私の企業は次世代バージョン管理システムfossilに切り替えました

**デフォルトの名無しさん** · 2022/01/24(月) 13:46:51.63

化石？

**デフォルトの名無しさん** · 2022/01/24(月) 15:13:36.64

次世代って書いてるけどGitやMercurialと同期だね
統合が特徴みたいだけど、少なくとも統合指向＝先進的というのは言えない
昔のMSや古いエンタープライズシステムが通ってきた道

**デフォルトの名無しさん** · 2022/01/24(月) 20:03:13.29

sqlite以外に使ってるプロジェクトあるの？

**デフォルトの名無しさん** · 2022/01/25(火) 09:41:06.99

Git v2.35.0

**デフォルトの名無しさん** · 2022/01/27(木) 23:05:55.20

「Git 2.35」が公開
https://mag.osdn.jp/22/01/26/225600

**デフォルトの名無しさん** · 2022/01/29(土) 22:24:24.64

Git v2.35.1

**デフォルトの名無しさん** · 2022/02/04(金) 16:36:05.63

Git 日本語翻訳チーム
https://github.com/vargaspeniel/git-l10n-ja

**デフォルトの名無しさん** · 2022/02/04(金) 16:53:15.37

>>844
gitを業務で使われている方は翻訳に参加してください

**デフォルトの名無しさん** · 2022/02/08(火) 12:18:02.21

ウクライナのGitLabがやばいな

**デフォルトの名無しさん** · 2022/03/16(水) 08:10:03.07

ゲイツもgit 作者もワクチン派=ナチス

**デフォルトの名無しさん** · 2022/03/20(日) 18:56:58.51

すみません、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が禁止されていたりしますかね?

**デフォルトの名無しさん** · 2022/03/20(日) 20:08:48.92

サーバー側の receive.denyNonFastForwards の設定で禁止されてる

**デフォルトの名無しさん** · 2022/03/20(日) 20:17:36.65

>>848
git push --delete ～でリモートブランチ消してpushしなおせばまだワンチャンある

**デフォルトの名無しさん** · 2022/03/22(火) 00:18:15.54

強制pushまだ禁じてるところあるんやね

**デフォルトの名無しさん** · 2022/03/22(火) 08:24:32.98

馬鹿がいるんだから当たり前やろ

**デフォルトの名無しさん** · 2022/03/22(火) 15:19:11.35

ブランチにアクセス権を設定できるサーバなら、メインのブランチにはプルリクエスト処理する人だけがアクセス可能にして、強制push禁止と強制ブランチ削除禁止の設定はいらん気もするね
でも本家gitにはブランチ単位のアクセス権は無いよね確か

**デフォルトの名無しさん** · 2022/03/22(火) 18:39:39.96

>>848
プロジェクトメンバーに周知すればいいんでないの？

**デフォルトの名無しさん** · 2022/03/25(金) 05:31:45.01

こっそりと周知、ってのは難易度高いな

**デフォルトの名無しさん** · 2022/03/25(金) 07:14:27.74

こっそりする必要はないでしょ

**デフォルトの名無しさん** · 2022/03/30(水) 21:00:41.82

pullする前にどれが変更されているか知ることは出来ないの

**デフォルトの名無しさん** · 2022/03/30(水) 21:03:54.04

git ls-remote

**デフォルトの名無しさん** · 2022/03/30(水) 21:50:58.83

fetch

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

totoiesegit使ってんですけ、コミットしただけでチェックアイコンに変わるんで
pushし忘れることが多いんですけど、区別できないんですか？

**デフォルトの名無しさん** · 2022/04/01(金) 04:32:18.73

>>860
うん

**デフォルトの名無しさん** · 2022/04/01(金) 05:21:04.10

尊いーぜgit
ごめん言ってみただけ

**デフォルトの名無しさん** · 2022/04/01(金) 08:03:05.39

Gitsだぜ
すいもあまいもー

**デフォルトの名無しさん** · 2022/04/01(金) 10:30:17.09

トータス使うよりSoucetree使う

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

リポジトリにあさんが変更をプッシュしたことをいさんはどうやって知れるのですか？
あさんからいさんへメールなりで連絡？
いさんがフェッチなり、プルすれば分かるんですが・・・

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

>>865
本来gitで想定されている正しい使い方としてはメールで連絡
今時の普通のチームならGitHubでpull requestを出す

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

共有するリポジトリの置き場所に素のgitを使ってない限り、何らかの通知する仕組みはあるだろ？
素のgitでもスクリプト仕込めばできるけど面倒だな「git hooks 通知」でぐぐれ

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

totoiesSVNの時はフォルダのアイコンが！に変わるから
logを表示させればだれが、どこを変更したか分かるけど
gitの場合、アイコン変わっていないから何時フェッチ、プルすればいいかわからない

こういうもの？

**デフォルトの名無しさん** · 2022/04/02(土) 17:20:12.10

>>868
Gitでは、同じブランチの上で複数人が作業することは普通しない

**デフォルトの名無しさん** · 2022/04/02(土) 17:22:26.59

同じことだよ
TortoiseSVNを使っていても他人の変更が勝手に降ってくることはないぞ
これまでほぼ無意識にときどき更新コマンドを実行してたんだろ
Gitでもそれと同じように無意識にときどきフェッチすればいい
リポジトリが新しかったりローカルが汚れているときにコンソールが赤とか黄色とかになる環境を作っておけばさらに分かりやすくなる

**デフォルトの名無しさん** · 2022/04/02(土) 17:33:56.91

>>870
その「更新コマンド」を実行すべきタイミングが分からないんですよ
とりあえずプルすれば、変更されていれば更新されるけど
変更されていなければ更新されない

いちいちメールかなにかで連絡もらえれば、プルするから実害はないんだけど

**デフォルトの名無しさん** · 2022/04/02(土) 17:37:22.85

git push したらｖｐｓのソースが更新されるようにしたのに、ヒミツ鍵でログインするタイプのvpsに変えたらgit pushでエラーが出るようになったわ

**デフォルトの名無しさん** · 2022/04/02(土) 17:50:45.78

>>871
気になった時fetchすりゃいいんだよ。

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

>>873
１分おきにfetchするアルバイト雇ったほうが工数的にはいいですね

**デフォルトの名無しさん** · 2022/04/02(土) 23:09:26.57

変な質問だと思ったがネタだったか。四ね。

**デフォルトの名無しさん** · 2022/04/03(日) 00:33:31.34

git reflogを時間指定して実行すると上手くログが取得できないんだが、自分だけ？
git logは普通に動く

**デフォルトの名無しさん** · 2022/04/03(日) 09:55:27.42

>>875
釣られましたねｗ

**デフォルトの名無しさん** · 2022/04/03(日) 11:58:15.04

気になったらエッチとな？

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

>>876
reflogで表示される時間はその操作が行われた時間ではなくてその操作の結果のHEADのコミットの時間で、reflogの--afterとかによる表示範囲判定は操作が行われた時間に基づいて判定されるぽいから、変な風に感じる？
HEADのコミットの時間でなくて操作した時間をreflogで表示する方法はあるのかな

**デフォルトの名無しさん** · 2022/04/05(火) 06:52:00.45

>>871
俺は開発ブランチにcommitした後にmasterをfetchしてる
で、マージすべき内容ならmergeする

**デフォルトの名無しさん** · 2022/04/05(火) 06:57:58.21

>>880
こういうのが居ると無駄なマージ履歴が残る。
コミットまたはプッシュする前にプルしてマージ完了した状態でプルするルールにしてる。

**デフォルトの名無しさん** · 2022/04/05(火) 06:58:45.84

×プルするルール
◯プッシュするルール

**デフォルトの名無しさん** · 2022/04/05(火) 07:02:20.74

>>881
これはfetchかpullのタイミングの話であって、それとこれとは別の話だよ
それはpull request用のブランチにsquashなりすれば解決することだろ

**デフォルトの名無しさん** · 2022/04/05(火) 07:09:17.66

squashするとまた意味が変わってくる
無駄なマージコミットを気にするならpull --rebaseするといい

**デフォルトの名無しさん** · 2022/04/05(火) 08:27:03.94

内容ごとにブランチを切って、実装完了後にマージしたほうがいい。
こまめにマージする必要あるけど。

**デフォルトの名無しさん** · 2022/04/05(火) 08:37:26.26

rebaseすると途中のコミットが見たことないスナップショットに化けるから諦めてmergeする派

**デフォルトの名無しさん** · 2022/04/05(火) 10:22:46.93

どうせマージコミットしか見ないからどうでもいいわ

**デフォルトの名無しさん** · 2022/04/05(火) 12:59:38.64

Git v2.36.0-rc0

**デフォルトの名無しさん** · 2022/04/10(日) 12:29:54.84

Git v2.36.0-rc1

**デフォルトの名無しさん** · 2022/04/10(日) 12:43:00.27

今からGitを始めます初心者の質問です。

Gitに設定するユーザー名、メールアドレスと
GitHubのアカウント作成で指定するユーザー名、メールアドレスは
同じものでないといけないのでしょうか？

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

ネットでgitをググると
コミットしたらﾌﾟｯｼｭっする癖をつけようなんて見かけるけど
それなら意味なくね

**デフォルトの名無しさん** · 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の挙動を勘違いしてんじゃん