Git 20

2024/02/15(木) 09:50:09.07

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/
Git 19
https://mevius.5ch.net/test/read.cgi/tech/1667720427/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

**デフォルトの名無しさん** (JP 0H62-tcJ/) · 2024/07/30(火) 06:35:24.67

その3ディレクトリ以外は管理対象外にするような.gitignoreを書くだけでは

2024/07/30(火) 07:21:31.30

>>17
homeのユーザーディレクトリを丸ごとリポジトリにしてしまってもいいのでしょうか？

2024/07/30(火) 10:15:20.92

Git v2.46.0

**デフォルトの名無しさん** (JP 0H62-tcJ/) · 2024/07/31(水) 06:12:42.11

>>18
だってuser1直下のディレクトリ構成変えるのが嫌なんでしょ
乱暴だとは思うけど割り切ってこうするしかないよ？

2024/07/31(水) 18:41:12.02

>>20
ありがとうございます！

2024/09/15(日) 02:31:26.93

Git v2.46.1

2024/09/24(火) 08:35:15.36

Git v2.46.2

2024/09/27(金) 08:27:25.30

Git v2.47.0-rc0

2024/10/04(金) 12:52:23.68

Git v2.47.0-rc1

2024/10/05(土) 02:47:36.52

Gitって、
ややこしいね…

2024/10/06(日) 21:10:55.65

>>26
なにがややこしいの？

2024/10/07(月) 05:10:17.01

>>27

gitkraken使えばいいのかな…？

2024/10/08(火) 09:22:58.42

Git v2.47.0

警備員[Lv.30] (ﾜｯﾁｮｲ e59c-7BmO) · 2024/10/23(水) 15:25:36.90

PCがブルスクになって再起動したら、.gitフォルダが全く認識されなくなったけど、これもう終わりかね
git initしてもダメだった

2024/10/24(木) 20:20:25.88

なんか問題の切り分けできてなさそう

2024/10/24(木) 20:37:32.99

そりゃーいわね約束だべ

30 (ｵｯﾍﾟｹ Sr11-7BmO) · 2024/10/25(金) 15:25:22.24

もう終わった話なので大丈夫です

2024/10/27(日) 06:40:21.04

結局PCもgitも関係ないところのエラーだったんだろうな

2024/10/29(火) 16:36:54.68

今開発中の2.48は浜野氏がメンテナーをしていない模様

2024/10/29(火) 16:47:01.23

GitHubとかのパブリックリポジトリをクローンしてログを見てみると、
ブランチを作らずに複数人がmainにばんばんコミットしてるものも多いんだけど、
ブランチを作る作らないはどういう基準で分けてるんだろうか

2024/10/29(火) 20:27:36.21

>>36
ローカルにブランチ切ってるんじゃないの？

2024/10/30(水) 08:55:08.43

>>37
どうやったらmainをこんな一直線にできるんでしょうか？
ローカルのブランチをmainにマージするときに、リベースとか使ってるってことですか？

2024/10/30(水) 09:28:31.83

>>38
当然 rebase するだろう
git なんのために使うと思ってるんだ

2024/10/30(水) 14:32:17.39

何より自称意識高い系対策だろ

2024/10/31(木) 12:54:50.89

fork して branch してその branch を fork 元の main に対して pull request
merge したら main に合流
じゃないの

2024/10/31(木) 13:39:31.30

>>41
直前にもう一回 pull / rebase してから pull request しろや
メンテナに余計な手間かけさせるな

2024/11/01(金) 19:56:16.32

>>36 がブランチ無いって言うから解説してみたんだが

2024/11/02(土) 19:40:13.72

gitでファイルを管理したいです
というのも、あるide上で削除したファイルは完全削除になり、ゴミ箱に移動されません
またリドゥも出来ません

だから定期的にgitに保存して、そこから復元という形になるみたいです
しかし、例えば10秒に1回ファイル削除をした場合10秒ごとにリポジトリに保存しなければいけないのでしょうか
自動化はできそうですが、凄まじく面倒です

2024/11/02(土) 19:55:48.59

何も難しくねーんだから自動化すれば良いだろ
凄まじく面倒なんて言い訳は頭が悪いことを自白しているようなもんだ

2024/11/03(日) 05:29:56.13

gitの用途間違えてるよ
高頻度で削除するようなファイルを復元したがるケースがまず不明
どのIDEでどんなプロジェクトをどう運用してるか説明したほうがいい

本当に実現したいことに対して手法が間違ってる気がする

2024/11/06(水) 12:12:04.99

Gitの使い方のルールが明文化されていない職場が増えた

2024/11/06(水) 15:17:18.19

>>47
どんなルール？

2024/11/06(水) 20:07:20.18

職場でのルールってことでしょ
Git自体にルールはないよ

2024/11/07(木) 08:56:52.06

そりゃそうだろ何の話してると思ったの?w

2024/11/07(木) 23:37:53.08

>>44
そんなに頻繁にファイル消すてどういうプロジェクトなんだろう？
削除せずに、ゴミ箱的なフォルダに移動するとか、ファイルをリネームするとかで
どうにかならないの？

2024/11/08(金) 04:47:19.41

git は履歴保管箱じゃねーぞ
変更点の採用/不採用や再利用や順番の入れ替えなどをする道具だぞ
履歴の保管はそのための単なる手段だぞ
ファイル保管の道具と勘違いしてるやつが多過ぎる、特に他の VCS から移ってきたやつ

2024/11/08(金) 16:10:07.37

またお前か

2024/11/08(金) 18:49:52.14

>>51
彼はIDEとGitの二重管理がしたいらしいが、二重管理そのものが良くないと教えてやってよ。

2024/11/08(金) 18:51:25.49

>>52
それはGitではなく、GitHub、GitLabなどのGitのホスティングサービスのことだ。

2024/11/09(土) 11:14:39.71

チェックインチェックアウト型の方が合う職場の方が多いけどgit原理主義者がジャマをする

2024/11/10(日) 23:26:27.94

ファイルを弄ろうとした瞬間にダイアログが自動で開いて
お前は一体何のためにこのファイルを編集しようとしているんだ？
と意図を聞いてくるようなguiのgitクライアントやエディタってないの？
コミット時のコメントを先に書くようなの

2024/11/13(水) 18:08:56.60

それ必要ある？
煩わしいだけだよね

2024/11/14(木) 16:08:53.18

やることを明確にしてから手を動かす癖をつけるには悪くないアイデアだと思う
しかし強制力がないと結局煩わしいだけで終わりそうだから、宣言した内容から逸れるような変更をAIが検知して電気ショックを与えるような仕組みとセットだな

2024/11/14(木) 17:05:51.92

基本的に git はコードを書いてから、それをどのように他人に見せるか考える仕組み
最初に目的を書くとか git ではありえない

他の VCS 使え、無理して git を使う必要ないぞ
ステージが何のためにあるのか分かんない奴、ステージの便利さが分かんない奴は他のを使った方が幸せだと思うぞ

2024/11/14(木) 18:05:15.86

そりゃ暴論だな
Git自体は開発ワークフローではなくソースコードを管理するツールだから、UNIX的ミニマリズムの帰結でそうなってるだけの話で、
開発ワークフローとして先にコミットメッセージを決めちゃいけないわけではない
そういうワークフローをサポートする周辺ツールを作ればいいだけのことで、それを妨げるものは何もない

2024/11/14(木) 18:59:29.63

なんかGitと関係ない気がする

2024/11/14(木) 19:39:03.69

GitにはSVNのneeds-lockに相当するものはない
開発のスループットを上げるためにロックの考えは省いて競合解決はなるべく機械に頼る
そのあたりの思想やポリシーはリーナスが語ってたはず
彼が自分のために作ったツールだからそのあたり色濃くコマンドに現れてる
だがフロントエンドの開発を妨げるものはなにもない
必要だと思ったやつが自分で作ればいい
Git自身の思想とは別ベクトルを向いているので特殊でマイナーな用途のうちに入るから巷で誰かが公開してくれている可能性は低いかもしれないな

2024/11/14(木) 19:59:56.31

急にどうした

2024/11/14(木) 20:17:06.85

git の思想合わないのなら git以外を使えば良いのになんで git にこだわるんだろ
git は汎用ニュートラルなツールじゃなくて思想性の強いクセがあるツール、その分はまったら手放せなくなるけど
料理で言ったらカレー粉レベル、カレー味にしたくない時に使うのはお勧めできない

2024/11/14(木) 21:23:12.93

GitもSubversionも使い方は自由

2024/11/16(土) 11:27:19.19

思想性にクセの無い VCS なんてあるんかいな

2024/11/16(土) 14:54:04.41

>>67
ないよ、だから自分たちの手法/考えにあったやつを使うべき
有名だからといって git 向いてないやつが git 使うのは不幸になるだけ
git は素晴らしいツールだけど万人向けというわけではない

2024/11/16(土) 16:46:21.48

>>67
何にだって濃淡はあるだろ
あるなしの二択でしか考えられない1ビット脳かよ

2024/11/16(土) 16:51:08.62

>>69
濃淡といっても濃いやつかすごく濃いやつかの違い
薄いやつは存在しない

もちろん自分の思想にあってれば空気みたいに感じて薄いと思うかもだが、他の人にとっては猛毒という個人差

2024/11/16(土) 17:05:38.74

>>70
うん、だから >>63 はGitはかなり濃い目の部類って言ってるんだよ

2024/11/17(日) 11:09:45.68

いやわかるんだけどさ、適材適所にならずにgitが一番、git使うのが正しい、gitも使えないような奴ぁ、みたいにいらぬ波風を仕事で起こす迷惑な原理主義者が実際多いのよ

2024/11/17(日) 11:57:45.29

たかがソースコードのバージョン管理に適材適所とか多様性とか要らん
くだらん自転車置き場の議論で時間を無駄にするだけだから問答無用でgit一択でいい
ゲーム開発で巨大なアセットを管理する必要があるように管理対象の性質によって他を選ぶのは仕方ないが、
些細なワークフローの問題で他の選択肢を検討するべきではない

2024/11/17(日) 12:30:40.26

>>73
git 使う理由を考えろ
お前みたいな変なのがいるから、git でロックしたいだの、事前にコミット・メッセージ入れたいだの的外れなこと言い出すやつが湧いくことになる
git 使うんなら git のワークフローになるし、他のワークフローにしたいのなら他の VCS 使うべき
（全部が一緒に見えるアホはどれ使っても駄目だが）

2024/11/17(日) 14:21:11.61

Gitのワークフローなんてものは無い
個人の小規模開発では、手元のフォルダ上でデフォルトブランチにコミットするだけの使い方も多い
GitHub使ったクローズドな組織での開発では単一のリモードリポジトリで作業する中央集権型のワークフローが普通だ
一方で、OSSではフォークして互いにpullし合うのが一般的だろう
素のGitにはレビューやコメントもなければCI/CDもなく、マージやデプロイを承認するような機能もない
それらはあくまでGitと直行するものとしてGitHubによって自然な形で実装されたものだ
GitはLinuxカーネル開発のワークフローを前提として設計されたものではあるがGitそれ自体はワークフロー中立であり、
多様な使い方を受容することがGitがこれだけ広く普及した大きな理由だ

2024/11/17(日) 15:03:16.35

svnはバイナリも差分で保存してくれることは覚えといて損はないぜ
脳死でgit一択なんてこたーない

73 (ﾜｯﾁｮｲ 7b3f-qduf) · 2024/11/17(日) 15:08:32.39

>>76
よく読んでくれ
俺は管理対象の性質に応じて選択することは否定していない

2024/11/17(日) 18:01:53.15

>>75
もっと大きな部分を考えろ

分散して手元で開発
複数の人が同じファイルを並行して作業
ロックを取らずにマージ時に調整
ステージングでパッチを読みやすく整形
リベースでチェインを整形
個別ロックのかわりにブランチを使う

みたいなのも全部ワークフローだ
git 使ってると当たり前過ぎて空気になってるだけ、中央集権とかだけがワークフローじゃない

2024/11/17(日) 18:22:05.70

Q. バッティングするといやなのでロック取りたいんだが
A. ブランチ切れ、自分専用ブランチならバッティングしない

Q. 作業開始前に今からする作業の説明保存したいんだが
A. ブランチ切ってブランチの説明を追加しろ

だいたい git のワークフローに適した代替のやり方がある
個人ごとで保管すべきものが何で、全員で共有すべきものは何か？という根幹の考え方が VCS ごとに違っている

2024/11/17(日) 18:43:36.44

だからそういう話だろ？
なんか勘違いをしているようだが、質問者はあくまでクライアントの話をしている
自分の手元で自分以外誰も見ないし触らないブランチでやる分にはロックしようと自由だ

2024/11/17(日) 19:09:27.90

>>80
ロックは自由だ
LとR間違ってないか？何のため誰のためのロックの話？

2024/11/17(日) 19:28:00.48

だから>>57の通り、メッセージを先に書きたいだけでしょ
そもそもロックしたいとは言っていないが、実装するなら少なくとも手元のブランチに対する排他制御は必要だろうね

2024/11/17(日) 19:37:35.19

いやブランチじゃなくてリポジトリに対しての排他制御が必要か
コミット前だからどうせブランチは切り替えられないもんね
補足すると、自分で重複して同じクライアントを起動することによる競合を防ぐことを目的とした、同一PC上の同一のクライアント自身に対する排他制御な

2024/11/17(日) 19:51:48.68

ソースコードの履歴管理上の排他制御とリポジトリ内部の整合性を保証するための排他制御がごっちゃになってない？

2024/11/17(日) 20:35:32.55

なんでGitはおかしな原理主義者出てきやすいのだろう？
そりゃGitの～を使えばできます、は事実ですだろう
でも無理してなんでもかんでもGitでやる必要ないよなあ

どうも原理主義者くんはこの用途はこっちのバージョン管理ツールが合ってる、と言われるとGitにはその機能がない、と責められているように聞こえるらしい

2024/11/17(日) 21:12:22.55

git 以前にプログラミング向いてないやつがいるな
「ローカルでエディットしてるファイルを排他したいだけなら VCS じゃなくてエディタのロックの仕事」
って言われたら顔真っ赤にして反論するんだろうか？

30 (ﾜｯﾁｮｲ 4368-LaHf) · 2024/11/17(日) 22:38:40.72

git一択と言ってる奴いて草
これが原理主義か怖いねえ😱

2024/11/18(月) 23:21:35.04

日本人はやたら正解があることにしたがるが、外国人は正解が複数存在するという考えだから発展する。

2024/11/19(火) 07:05:59.68

>>85
> なんでGitはおかしな原理主義者出てきやすいのだろう？
馬鹿がイキるのに丁度良い複雑さだから
まともな人はコードに忙しくツールなんて出来るだけ疎かにするのもあって

2024/11/19(火) 17:13:14.46

ゴミ箱くんが帰ってきたのか？

2024/11/19(火) 19:37:11.73

>>90
思い出した。
専用のスレッド作ってもらっていて、2022/11/20だ。あれから2年か。

2024/11/25(月) 16:12:49.15

Git v2.47.1

2024/12/02(月) 01:10:56.87

ファイルのパーミッションって保存されないの?

2024/12/02(月) 09:32:52.91

>>93
実行権限以外は管理されない、git は保存ツールやバックアップツールでなくてコラボツールなので読み書き権限の管理は不要
Windows 使いとかで実行権限がうまくいかない場合は core.filemode=true 設定とか、--chmod とオプションとかを使うと良い

2024/12/03(火) 09:10:05.62

>>93
なんかバックアップと勘違いしてる人多いよね。
複数のPCで使う前提なのにパーミッション管理して何したいの？って思う。

2024/12/03(火) 12:44:13.34

>>93
されないね 600の設定ファイルとかでよく出るGitのあるあるなんだけど設計思想なんでしょうがない
他のVCSには出来るものもあるんでそっちを検討するか、毎回シェルスクリプトを叩くか、置けるならGitのフックを使うか
それこそドットファイルの管理なんかでマージとかはあんまり考慮しなく出来るなら、rsyncみたいな世代バックアップのツール使ってもいいかも

2024/12/03(火) 16:09:40.34

perforceは出来るけどまああれだしな
後はそれこそRCSくらいしか思い浮かばないけど他になんかあったっけ

2024/12/03(火) 17:16:17.61

>>97
昔は、
新しいのは考え方や目的が違う、ファイル単位で読み書き権限の管理とかしたかったら今まで通りRCSとかCVS使い続けろ
って言うのが常識だったんだが

2024/12/03(火) 23:07:05.89

>>96 >>97
なるほどありがとう
そういうことならスクリプトでやるかな

2024/12/05(木) 01:07:05.86

>>93
それはOSが管理しているのであって、ファイルそのものにそういう情報があるわけではない。

2024/12/05(木) 09:32:47.93

んなこと言ったらファイル名もいらないって話になっちゃうぞ。
ファイル名はinodeではなくデータだとかいうツッコミは無しな。それこそファイルシステムの実装の都合に過ぎないんだから。
Gitがパーミッションを扱わないのはLinuxカーネル開発のソース管理においてそれを必要としないからで、それ以上のこじつけは必要ない。

2024/12/05(木) 14:04:38.28

xlsxとかxmlとしてバージョン管理できないの？しなくて良いのかもしれんが

2024/12/05(木) 15:31:26.26

>>101
git 出てくる以前から svn とか他の分散型でも実行権限しか管理しないのが常識だったから linux kernel のせいにするのは間違い

2024/12/05(木) 19:17:01.43

>>101
プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw

2024/12/05(木) 19:17:26.14

>>101
プレーンテキストにこのファイルの説明書が付いているという発想はなかなか思いつかないぞw

2024/12/05(木) 19:19:57.44

Windowsだってファイルにアクセス制御情報があるのではない。

DOSがディスクオペレーションシステムだと知っていれば、ファイルを管理しているのはOSで、ファイルがOSに指示しているという発想が出てくるはずがない。

2024/12/05(木) 20:15:24.74

（この流れ早く終わらないかなあ）

2024/12/05(木) 20:36:07.99

必要な機能が欠けている、という事でしかないのでは。
実行権限だけ管理するというのもチグハグだし。

>>101
> それ以上のこじつけは必要ない。
完全に同意。
Git信者はGit一神教徒だから、Gitは間違ってない、間違わない、という前提で話をするからおかしくなる。
本当に間違ってないのであれば、更新する必要がない。ある意味CやHTMLがこれに近い。
Gitはツギハギだらけなんだから、パーミッションも今後は保存されるようになる、それの方が便利だから、というだけでよいのでは。

2024/12/05(木) 20:59:18.56

>>108
逆に git しか使ったことないやつがこういう戯言言うよな
最近のメジャーな VCS は実行権限しか管理しないのが普通なのに git 特有の仕様だと思い込んでる。git 以前からなのに

2024/12/05(木) 21:27:58.46

みなさんケンカはやめよう

2024/12/05(木) 22:57:49.39

しかし教科書ではきれいにブランチだのフィックスだのと理想的なバージョン
管理が語られるが、会社でそれなりの規模になってくるとユーザーもいろいろだし
MSオフィスファイルや画像やとファイルの種別も多いのでほんとカオス化するなあ
もうやだ

2024/12/05(木) 23:18:07.05

>>106
だからその理屈だとgitが実行権限やファイル名を扱えることを説明できないでしょ
Linuxでは実行権限はメタデータだし、ファイル名はファイルではなくディレクトリのデータだ
Windowsではファイル名はアクセス権限と同等のメタデータの一つだね

2024/12/05(木) 23:37:35.74

>>112
それはGitの話ではなく、Gitの使い方の話だぜ？

2024/12/05(木) 23:38:42.52

>>112
ファイル名がパス名なのはUNIXの話でLinux独自の考えじゃない

2024/12/05(木) 23:39:42.78

>>112
「メタデータ」の意味を取り違えていますけど？

2024/12/05(木) 23:42:05.86

このスレッドはLinuxにおけるGitのスレッドじゃねえのにな

2024/12/06(金) 09:03:40.82

>>112
不毛だと思うが続けるつもりならシンボリックリンクを突いた方がいいのでは？
Gitに整合性なんて無いし、
Linusには不要だったから付いてないが、一般人には必要だから質問されるって事にしかならないと思うが