Git 18

2022/04/23(土) 03:25:45.27

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

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

2022/07/28(木) 17:16:34.57

>>407は凄くかっこ悪い

2022/07/28(木) 18:31:06.84

煽り耐性なさすぎだろ…

ところで origin dev というフレーズに意味があると捉えてるのいいのかな
単に<repository>と<refspec>を順に受け取るコマンドが多いだけで、origin dev と oringin/dev を同格の概念だと捉えるのは理解を妨げると思うんだが

2022/07/28(木) 19:32:20.12

>>410
厳密に言えば違うけど、どっちもブランチを指定しているという意味では同格だろ。
ローカルブランチと、リモートブランチを取るコマンドで引数の指定方法が異なると理解しとけば良い。

2022/07/28(木) 20:04:25.84

我流で変な理解をするよりも、上で丁寧にわかりやすく説明してくれてくれてる人が言うようにちゃんとヘルプ見たほうがいいと思うけどね
中級者と本当に詳しい人の差はそこで出ると思う
refspecとは何か、tree-ishとは何かを説明できるかどうかはポイントの一つだと思う

2022/07/28(木) 21:31:34.95

未だにSVNなんか使ってgit使ってないのはやばいなんて言う方がやばいなんて話題になってたんだけどgitに慣れた身からすると
ローカルでコミットできない、ブランチを気軽に切れない、もうそれだけであまりに不便だと思うんだけど、SVNユーザーはこれをデメリットと感じないのだろうか？

2022/07/28(木) 22:20:18.72

gitのことを知らないんだからsvnのデメリットにも気付かないよ

2022/07/28(木) 22:40:17.73

ドカタ開発はもっと理不尽なことがいくらでもあるからその程度は大した問題じゃないんだよ
VCS使ってるだけマシ

2022/07/29(金) 01:55:35.40

>>408
なんで敵視？

2022/07/29(金) 02:26:57.20

デメリットなんて気付くわけないさね
スマホを使ったことがない人はガラケーの劣る点に悩まないし、自動車がなかった時代に初の自動車を見てもこのヘンテコなカラクリ仕掛けが世界を変えるとは考えられない
保守的な人やいつも忙殺されて余裕のない人は損失回避バイアスによって変化のリスクを過大に見積もり現状維持を選ぶし
いよいよ心が老人になると自分の慣習や価値観を否定されたと感じて怒り出す始末

2022/07/29(金) 06:43:18.42

>>413
その2点に慣れてしまうともう戻れないよな
コーディング方法さえ変えてしまうほど便利

2022/07/29(金) 10:26:37.17

>>396
++
tmux最強

2022/07/29(金) 10:28:01.90

>>393-394
判りやすい

2022/07/29(金) 11:55:40.15

CVS使ってた現場で、コミット漏れによる先祖返りで障害が起きた対策として、下記の作業手順が定められた
1. 一切コミットすることなくソースの変更とテストとレビューを済ませる
2. 本番からソースをダウンロードし、ワーキングセットとの差分を取る
3. ワーキングセットを本番にデプロイする
4. CVSにコミットする
もはやバージョン管理とは何なのかと思ったね

2022/07/29(金) 12:45:43.04

>>421
ローカルとかチームではgit使って、サーバーだけcvsにした方が良さそうだな。

**421** (ﾌﾞｰｲﾓ MM9d-vZl0) · 2022/07/29(金) 13:13:28.48

あーちょっと不正確だった。正しくは、1の前に
0. 本番からソースをダウンロードし、CVSとの差分がないことを確認する
が入る。簡単に言えばVCSを一切当てにしないで本番環境にあるソースをマスターにしましょうってことだ。
こんなのCVSかGitかとかいう以前の問題で、ルール決める人間がVCSを理解してないんだからツールを何使おうが絶対に間違えるんだよ。
仮にGit使ってたとしても同じことになってるだろうね。

2022/07/30(土) 04:13:51.24

>>421
cvsがただのソース置き場になってるな
zip管理してるのと変わらん

それで回るのなら、cvsやめてzip管理でええやん

2022/07/31(日) 02:06:31.57

例えばgoogle trendで検索すると日本はgitに対するsvnの比率が世界最上位クラスに高いのが分かる
より良い技術を取り入れていこう勉強していこうってタイプの人が全然いないのかな
そんなものより動く製品作るのが大事だろ、知ってる技術使えばいいだろ、勉強する時間が無駄みたいな

2022/07/31(日) 02:15:39.82

>>425
すまん俺が svn 糞とかでググってるせいだわ

2022/07/31(日) 02:22:27.63

>>421
cvsじゃなくてtfvcだけどまさにそんな感じ
ブランチが開発差分じゃなくて、各モジュールを表すものになってるんだよねうち。メインに共通部品が置いてあるのよ
じゃぁこのブランチで開発してね他の人はいじらないから、みたいなこと最初に言われたとき、お前バージョン管理をなんだと思ってるんだってなったわ
>>424の言う通りだし、そもそも「バージョン管理」って概念自体がよく分かってない人結構いるのかもしれない

2022/07/31(日) 05:29:08.90

>>425
svnを敵視する人はこれだから困る

2022/07/31(日) 15:16:33.83

>>427
テンプレートからフォークしていく運用自体はそんなに珍奇ではないと思うよ
TFVCはよく知らないけどGitほど複数リポジトリに跨った管理が得意とは思えないから、
フォークの際にGitでクローンする代わりにブランチを使うのはまあアリなんじゃないか

2022/08/01(月) 09:23:36.02

Hamano氏のインタビューが載ってる　https://git.github.io/rev_news/2022/07/31/edition-89/

2022/08/06(土) 16:17:32.37

おまえらってgitを使ってなにを管理してんの？
どうせ人には見せれない、クソコードをprivateにして遊んでるだけだよなｗ

2022/08/06(土) 16:19:29.02

確かに見せられないな、機密情報だから
ごめんねー

2022/08/06(土) 22:54:01.88

恥ずかしくてみせないよな
ｗｗｗｗｗ

2022/08/06(土) 22:55:49.69

そんなにみたいなら見せてやるよ
最新作だ
https://github.com/NCNT/TimingCmds_in_POSIX/tree/main/c_src

2022/08/07(日) 06:13:33.06

相変わらずのダサいコードで笑う

2022/08/07(日) 10:36:56.12

>>434
なにこれ？
この程度ものを管理する必要があるのか？
しかも公開してｗｗｗｗ

やっぱり、偉そうにいうわりにはクソみたいなソフトしか作れないんんだろ

2022/08/07(日) 13:36:16.69

>>436
コミケで販売するから文句はそれ買ってから言え。通販もしてるぞ。

あなたのシェルスクリプトに正確な「時」をデリバリー
トキデリ Rich Mikan 著
https://richlab.org/coterie/tok.html

2022/08/08(月) 13:17:15.57

資源の無駄

2022/08/08(月) 13:28:32.63

githubの話はgitスレでしないでくたさーい

2022/08/09(火) 23:25:41.25

githubとgitは別物だぞ

2022/08/10(水) 01:11:45.77

>>440
gitを使ったシステムなんだから別物ではない

2022/08/10(水) 01:28:37.91

え？

2022/08/10(水) 02:07:21.61

DNAと人間は同じだから

2022/08/10(水) 02:47:33.52

repoってgithubとかgitlabみたいなもん？

2022/08/10(水) 07:15:46.58

>>444
ホスティングサービスではなくて、gitを補佐するクライアントソフトらしい
複数のリポジトリを一括で操作できるのが特徴とか
ライブラリが多いとか、扱うリポジトリが多いプロジェクトなんかだと重宝するかも

個人的にはいらんなぁ

2022/08/10(水) 07:45:39.95

自分も会社の業務以外でほとんど使用したことはないな
そもそも個人レベルのプロジェクトで複数のリポジトリ扱うことないし

Android SDKのソース落としてくる時に使ったぐらい

2022/08/13(土) 07:41:00.55

Git v2.37.2

2022/08/13(土) 19:37:20.99

個人レベルでgitを使う必要ある？
そもそも自分ひとりで書いてるなら大抵は覚えてるだろｗ

2022/08/13(土) 20:04:36.06

個人レベルだからこそ簡単に導入出来るgitを使う
別にリモートにpushやらしなくても所々コミットしておけば戻るのも簡単だし
便利だと思うのだけどね
ただバイナリ（excelのファイル)みたいなのには使わないが

2022/08/14(日) 02:14:02.08

新機能を実装する時は、変更前のソースを参照できるようにしておかないと面倒。

バグが発生したときは差分をすぐに参照できるようにしたいしな。

2022/08/14(日) 02:16:52.49

>>448
ローカルリポジトリだけでも完結できるのにgitをわざわざ忌避する理由がない

2022/08/14(日) 13:58:00.56

>>448
数万行のコードなんて覚えてられない
どうせおまえがやってるのは100行以下のサンプルコードだけだろｗ

2022/08/14(日) 15:10:31.19

>>452
どうせ公開できないんだろｗ
何とでもいえるわなｗｗｗ
俺なんてカーネル開発してるよ

2022/08/14(日) 15:48:56.36

>>453
たった数万行に驚いてるのか？

2022/08/14(日) 16:47:19.54

そもそも描いたこと無いからイキれるんだな

2022/08/15(月) 19:27:14.17

一日100行でも一年経てば20000行

2022/08/15(月) 20:10:11.85

svn脳の人はローカルリポジトリの概念がないからvcs使うことを大層に考えてしまうんだよな

2022/08/15(月) 20:22:20.12

リモートリポジトリが要らないというのは革命的だと個人的には思うけど、あんまりそういう話は出てこないよね。

リモートリポジトリ無しってgit登場時点で普通の話だったっけ？

2022/08/15(月) 21:27:50.09

リポジトリーのローカルコピーも含めてGitの機能的な部分はBitKeeperから持ち込まれたものだろ

2022/08/15(月) 22:34:37.88

>>458
SCCSとかRCSとか。

2022/08/15(月) 23:18:53.39

Gitの開発経緯を考えるとリモートリポジトリの存在はむしろ超大前提で、ローカルだけで使えるのは副産物みたいなもんでしょ
まあリモートと言ってもGithubみたいな中央集権型ではなくて、無数のリモートリポジトリがあってパッチを送り合うような開発スタイルが本来のGitの姿

2022/08/16(火) 01:17:15.07

https://ezoeryou.github.io/blog/article/2015-04-08-linus-git-interview.html
gitの10周年を記念したLinus Torvalsへのインタビューの翻訳

＞しかし、BitKeeperがやってきてからというもの、ソース管理に対する見方が変わったね。
＞ BitKeeperは大抵のことを正しく行っていた。
＞レポジトリのローカルコピーがあることと、分散マージはでかかった。

2022/08/16(火) 23:52:04.96

>>448
gitに限らんけど、VCSって個人レベルでも機能追加とバグ修正並行して進める時は楽だ

2022/08/18(木) 11:54:41.84

gitとgithubの区別がついてないんだろ

2022/08/25(木) 00:47:44.66

初歩的な質問になるけれど…
異なるローカルブランチ「debug」と「genbug」が存在する。
両方のブランチに全く等しい「iam.txt」と「whoyou.txt」いうテキストファイルがあって、
どちらのテキストファイルも両ブランチの最新コミット内に存在するものとする。
「Iam.txt]の中身は"I am a dog."

「debug」ブランチで【rm whoyou.txt】と打って「whoyou.txt」を削除し、「Iam.txt」の中身を"I am a cat."に変更してステージングをしないまま、
【git checkout genbug】と打って「genbug」ブランチに切り替え、ワークツリーを確認してみると、「Iam.txt」の中身は"I am a cat."に変更されているのに、
「whoyou.txt」は削除されていない（というより復活している）。
これはなぜなのだろうか？（whoyou.txtをgitリポジトリから消したいならrmコマンドではなくgit rm --cachedを使うべきなのはわかる）

いまいち、git checkoutをしたときのワークツリーの挙動が掴めない

2022/08/25(木) 02:38:58.44

「git checkout ブランチ」するとき、

checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる

つまりIam.txtが変更されているのは正しいが、whoyou.txtが復活するのは何か操作を勘違いしていると思う

ちなみに、
checkout前のブランチとcheckout後のブランチにコミットされているファイルが等しく無い場合、
checkoutすることでcheckout後のブランチにコミットされているファイルへ置き換わるが、
checkout前のブランチにおいてワークツリー上でそのファイルを編集や削除していると、
checkoutが失敗する

2022/08/25(木) 02:40:02.58

$ git status -sb
## debug
$ ls
iam.txt whoyou.txt
$ cat iam.txt
I am a dog.
$ echo "I am a cat." > iam.txt
$ rm whoyou.txt
$ git status -sb
## debug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.
$ git checkout genbug
M iam.txt
D whoyou.txt
Switched to branch 'genbug'
$ git status -sb
## genbug
M iam.txt
D whoyou.txt
$ ls
iam.txt
$ cat iam.txt
I am a cat.

2022/08/25(木) 10:19:53.57

>>466-467
whoyou.txtが復活するのは勘違いしていたみたいすまん
「checkout前のブランチにおけるワークツリー上でのファイルの編集や削除は、
checkout前のブランチにコミットされているそのファイルとcheckout後のブランチにコミットされているそのファイルが等しい場合、
checkout後のブランチにそのまま引き継がれる」
こんな仕様があったのか。知らなかった。ありがとう。

ワークツリー上で行った操作をなかったことにしたい場合「git checkout .」で良いと思うんだけど
ワークツリー上で行ったgit操作履歴（というかローカルリポジトリへのコミット内容との差分）を確認する方法ってないのかな

2022/08/25(木) 11:07:47.22

>>468
ワークツリーでの操作に関しては履歴は残らない
カレントブランチにコミット済みとワークツリーとの差分については、上でもやってるけどgit statusや、git diffでもできる

git diff # 差分の内容を表示
git diff --name-status # 差分があるファイル名とそのステータスを各1行で表示
git status # 差分があるファイル名を含めたワークツリーの状況を詳しめに表示
git status -s # 差分があるファイル名とそのステータスを各1行で表示
git status -sb # ブランチ名を表示した下にgit status -sと同じものを表示

2022/08/25(木) 11:08:10.42

git status -v
とかじゃダメなのか？

2022/08/25(木) 11:14:51.48

git status -vは-v無しと同じかな？
毎回git statusやると表示がうっとおしいので、git status -sbの方をシェル関数でgstに定義して良く使ってる
git status -vはmergeやrebaseが失敗したときに見る

2022/08/26(金) 18:45:49.38

たかだかpushするだけなのに、ターミナルからやった方がエモいですか？

2022/08/26(金) 19:07:22.83

エモいと言う言葉の意味がわからない

2022/08/26(金) 19:30:50.57

>>472=>>407

2022/08/27(土) 07:34:04.59

エモいかどうかは知らんけど、ターミナルの方が便利

2022/08/30(火) 12:28:50.29

興味本位でインストールしたけど、そもそも履歴を管理しなきゃいけないようなものが、個人にはないこと気づいてほったらかしwww

2022/08/30(火) 23:04:23.35

まあ、プログラマーくらいしか使わんかも
事務の人とか使ってるんかな？

2022/08/31(水) 08:44:21.38

ファイル名で管理していて最新版がどれかわからんっていうネタはよく見るけど、最新版を追うためだけにVCSを導入するところは少ないでしょ

2022/08/31(水) 08:46:09.80

Git v2.37.3

2022/08/31(水) 12:34:16.47

>>478

最新はタイムスタンプ見れば一目瞭然だろ
パソコン初心者かよw

2022/08/31(水) 15:08:11.70

タイムスタンプω
パソコン初心者かよωωω=2πf

2022/08/31(水) 15:34:18.76

gitがメジャーになったおかげで、ソースコードのタイムスタンプにゴチャゴチャ文句付けるオジサンを駆逐できて良かった

2022/08/31(水) 16:40:45.15

あと、扱うファイル形式的にも難しそう

>>482
どういうこと？昔はタイムスタンプで何か言ってくる人がいたの？

2022/09/01(木) 01:20:40.38

>>481
涙拭けよ

2022/09/01(木) 02:02:37.38

タイムスタンプみたいな信用できないものに依存するなよ

2022/09/03(土) 12:08:05.86

https://github.com/zhlynn/zsign
これをビルドするのにMSYS2を入れて、git clone git@github.com:witwall/mman-win32とやったら、git@github.com: Permission denied (publickey).になっちゃったんですけど、githubのアカウントがないとダメなんでしょうか？

2022/09/03(土) 12:50:36.25

git clone github.com:witwall/mman-win32

2022/09/03(土) 12:56:48.05

>>486
SSH接続はアカウント作って鍵を登録する必要がある
git@github.com: → https://github.com/
に読み替えてhttpsでやればいい

2022/09/03(土) 15:32:09.11

>>488
ありがとう

2022/09/04(日) 18:01:40.46

情報系卒ではじめて業務でgit触ったんだけど、これbranch newFunc -u みたいな感じで
origin/newFuncみたいなの脳死で追跡するように設定しちゃってもいい？
このコマンド一度打っておけば。そのブランチにpushするときいちいちoriginって入れなくてもよくなる
くらいの認識でしかないんだけども

2022/09/04(日) 18:03:08.45

日本語下手すぎたから書き直します
情報系卒の1年目で、最近はじめて業務でgit触ったんだけど、これ「git branch newFunc -u」で
origin/newFuncをup-streamに設定しちゃってもいい？
このコマンド一度打っておけば、そのブランチにpushするときいちいちoriginって入れなくてもよくなる（originが省略できる）
くらいの認識でしかないんだけども

2022/09/04(日) 18:09:17.04

いいよ
間違ったとこにpushすることを防げる

2022/09/05(月) 00:07:59.17

おとなしくGUI使えよ

タイプするのが面倒で、間違ってpushなんてしてるようならｗｗｗ

2022/09/05(月) 01:29:30.11

>>493
push先を間違うのは頭の中の段階なので何UIでも関係ないです

2022/09/05(月) 01:33:50.45

>>494
論破しましたね

2022/09/05(月) 12:14:03.67

論破ww
久々に聞いた、平成かよw

2022/09/05(月) 14:19:44.96

ﾃﾃﾝﾃﾝﾃﾝがこうも粘着してgitのコマンド入力に憎しみを向けるのも過去に完全論破されたのがよっぽど悔しかったんだろうな

2022/09/05(月) 16:50:12.49

ローカルブランチのソースコード中の
コメントアウトしてある説明とかの修整って
気付いたときに、いちいちコミットしてる？
それともstashとかにまとめといて後で一気にやる？

2022/09/05(月) 18:08:18.48

別にこまめに修正してコミットしても良いのでは？
何かルールでもあるの？

2022/09/05(月) 19:17:05.40

>>499
ルールは無いよ
ただどうでもいいとこで無用にログが膨らむけど
皆は普段どうしてんだろ？って思って書いてみた

2022/09/05(月) 20:13:32.62

気が向いたらコミットしといてpushする前にsquashで複数コミットを1個にまとめる

2022/09/05(月) 23:32:13.90

気楽に思いつくままコミットして、ゴチャつきが気になったら後で rebase -i で美化運動する

2022/09/10(土) 14:36:31.13

>>491
originしかないような状況ならまず困らないからOK
2つ以上のリモートリポジトリにpush/pullしたくなったら、ユースケースでデフォルトに設定するかその都度考えて打った方がいいか考えればok

2022/09/10(土) 17:37:58.38

.gitattributesで.rcファイルをUTF-16LE-BOMに指定してから、git cloneした時にエラーが発生するようになりました
書き方が間違ってるのでしょうか？
>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM

.editorconfig
------------------
root = true

[*]
end_of_line = crlf
charset = utf-8
indent_style = space
indent_size = 4
trim_trailing_whitespace = true
insert_final_newline = false

[*.rc]
charset = utf-16
------------------

.gitattributes
------------------
*.rc working-tree-encoding=UTF-16LE-BOM eol=CRLF

2022/09/10(土) 17:55:34.66

>error: failed to encode 'resource.rc' from UTF-8 to UTF-16LE-BOM
これが理由じゃないの？

そもそも、UTF-16LE-BOM を使う事ってある？

普通は、BOM 無しUTF-8 を使う

2022/09/10(土) 18:08:59.50

>>505
Visual Studioを使ってるのでUTF-16LE-BOMかShiftjisの二択なのです
resource.rcはUTF-16LE-BOMで保存してあります

2022/09/10(土) 18:17:08.28

>>505
使う理由があって使ってんのに難癖はやめとけ

2022/09/10(土) 19:58:42.22

>>504
リモートとのやり取り時に指定文字コードとUTF-8を相互変換するんだから.rcファイルpushし直さないとだめじゃね？