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/26(火) 19:34:51.51

いやよく読もう

> いちいちターミナル立ち上げてタイプしてる人は何？
> しかもタイピングが遅いからまどろっこしくて仕方ないw

タイピングが遅いはどう考えても一般論じゃないんだから、身近にそういう変わった人がいるという質問風の愚痴だろ
「ほーん、で？」「それは大変だったね」「しらんがな」とか答えてあげるかスルーすればいい案件

2022/07/26(火) 19:38:48.45

特定の誰かがタイピング遅いから全員gitコマンド使うなという主張だよ

2022/07/26(火) 19:42:06.64

被害妄想じゃね

2022/07/26(火) 19:43:23.18

いちいちターミナルを立ち上げって書いてあるけど、普通ターミナルなんて立ち上げっぱなしだよなあ

2022/07/26(火) 19:49:04.16

開いてあるターミナルでコマンド履歴を呼び出したり git switch - 打ったりはコマンドが早いな
エイリアスがあればさらに早い

そのタイピングが遅い人はgitの練習かタイピングの練習がしたいんじゃね

2022/07/26(火) 19:56:26.38

>>390
はい。わたしは>>381には、リモートブランチとリモート追跡ブランチが同じ意味で書いてます。

前半は自分にはわからなかったです。
どのorigin/devが、logのorigin/devと同じと言っているんだろう。
origin/devは普通.git/refs/remotes/origin/devの省略形として使われるのであって、
git logの引数の説明に、refspecとかrevisionとか書いてあったらそうだろうと思います。
自分はそういうつもりで使ってますが、ちゃんと知りたいなら調べてみたらどうでしょう？
文脈によっては.git/refs/heads/origin/devかもしれないですね。これは難癖ですが。（つまりorigin/devっていう名前のローカルブランチ。でもコマンドミスで、たまに作ってしまう…）

2022/07/26(火) 19:59:34.56

>>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。

2022/07/26(火) 20:52:33.24

>>399
ああ、そういうことですか。腑に落ちました。
仰るとおり、一つの言葉の意味を一つに定めようとしていました。
origin/devといっても脈絡次第でそれが何の略であるか、いくつか解釈パターンがあるんですね。

原著はgit-scm.com/docｓ/であってますか？
tagやcommit等を調べるときはこのページを利用しました。
このスレの皆さん、リモート追跡ブランチが何であるかを理解した時も原著を参照されたのですか？
書籍等でわかりやすく日本語でまとめられた情報等は購入されていないのでしょうか？
参考までに教えて頂けると助かります。本当は自分でわからないことをすべて調べられるのなら理想なのですが
まだその段階には至っていないようです。

2022/07/26(火) 21:27:22.81

>>400
用語はそのurlからgitglossaryで検索すると見れます。
というか、コマンドラインからgit help gitglossaryで、使ってるバージョンのヘルプページが開きます。
この中を、remote-tracking branchをページ内検索すればリモート追跡ブランチの説明があります。

あと、git help gitで、使えるコマンドの大枠が見れます。

本については、10年以上前ですが自分はjunio c hamanoが書いた本で学びました。日本語です。その後3冊買いましたが、最初ので十分でした。
オンラインで無料で読めるやつならpro gitが一番読みやすいと思います。日本語訳があります。
ただしこれはツールとしての使い方が主です。

2022/07/26(火) 21:35:13.51

>>401
ProGit後半の方には内部実装に踏み込んだ説明もあるので、あなたの知りたいことは、こちら寄りかもしれません。
多くの人は、ツールを一般的なユースケースで使えればいいのであって、origin/devとorigin devはどう違うのか、といった疑問は感じないか、もしあってもすぐに忘れます。

origin/devとorigin devの違いだけを知りたい場合はすでに説明したとおりです。
でも更に疑問が出てくると思います。

あなたの疑問は、定義をしっかり知ったほうが理解につながるものだと思うので、地道にヘルプなどのドキュメントをたくさん読んで、自分の頭で探し方を学んだほうがいいものだと思います。

2022/07/26(火) 23:28:02.96

commitはメッセージが改行付きで長めになるのでGUIでやってるｗ
status,checkout,push,pull,mergeみたいなのはコマンドラインでやってるなぁ

2022/07/27(水) 00:32:02.65

commitコマンド実行したときにエディタ立ち上がるようにしてないの？

**デフォルトの名無しさん** (JP 0H8b-kbwT) · 2022/07/27(水) 02:00:04.13

環境依存な話ですが、Macでターミナルからgit difftoolした時に外部diffビューアを立ち上げ
たいのですが、皆さんどうしてますか?

ググってopendiff (-> FileMerge)を呼ぶ設定にしてみたのですが、複数の変更ファイルが
あるとき、FileMergeが2番目以降のファイルを開いてくれません

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

呼び方が混乱してるのかも。通常の使い方だと、以下の通り。
origin dev 「リモートブランチ」、 origin という名前のリポジトリ上にある dev という名前のブランチ。
origin/dev 「リモート追跡ブランチ」、origin/dev という名前のローカルブランチ、上記のリモートブランチを追跡するように設定されている。
dev 「追跡ブランチ」、dev という名前のローカルブランチ、上記のリモート追跡ブランチ(origin/dev)が上流に設定されている。

（注:あくまでデフォルトなので変えることはできる…）

2022/07/28(木) 16:29:18.98

ターミナルにコマンド入力してのがかっこいいと思ってる人いる？

2022/07/28(木) 17:09:52.93

>>407==>>387
どんだけコマンド敵視してんだよ

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することを防げる