Git 19

2022/11/06(日) 16:40:27.51

ソースコード管理を行う分散型バージョン管理システム、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 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/

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

2023/01/23(月) 10:51:47.46

>>406
ありがとう。参考にシマス。

2023/01/23(月) 17:43:30.01

>>405
deだけを付け直すrebaseのオプションがあったはず。ブランチ切らないとダメかもしれないけど

https://git-scm.com/book/en/v2/Git-Branching-Rebasing

これの more interesting rebasesのところ
日本語版もあると思うので読んでみてくれ

2023/01/24(火) 14:12:59.02

>>408
ありがとう。読んだけど脳みそのキャパオーバーぎみ。
マージと同じような意味でリベース使えば履歴がスッキリするよって感じなのかな。

2023/01/25(水) 18:58:25.67

GitHubでフォークされた場合にフォークリポジトリを削除してもらう方法ってフォーク主にお願いするしかないんですか？

2023/01/25(水) 19:26:11.38

いいえ、フォーク主にお願いしても削除できません

2023/01/25(水) 19:33:00.95

>>411
そういう仕様ですか？

2023/01/25(水) 19:37:07.29

フォーク主にお願いしただけでは削除されませんっていう重箱の隅

2023/01/25(水) 19:50:29.62

フォーク自体は削除できるのでフォーク主にお願いして削除してもらえばいいと思うのですが
現実問題としてそれで削除してもらえるのかという問題はありますけど
他にいい方法ないですかね？

2023/01/25(水) 21:01:54.27

個人情報うpしちゃったとかなら
GitHubのサポートに削除してもらえるかも

フォークした奴がお願いしてもきかなくてまたpushしたりした場合は知らん

APIキー漏らしたとかなら
悪用される前にAPIキーを無効化して作り直すべき

2023/01/25(水) 22:32:00.35

そもそもgithubの話題はスレチ

2023/01/26(木) 21:19:38.08

じゃあどのスレならいいの？

2023/01/27(金) 02:39:06.99

githubとかのスレ落ちてるね

2023/01/27(金) 02:41:24.15

1000まで使い切って落ちたみたいだから次スレたてようか
前スレがOSSホスティング総合からｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合に名前変えた1スレ目だったから、次スレをｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合の2スレ目にして立ててしまおう
ちょっと長いからスレタイからbitbucketは退場してもらう「ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合 2【GitHub,GitLab等】」で

2023/01/27(金) 02:50:50.96

立てた

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合 2【GitHub,GitLab等】
http://mevius.5ch.net/test/read.cgi/tech/1674755161

次のGitスレの1にもこのリンクなるべく貼ろう
githubの話題はこっちにって

2023/02/15(水) 08:49:46.98

Git v2.39.2

2023/02/19(日) 15:35:48.54

.gitignoreに
supervisord*
と記述していて
supervisord.log
supervisord.log.2
supervisord.log.3
supervisord.pid
は除外されるんだが
supervisord.log.1
だけ除外されない。これなんで？

2023/02/19(日) 15:41:46.42

どうせ誤字だろ
>>422をコピーして各行の頭にtouchつけてファイル作成したけどちゃんと全部除外になったぞ

2023/02/19(日) 15:42:44.58

誤字する余地ある？
つーかそのままコピペしたんだけどどこか間違ってる？

2023/02/19(日) 19:10:19.28

.gitignoreに記述する前にそのファイルだけaddしてたとかコミット済みだったとか？

2023/02/22(水) 14:17:17.89

TortoiseSVNは内部にSubversionの機能を持っていてましたが、TortoiseGitとGitは別れていて、
TortoiseGitとGitは別々に自分でアップデートしなくてはいけないということで合ってますか？

2023/02/22(水) 14:34:18.81

あってるよ
TortoiseGitは単なるシェルエクステンション

2023/02/22(水) 14:38:45.82

>>425
多分だけどそれが正解ぽかった
おさわがせしました

2023/02/22(水) 14:41:46.67

Gitを時代遅れにする革新的な次世代VCSってないの？

2023/02/22(水) 14:44:38.95

>>427
やっぱりそいういう原理ですか
TortoiseGitは最新版を通知してくるけど、Gitそのものは自分で定期的に調べることになりますかね

2023/02/22(水) 14:47:25.92

>>429
pijulが技術的には面白そう

2023/02/23(木) 10:18:27.51

Linus Torvalds氏、Gitのマージに関し「マージについて説明できないのならやらないほうがいい」ゴミだからとアドバイス
https://softantenna.com/blog/linus-torvalds-git-merge-advice/

2023/02/23(木) 12:32:27.18

pushするときにリモートからpullし忘れてて(大抵修正加えた.MDファイル)面倒でそのままmergeして済ましちゃうことあるわ

2023/02/23(木) 13:42:07.29

githubって、利用規約的に、プログラミング以外の、例えば、工学でもないような
科学の分野の記事を投稿してもいいのかな？

2023/02/23(木) 16:38:51.57

利用規約を読めば分かるのでは
それとも読んだけど文章が理解出来ないからここで聞いてるってこと?

2023/02/23(木) 17:25:36.02

>>435
まあ、そうおっしゃらずに。

2023/02/23(木) 19:53:24.41

ここは github スレじゃないので、詳しくはそっちで聞いた方がいいんじゃないか？

既にドキュメントとか、小説とか、TRPGのルールとか上がってる時点で見当がつくかもだが、プログラム縛りとかないよ。
ただし無料版は、公開した時点でフォークに同意したことになるのでオープンソースなライセンスのものに限る。「俺の小説を読め」では駄目で「俺の小説を好き勝手に改変して良いよ」な必要がある。

2023/02/23(木) 23:08:58.36

>>437
じゃあ課金すれば俺の小説を読めでいいんだね

2023/02/24(金) 03:19:03.50

>>438
一般公開しなければOK
金払って身内オンリーのプロジェクトにして、身内に俺の小説読めとやる分には問題ないはず

2023/02/24(金) 07:04:25.06

>>439
無料ユーザーでもプライベートリポジトリは作成できるけど、それじゃだめなの？

2023/02/25(土) 12:18:16.14

WindowsでTortoiseGitを入れてみたら、
文字が収まっていないボタンやらテキストやらがあちこちにあるんだけど、
もう誰も日本人はメンテナンスしていないということ？

2023/02/25(土) 12:38:25.55

>>441
トータスSVNに思い入れのある奴以外わざわざシェルエクステンション入れようと思うのが少ないからでは

2023/02/25(土) 12:51:57.84

コマンド名まで訳されて使い物にならないから英語のままでいいんだよ

2023/02/25(土) 14:04:39.71

Git v2.40.0-rc0

**デフォルトの名無しさん** (ｽﾌｯ Sdfa-/m9g) · 2023/02/25(土) 23:13:40.02

>>443
これ

2023/03/02(木) 09:01:59.55

Git v2.40.0-rc1

2023/03/05(日) 13:04:21.70

Gitで、たとえばWindowsの共有フォルダC:\share\内にgitrepo\repo1でレポジトリを作って、

・自分…C:\share\gitrepo\repo1をレポジトリとして扱う
・他人…\\mypc\gitrepo\repo1をレポジトリとして扱ったり、
　C:\share\をネットワークドライブに割り当ててX:\gitrepo\repo1として扱う

という使い方を混在させられますか

2023/03/08(水) 08:49:32.65

Git v2.40.0-rc2

2023/03/08(水) 15:10:53.84

>>447
出来るはず

2023/03/08(水) 15:30:31.63

>>447
できるけど、作業ツリー付きのリポジトリだとpushが出来ないとかでハマるから、自分のPCの中にベアリポジトリを作って、そこから自分の作業ツリーも他人の作業ツリーもcloneした方がいい
要は、remoteはgit://のURLで始まってる必要はなくて、file:///でも全く同じように動作するってこと。

2023/03/08(水) 22:23:57.15

gitってオフラインでローカルでも使えるんだな。練習もしやすいんだね

2023/03/14(火) 07:38:19.27

Git v2.40.0

2023/03/14(火) 20:58:29.14

Windows向けGitって、mingwとかbashとかGNU系コマンドまでいろいろ入ってて
インストールしたら400MBくらいの容量食うことになるけど、
本当にあれ全部必要なの?

2023/03/14(火) 23:44:11.24

>>453
自分で消してみたら分かるんじゃないの

2023/03/20(月) 12:35:58.85

Windows上で、TortoiseGitとSourceTreeと両方入れて、
1つのリポジトリに対して両方を使い分けるようなことは問題ないですか？
どちらも.gitの中身をリアルタイムで見ているだけなら大丈夫そうに思えるのですが。

2023/03/20(月) 17:30:03.68

問題無い
更新するときもロックファイル作ってからやるから平気なはず

2023/03/20(月) 19:28:34.75

ありがとうございます。併用できるんですね。
ファイル単位の履歴などはTortoiseGitのほうが使いやすいし、
ブランチの切り替えや全体の状況などはSourceTreeのほうが使いやすいです。

2023/03/24(金) 15:34:13.51

>>441
英語版も収まってないとこあるよ

2023/03/28(火) 17:21:29.11

TortoiseGit入れたらExplorerが重くなったり落ちたりしたからもう使ってない

2023/03/28(火) 19:02:23.66

さーせん、最初のところを何も考えずにyesしました。

2023/03/29(水) 00:17:09.12

>>453
オープンソース系のソフトはみんなそんな感じだね。
EmscriptenやTeXも巨大。
TeXなんてさして機能アップして無いのに数GBのインストールが必要だったりする。
もともとは10MBでも動く程度のものだったはずなのに。

2023/03/29(水) 01:47:09.24

>>453
Linux 系のOSS で、Linux以外で動くものはあるかな？

例えば、Ruby も初心者用の本では、Linuxの勉強を避けるため、MSYS2/MinGW で、
プロはWSL2, Linux, Docker, AWS

Windows に、OSSは載せられないから、
Microsoft 製のものはWindows 10 以降に作られた、SSH, curl, tar など

コマンドプロンプトで、
where ssh
C:\Windows\System32\OpenSSH\ssh.exe

where curl
C:\Windows\System32\curl.exe

where tar
C:\Windows\System32\tar.exe

以前からPowerShell(PS)には、
微妙に異なる、似たようなssh, curl, wget はあったけど

PSで、
ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

Get-Alias -Definition Invoke-WebRequest
iwr, curl, wget

2023/03/29(水) 03:49:58.38

元々インフラ屋だったから、
マジで開発環境を
>>462
こんな感じで右往左往しとる

2023/03/29(水) 07:00:07.39

>>453 だが、結局Busybox版MinGitにした

サイズ小さいし、VSCodeやEclipseのGit拡張機能からでも使えるし、十分だわ

2023/03/29(水) 11:32:54.49

OSS という訳ではなく、Freeで有名なアプリでもライセンスチェックされてOKなものでないとWindowsに導入できない会社も多いんじゃないかな。
Windows10 はそんなに準備してくれていたのか、とOpenSSH 以外は初めて知った。

2023/03/29(水) 11:36:13.25

>>463
WSL使えば右往左往しなくていいよ

2023/03/30(木) 02:21:13.08

オープンソース系が好きな開発者は、Unix原理主義者である事も多く、
Windowsではシンボリックリンクが使えないことを「いいことに」
シンボリックリンクをファイルのコピーで済ます。それで爆発的に肥大化する。
そして馬鹿で技術力が無いのでサイズが大きなセットでしかソフトを作れない。

2023/03/30(木) 02:47:46.58

20世紀から知識が更新されてない人だろうか？

2023/03/30(木) 03:19:39.83

>>468
あなたこそ、現実にオープンソースソフトウェアを試してない。
試したらすぐ分かること。

2023/03/30(木) 03:56:59.98

>>469
Windows にシンボリック・リンクが無かったのは大昔に話ですよ。いくら 2ch が老人集会所だからって、知識が Windows XP どまりとか笑える。

2023/03/30(木) 04:09:23.59

git スレにきて、「お前はオープンソースソフトウェアを試していない」とか言い出す奴おる？
長文君といい、このスレ定期的に変な奴湧くなあ

2023/03/30(木) 15:38:07.97

>>470
あっても大部分のオープンソースアプリでは使われて無い。
馬鹿だから。

2023/03/30(木) 18:20:59.63

>>472
ここはお前の妄想を語る場所じゃないよ。
git の話しろ。

2023/03/30(木) 20:36:16.47

複数人が同一ブランチで作業していて、それぞれ異なるファイルを修正しているのですが、
一人がプッシュすると、他の人がそれをプルしてくる際にマージのコミットが発生します。
ff-onlyの設定だと、複数人の作業ではいつもプルに失敗します。
Gitでは複数人での作業はこういうものなのでしょうか。

2023/03/30(木) 21:17:24.39

そういうもんだけどその複数人たる他の人達はそのことについてあなたになんて言ってるのさ

2023/03/30(木) 23:49:49.22

>>474
普通は同じブランチ上で作業しない。
ブランチ切るのは無料なので各自が自分用の作業ブランチを切ってそこで作業する。ff-only の場合は特に。
ブランチ切らずに作業するのは hot fix とか超急いでる時だけ。

2023/03/31(金) 09:11:50.51

>>475-476
一つの機能追加やバグ修正を、複数人で対応するようなケースなんですが、
こういう場合も一人一人ブランチを切って作業するものなんですか？
そうなると、ブランチでフェッチやプルが必要なケースってなくなってしまいそうですが。

2023/03/31(金) 10:25:27.66

>>474
異なるファイルを編集しようが、すでに起こったコミット済みのファイル間で一貫性が保たれていないかもしれない状態かもしれないわけだしマージするしかなくない？
モジュールAとモジュールBはお互いの内部実装に依存しているが、AとBを変更した担当者がお互いの変更を知らないでコミットツリーが1本になっちゃっても困るでしょう。
見た目上マージを避ける方法としてはrebaseとかあるけど。

2023/03/31(金) 10:58:07.02

>>478
プルのときにリベースをすると、マージコミットが発生しないようにできるんですね。
いろいろ勉強していたら、複数人での開発でマージコミットが履歴の上に何度も現れるのは目障り、
と同じような感想を持っているサイトがあり、リベースが紹介されていました。

2023/03/31(金) 12:50:57.47

merge commit ない方が履歴を追いやすいので普段の小さな更新は rebase でやるのが一般的。
一方で長く別れていた異なる経歴のものを混ぜる場合には merge commit があった方が分かりやすいので merge にするべき。

2023/03/31(金) 12:57:43.80

>>477
作業ブランチの共有をどのようにするかはチームごとのルールがあるので仲間に確認
プルリクエストを出して取り込んでもらうという運用もあるし、
共有ブランチにプッシュする運用なら、作業ブランチを共有ブランチの先頭に rebase した上でプッシュするのが一般的。

2023/03/31(金) 13:39:22.27

>>480-481
>共有ブランチにプッシュする運用なら、作業ブランチを共有ブランチの先頭に rebase した上でプッシュするのが一般的
この運用だと、複数人での同一ブランチでの作業でも、履歴を1本化できるのですよね。
もちろん、他のブランチでの修正などをマージするときは、履歴として残していくつもりです。

2023/04/05(水) 18:00:34.21

WindowsのSourcetree、起動するたびに右に1ピクセルずつ広がっていくんだけど、おま環？

2023/04/06(木) 18:18:24.64

めっちゃ判りますωωω

2023/04/08(土) 16:07:30.25

Git初心者後輩のrebase童貞とreset童貞
卒業させてやった

2023/04/09(日) 19:33:50.10

>>485
おめ。
次はSquashで大量コミットお化け童貞も捨てさせるチャンスだな。

2023/04/12(水) 16:25:18.28

pushしてPRしてアーッって新境地へ

2023/04/20(木) 22:47:39.66

開発用ML見てたら、git replay　ってのを作ってる人がいる模様。

https://public-inbox.org/git/20230407072415.1360068-1-christian.couder@gmail.com/T/#m982eda816df06532f97ec30be5dda768cea5338f

2023/04/26(水) 19:09:19.52

マージして削除したブランチって、ログの樹形図を見ても、
そのブランチが何という名前だったのかは基本的にわからないものですか？

2023/04/26(水) 19:49:05.13

Git v2.40.1

2023/04/26(水) 19:58:42.13

マージコミットのメッセージがあればそれを信用するしかない

2023/04/27(木) 09:18:11.67

>>491
そういうものなんですか。
Subversionのときは、ブランチの作成自体が1つのコミットで、
ブランチの名前や、どういう作業を始めるのかをログに残しておけたけど、
そのへんの感覚も違うんですね。

2023/04/27(木) 10:53:45.90

>>492
だからマージの時にどのブランチからどのブランチにマージしたのかデブォルトでコミットログに残るでしょ

2023/04/27(木) 21:42:03.12

>>492
subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、
git はブランチが軽くて余計な容量を食わないので百でも千でも好きなだけ切れる。しょっちゅう作ったり消したりできるし、ずっと残しておく事もできる。
そのせいでブランチに対する考え方が違う。必要ならなんで消したの？みたいになる。

2023/04/27(木) 21:51:10.24

>>494
> subversion はブランチの使用が重くて、使える数も実質的にディスク容量とかで制限されてたけど、

んなこたーない。
https://tortoisesvn.net/docs/release/TortoiseSVN_ja/tsvn-dug-branchtag.html
> つまり、リポジトリの完全なコピーを作成する代わりに、指定したツリーやリビジョンを指す内部リンクを作成します。そのため、ブランチやタグの作成は、非常に高速で、リポジトリに追加スペースをほとんど使用しません。

ダメなのはマージの追跡が後付けで非効率なところ。

2023/04/27(木) 22:14:47.72

いい加減なこと言ってないで、実プロジェクトで git と svn のブランチを使い比べてみろ。

2023/04/28(金) 05:15:11.41

Error: explorer.exe not found in PATH の修正来たわ

please note that the latest snapshot has the fix
https://wingit.blob.core.windows.net/files/index.html

2023/04/28(金) 15:09:32.21

svn 屋がいくら cheap copy でコピーが速いって自慢しても、git のブランチ作成はそもそも zero copy なんで比べものにならないんだよな。
設計思想の根本的な違い。

2023/04/28(金) 15:30:18.71

別に Subversion を擁護するわけでも自慢するわけでもないんだけど、少なくともブランチ作成に限れば
どちらも一瞬なんで何を見て「ディスク容量とかで制限されてた」「比べものにならない」とか言ってるのか
わからない。 Subversion 嫌い過ぎなだけなんじゃないかと。

マージはクソなのでそこも含めての話なら「ブランチの使用が重くて」はわかる。

2023/04/28(金) 17:05:37.81

>>499
そこまで言うのなら大きめのプロジェクト、例えば linux のソースコードくらいのやつに git と svn で100個ずつブランチを切って作業時間を比べてみ。当然だが作業コピーも作って1回ずつ作業しろよ。
どっちも一瞬かどうか、自分で体験すれば納得いくだろ。

ディスク容量の話は昔の容量が小さかったころの経験なので、最近の大容量だと問題ないかもだから撤回しとく。

2023/04/28(金) 17:47:03.47

>>500
え？ブランチ作るごとに作業コピー作るってのが意味わからんのだけど？
そんなことしたらどっちでも作業コピー作る時間が圧倒的ネックになって比較の意味も無くなりそうだし。

2023/04/29(土) 10:58:48.12

>>501
使ってないこと丸わかりの馬鹿コメントだな。svnスレに帰れ。
お前は作業もしないのにブランチ切るの？
圧倒的ネックなのは svn だけ。git を巻き込むな

2023/04/29(土) 11:49:10.88

>>502
どういうことなの・・・
git branch x でブランチ作るにあたって作業コピーなんか作らないし、
svn copy ^/trunk ^/branches/x -m "..." でブランチ作ってもそれは同じでしょ。

なんで「当然だが作業コピーも作って」なんて話になるんだ？

2023/04/29(土) 13:24:59.65

>>503
git checkout -b xxx
edit filename
git cimmit -a
が git のやり方

2023/04/29(土) 15:34:03.46

あー >500 の「作業コピーも作って」は「作業コピーを切り替えて」の意味で、
git checkout -b xxx
↑が↓になる違いを言ってたのかな。
svn copy ^/trunk ^/branches/xxx -m "..."
svn switch ^/branches/xxx

git だと切り替え含めてほぼ何もしないからこれでも一瞬だけど、
svn のほうは切り替え含めれば数秒はかかりそうだから 100 も作ればだいぶ違うだろうね。

2023/04/29(土) 17:08:24.97

branch に名前をつけるだけじゃなくて、branch を実際に使うとこまで含めて git は軽々ということ
そしてそれが git 文化の根底にあるので、旧世代の認識で見ると不思議に見えるという話