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/03(火) 01:44:58.77

それは全く逆で、むしろGitHub使える環境の人はGitに対してもGitHubに対しても満足度高いと思うぞ
Git使ってるのにGitHub使ってないというのはだいたい下請業務など劣悪な環境だろうから、Gitに対してもヘイトが集まることになる

2023/01/03(火) 05:34:05.62

ワイはgitには特に何もないが、GitHubには文句たらたらや

2023/01/03(火) 07:04:51.47

マイクロソフトがー、マイクロソフトがー

2023/01/03(火) 17:51:22.90

おまいら、ギフハフって灰汁の組織知ってるか？

2023/01/15(日) 11:41:44.14

ギフハブだぞ
AS*Aさんのセンスでギフハフなんて響きの悪い名前を思いつくわけないだろ

2023/01/18(水) 08:55:28.93

Git v2.39.1 and others

2023/01/20(金) 11:58:28.71

「Git」に3件の脆弱性～修正版のv2.39.1が公開 - 窓の杜
https://forest.watch.impress.co.jp/docs/news/1471256.html

2023/01/22(日) 00:10:04.98

stalmannenってスェーデン語でSuperMan のことなんだって。
だから、あの左翼は頓珍漢なことばかり言ってたのか。

2023/01/23(月) 08:39:01.26

ちょっと教えてください。
a、b、c、d、eとコミットして
bにリセットしたらcdeの修正分はなくなるよね？
最初の状態からcをリバートしたらdのコミット分だけが無くなる？

この時cの修正に依存するd,eの改修箇所はエラー吐きまくるであってますか？

実際のチーム開発でrevertとかそんな使う機会ある？

2023/01/23(月) 08:47:04.02

>>402
ごめん
最初の状態からcをリバートしたらcのコミット分だけが無くなる？
です

2023/01/23(月) 09:17:09.28

>>402
pushしたならrevertしかないから、使ったことはある
>>403
その認識で合ってる

2023/01/23(月) 10:00:41.12

>>404
ありがとう。
cの修正に依存するd,eの改修箇所は
手動で調整するしかない？
だよね？

2023/01/23(月) 10:08:15.27

revertは実際のチーム開発では主にリリース直前や直後に戻すときに使う
途中のコミットだけ戻すのも、リリースにむけて成果をマージしていくメインストリームのブランチの場合は珍しくない
例えば、各自の作業をmainブランチに統合した後にステージング環境で最終確認してて特定の新機能に不具合が見つかったら、その機能のマージコミットだけをmainブランチからrevertしてリリースする
一般的にはそういう統合用のブランチにおいてそれぞれのマージコミットにはあまり依存関係がないから、途中のコミットであっても安全に戻せることが多い

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 はブランチが軽くて余計な容量を食わないので百でも千でも好きなだけ切れる。しょっちゅう作ったり消したりできるし、ずっと残しておく事もできる。
そのせいでブランチに対する考え方が違う。必要ならなんで消したの？みたいになる。