Git 17

**デフォルトの名無しさん** · 2020/09/02(水) 12:18:30.39

ソースコード管理を行う分散型バージョン管理システム、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 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/
Git 16©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1502726047/
-
VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2020/10/04(日) 08:12:16.77

ありがとうございます
ファイル等gitオブジェクトはSHA-1で格納されているらしいということまではわかったのですが
受信時にこれを使ってベリファイしてるんでしょうか

**デフォルトの名無しさん** · 2020/10/04(日) 10:48:37.02

SHAで格納とかいう時点でエラーチェックについて全くわかっていない。
チェクサムかパリティビットから勉強しろ。

**デフォルトの名無しさん** · 2020/10/04(日) 12:42:13.02

横だけど、同一性のためのチェックはSHA-1で、ってことでしょ。

**デフォルトの名無しさん** · 2020/10/04(日) 13:06:56.18

いまファイルを編集中でコミットしたくないんですけど
別件で修正依頼が来たのでそれの修正をしてそれだけコミットし、編集してた状態に戻すまでのコマンドを１から教えてください

**デフォルトの名無しさん** · 2020/10/04(日) 13:21:30.23

git stashしとけば？

**デフォルトの名無しさん** · 2020/10/04(日) 13:26:43.51

>>25
すみません書き方が悪かったです
SHAハッシュ値をフォルダ名とかファイル名にして格納してるという意味でした
詳しそうなのでgitが同一性の確認をどのように行っているのかご教示いただけませんか

**デフォルトの名無しさん** · 2020/10/04(日) 13:37:46.47

>27
git stash save
他の作業
git stash apply

でもなコミットを忌避する理由は無い。
gitはコミットを編集できるから作業はとにかくブランチでやってバンバンコミットしてamendとかrebaseとかsquashとかresetする方が良い。
stashだって無名のブランチみたいなものだぞ。

**デフォルトの名無しさん** · 2020/10/04(日) 13:52:04.81

横からだけど
master で作業中
git stash save
他の作業 (branch B を造ったとして)
git stash apply
ここで master に戻るんじゃなくて B の続きでってどうするの？

**デフォルトの名無しさん** · 2020/10/04(日) 13:59:36.00

>>29
SHAハッシュ値をフォルダ名とかファイル名にして格納するのだから、格納するときにチェックすればいいだろ
実際にチェックするタイミングは臨機応変だよ
新規ファイルをコミットするときにはそのファイルのハッシュ値でフォルダ名やファイル名決めるのだから自然と一致するし
ファイルを上流からfetchしてきたときはファイルと一緒にハッシュも一緒にダウンロードするだろうからそこでチェックできる
git fsck みたいなコマンドで手動で強制的にチェックすることもできる

**デフォルトの名無しさん** · 2020/10/04(日) 14:07:50.26

>>31
stashのapplyやpopは、saveしたブランチでなくてもできるよ
必要ならマージしてくれるし、当然コンフリクトもする

**デフォルトの名無しさん** · 2020/10/04(日) 14:15:56.74

stashですねありがとうございます

**デフォルトの名無しさん** · 2020/10/04(日) 14:29:25.50

>>29
どのプロトコル使っても整合性チェックすると思う。もしかしたらGit Internalに書いてあるかもしれないけど、どうしてそれを思ったの？webブラウザ使ってるときにデータが欠けてるか気になる？

**デフォルトの名無しさん** · 2020/10/04(日) 15:28:09.43

>>32
ありがとうございます参考になりました

>>35
本来の用途と違いますが簡易的なファイルバックアップ目的で使えるかなと思いまして
これだけ使われていてデータ化け等のトラブルを聞いたことがないので
何らかの同一性をチェックする仕組みがあることは予想できましたが具体的に仕組みを知っておきたかったのです

**デフォルトの名無しさん** · 2020/10/04(日) 15:36:37.25

あとは自分でソースコード読んで調べます
お世話になりました

**デフォルトの名無しさん** · 2020/10/04(日) 19:47:03.49

いやだからSHA-1が何か知っていれば十分。
gitのソースなんか常識的なことしかやってない。

**デフォルトの名無しさん** · 2020/10/04(日) 22:04:42.04

そもそも差分で保持していることすら理解できてなさそう

**デフォルトの名無しさん** · 2020/10/04(日) 22:31:26.82

くすくすｗｗｗ
差分で保持してないのにｗｗｗ

**デフォルトの名無しさん** · 2020/10/04(日) 22:32:10.07

差分で保持？Subversionあたりと勘違いしてそう

**デフォルトの名無しさん** · 2020/10/05(月) 11:01:00.98

バイナリ弄くって中身を直接改竄したらどこで気付けるの？
githubにプッシュする段階で弾かれる？

**デフォルトの名無しさん** · 2020/10/05(月) 15:29:49.38

簡単に試してみると
status チェックしない
checkout チェックしない
diff チェックしない
clone チェックしない！
pull チェックする
fsck 当然チェックする

**デフォルトの名無しさん** · 2020/10/05(月) 21:05:37.85

すまん、SVNと勘違いしてた
スナップショットだったな

**デフォルトの名無しさん** · 2020/10/05(月) 21:41:45.15

ウソつけ。知らんかったんだろ。無知

**デフォルトの名無しさん** · 2020/10/06(火) 04:17:10.72

無知の血

**デフォルトの名無しさん** · 2020/10/06(火) 07:28:16.44

>>43
チェックしたかどうやって調べたんですか？

**デフォルトの名無しさん** · 2020/10/06(火) 08:57:57.90

>>47
status
エラーが出ない。改竄されて無いかのような結果を返す
checkout
エラーが出ない。改竄されたファイルをcheckoutできる
diff
エラーが出ない。改竄されたファイルとの差分が表示される
clone
エラーが出ない。改竄された状態のままクローンされる

**デフォルトの名無しさん** · 2020/10/06(火) 10:05:38.72

Git v2.29.0-rc0

**デフォルトの名無しさん** · 2020/10/06(火) 22:52:44.68

>>48
cloneでチェックしないのは驚き。
pullするまでわからないの？
pullとfsckはどんなエラーが出るんです？
pushはさすがにチェックするよな？リモートレポジトリ壊れちゃうぞ

ちなみにblobを改ざんしたんだよね？
treeやcommitと整合取れなくてエラーが出るってことなのかね？エラーはどこで検知されるんだろう。

**デフォルトの名無しさん** · 2020/10/06(火) 23:05:14.47

>>50
blobのオブジェクトの中身を改竄
ファイル名のハッシュ値と中身が一致しない旨のエラーが出る
clone も pull も同じファイルシステム上で試して、pullだけエラーになった
ネットからのcloneならもしかしてエラーが出るかもね

**デフォルトの名無しさん** · 2020/10/08(木) 12:02:31.68

gitのコマンドで、ファイル毎のコミットハッシュを一括で取得するようなコマンドはありますか？

**デフォルトの名無しさん** · 2020/10/08(木) 12:30:19.52

git status
git log

**デフォルトの名無しさん** · 2020/10/08(木) 14:21:22.99

git rev-list ブランチ名 -- ファイル名

**デフォルトの名無しさん** · 2020/10/10(土) 02:00:17.61

Git v2.29.0-rc1

**デフォルトの名無しさん** · 2020/10/10(土) 12:26:46.20

Git v2.26でプロトコルバージョン2がデフォルト
↓
Git v2.27でプロトコルバージョン2が非デフォルトに
↓
Git v2.29でプロトコルバージョン2が再度デフォルトになる予定

**デフォルトの名無しさん** · 2020/10/11(日) 14:13:58.25

プロトコルバージョンが2になるとなにがよくなるんでしょうか？

**デフォルトの名無しさん** · 2020/10/11(日) 17:40:18.92

おそらくGitHub特有の相談になるんだけどここでいいかな？

全体としては公開リポジトリなんだけど
ある理由（ライセンス制限、期日まで非公開にしておきたいデータ等）により
特定のファイル(secret.txt)もしくはディレクトリ(SecretFiles/)のみ非公開にしたい。

・【必須】バージョン管理はしたい

・全体と非公開ファイルは一体であり、非公開ファイル単体では意味をなさない
・開発中は公開/非公開を意識したくない

こういうとき、どういう方法を取ることが多いでしょうか

**デフォルトの名無しさん** · 2020/10/11(日) 17:53:58.19

>>58
非公開のファイルは別リポジトリに分離してgit submoduleで参照するのはどうだろう

**デフォルトの名無しさん** · 2020/10/11(日) 21:09:04.26

ありがとう
ただ、（必須条件ではないとはいえ）この２つが気になってる

> ・全体と非公開ファイルは一体であり、非公開ファイル単体では意味をなさない
> ・開発中は公開/非公開を意識したくない

**デフォルトの名無しさん** · 2020/10/12(月) 09:46:45.59

submodule に ++

**デフォルトの名無しさん** · 2020/10/12(月) 11:49:56.98

英語のフォーラムとかも漁ってみたけど
「submodule、ただしお前さんの開発のフローに合致するかどうかは知らん」
って感じみたいね

下手すると1ファイルだけのリポジトリとか
作る羽目になりそうだけど仕方ないか…

リポジトリ本体とサブモジュールでコミットの足並みをそろえたり
本体のコミット履歴にサブモジュールのそれを流し込んだり出来るものなのかしら？

**デフォルトの名無しさん** · 2020/10/12(月) 12:54:08.38

全部非公開にすればいいだけじゃん

**デフォルトの名無しさん** · 2020/10/12(月) 16:03:23.63

そもそも足並み揃えなきゃいけない理由がわからない
2つのリポジトリから取ってくるじゃダメなのか

**デフォルトの名無しさん** · 2020/10/12(月) 16:48:06.10

足並み揃ってることが大事なら
sub の方にバージョン番号も入れておいて
main の方は sub のバージョンが正しいかどうか確認して動作する構成にしたら医院で内科医

**デフォルトの名無しさん** · 2020/10/13(火) 15:53:28.21

>>64
ライブラリなり単独プロダクトなり論理的に分割できるものではなく
本来であれば他ファイルと一緒に管理するべきものって前提ね

具体的な方法はともかく
本リポジトリのコミットAのタイミングで、サブ内のファイルBが更新された
というのが追えるのが望ましいかなと

>>65
あー、なるほど
バージョン番号というよりはコミットハッシュのほうが良いかもしらん
やったことないけど多分自動化出来るだろうし

**デフォルトの名無しさん** · 2020/10/15(木) 17:38:16.60

Yahooとかamazonみたいな巨大なサイトって1つのリポジトリでWebサイトのソースコードを管理しているのでしょうか？

**デフォルトの名無しさん** · 2020/10/16(金) 09:51:57.07

GAFA: Google Apple Facebook Amazon

Yahoo Microsoft Twitter Mercari LINE

**デフォルトの名無しさん** · 2020/10/16(金) 09:56:14.58

googleはgitじゃないけど1つのリポジトリで全てを管理してるんだよな

**デフォルトの名無しさん** · 2020/10/16(金) 10:40:11.28

googleの巨大リポジトリはgitを改造して作ってるんだろ。
っていうか、そのためにHamano氏が雇われてると予想してるんたが。

**デフォルトの名無しさん** · 2020/10/20(火) 09:00:10.89

Git v2.29.0

**デフォルトの名無しさん** · 2020/10/22(木) 18:03:28.49

lan内、複数人、全部windowsマシンの環境で、vssからgitにしようとしてまっす
結局、gitサーバーって必要なの不要なの
bareレポジトリを共有フォルダにすればいいだけでっすか

**デフォルトの名無しさん** · 2020/10/22(木) 18:09:00.63

認証とLFS使わないならそれでOK

**デフォルトの名無しさん** · 2020/10/22(木) 18:34:07.73

local で運用したいなら
git と ssh のみで ok

**デフォルトの名無しさん** · 2020/10/22(木) 18:47:15.24

共有しないならローカルだけでgitを使うのもいいよ。

文書作成とかローカルgit重宝するんだけど、あんまり流行らないよね。

**デフォルトの名無しさん** · 2020/10/22(木) 22:44:35.80

コードレビューしないなら別にホスティングいらないんじゃね

**デフォルトの名無しさん** · 2020/10/22(木) 23:45:51.43

文書ならSubversionの方が使いやすい
Gitはサブディレクトリをチェックアウトできないのが致命的

**デフォルトの名無しさん** · 2020/10/22(木) 23:58:01.66

>>77
何を言ってるんだ？

**デフォルトの名無しさん** · 2020/10/23(金) 00:09:06.10

自然文書じゃマージしようないし、Gitの設計は根本的に当てはまらなくなるな

**デフォルトの名無しさん** · 2020/10/23(金) 00:14:27.37

>>77
これは恥ずかしい

**デフォルトの名無しさん** · 2020/10/23(金) 00:30:18.55

どっちみちマージできないんだからロックした方がマシだわな

**デフォルトの名無しさん** · 2020/10/23(金) 00:32:51.98

GitはWordExcelファイル管理してるとすぐにリポジトリ肥大化する問題もある

**デフォルトの名無しさん** · 2020/10/23(金) 00:35:30.46

LFS使えよ

**デフォルトの名無しさん** · 2020/10/23(金) 00:44:21.72

ファイルサーバ的な使い方だと、フォルダ単位のアクセス制御とかファイルロックとかでSubversionが使いやすい
Gitみたいなスナップショットで管理する設計は大規模な非ソースコード管理には向かない

**デフォルトの名無しさん** · 2020/10/23(金) 01:07:17.43

>>79
章の追加とかマージできる

**デフォルトの名無しさん** · 2020/10/23(金) 01:17:30.12

自然言語はプログラミング言語と違って構造化されてないからね

**デフォルトの名無しさん** · 2020/10/23(金) 01:18:27.98

自然言語は構造化されてないが
ドキュメントは構造化されてる

**デフォルトの名無しさん** · 2020/10/23(金) 02:08:07.70

文章も markdown みたいなテキストベースで書いて git で管理すると極楽だよ

**デフォルトの名無しさん** · 2020/10/23(金) 04:36:31.18

日本語だとか英語使う以上どうにもならん
それよりも、markdownって糞面倒くさい
リストの先頭にスペース4個だ8個だ、1. 1. 1.でナンバリングとかいかれてる
リンク貼るのは面倒だし、テーブル書くのは悪夢だし、slackがmarkdown止めたのも納得
wiki記法でもasciidocとかマシな選択肢他にある

**デフォルトの名無しさん** · 2020/10/23(金) 07:12:39.30

フォーマットの良し悪しはどうでも良いよ
問題は普及してるかどうか
客先とかにメールで躊躇なく送れるフォーマットでないと使わない

gitで管理するためにテキストベースならありがたいが、優先度は低い

**デフォルトの名無しさん** · 2020/10/23(金) 08:15:21.01

>>90
pandoc で word に変換して送る

**デフォルトの名無しさん** · 2020/10/23(金) 08:39:21.85

>>91
それって、wordフォーマットで貰って加筆して送り返す場合も、元の書式が完全に再現されるの？

**デフォルトの名無しさん** · 2020/10/23(金) 10:44:04.26

pandoc での変換は word への一方通行だよ

**デフォルトの名無しさん** · 2020/10/23(金) 14:14:34.98

「Git for Windows 2.29.0」が公開～セットアップ時にデフォルトブランチ名を設定可能
https://forest.watch.impress.co.jp/docs/news/1284871.html

「Git for Windows」ではこれに加え、“git init”コマンドで利用されるデフォルトのブランチ名をインストーラーで設定できるようになった。
「Git」の開発チームはデフォルトのブランチ名を従来の“master”から“main”に変更する意向で、「Git for Windows」もそれに追随する構えだ

**デフォルトの名無しさん** · 2020/10/23(金) 14:37:03.75

ぶっちゃけ日本人としてはmaster（ご主人様！）でもmainでも
どっちでもいいんだが、gitが変えるならmainでいいとして
masterとmainを同一視する機能作らないの？
エイリアスブランチとかいう名前にしてさ、どちらからでも同じようにpullできる

**デフォルトの名無しさん** · 2020/10/23(金) 17:08:42.32

sub : 私を差別するなニダ

**デフォルトの名無しさん** · 2020/10/23(金) 22:17:05.16

>>95
エイリアスを作る意味がわからん

**デフォルトの名無しさん** · 2020/10/23(金) 22:22:38.51

>>97
互換性が保たれる
各自好きなときに変更を入れられる
誰にも影響がない

**デフォルトの名無しさん** · 2020/10/23(金) 22:27:37.90

え？何と何の互換性の話してんの？

**デフォルトの名無しさん** · 2020/10/23(金) 22:35:42.31

ブランチなんだからブランチ操作のときの互換性に決まってんだろ
アホかｗ

**デフォルトの名無しさん** · 2020/10/23(金) 23:36:08.41

さっぱり目的がわからん

**デフォルトの名無しさん** · 2020/10/23(金) 23:38:51.83

mainにする必要を感じないユーザーは今後もmainを使い続ければいい
互換性の上で何も困らない
上司が新しいブランチをmainで作りやがったけどオレはmasterが慣れてるんだ！オレの快適のために便利機能を開発しないGitはクソ！とか言い出したら立派なクレーマー

**デフォルトの名無しさん** · 2020/10/23(金) 23:40:11.79

書き間違えた
×今後もmainを使い続ければいい
◯今後もmasterを使い続ければいい

**デフォルトの名無しさん** · 2020/10/24(土) 01:13:36.48

gitは分散システムだって理解してるかな

**デフォルトの名無しさん** · 2020/10/24(土) 05:51:47.10

>>102-103
な？そういうときにmainとmasterがエイリアスの関係になってれば
問題は全く起きないやろ

**デフォルトの名無しさん** · 2020/10/24(土) 07:10:13.82

Git v2.29.1

**デフォルトの名無しさん** · 2020/10/24(土) 08:23:49.45

>>105
誤字は訂正すりゃ済む話だろ
誤字の責任をGitに転嫁し始めたらお前と同じだが

自分が欲しいと思い付いたものは皆欲しいに違いないし
それを提供する大人は疑い無く奉仕すべきってのは子供の発想

**デフォルトの名無しさん** · 2020/10/24(土) 09:59:23.62

まあエイリアス機能はもうあるけどな
https://git-scm.com/docs/git-symbolic-ref

**デフォルトの名無しさん** · 2020/10/24(土) 12:14:42.80

>>107
誤字の話なんかしてないけど、どっから持ってきた（笑）

**デフォルトの名無しさん** · 2020/10/24(土) 20:00:28.27

>>105
誤字の話じゃないとすると、「問題」ってどういう状況のことを言ってるの？

**デフォルトの名無しさん** · 2020/10/24(土) 20:03:07.32

> 上司が新しいブランチをmainで作りやがったけどオレはmasterが慣れてるんだ！

ここに決まってるだろ

エイリアスがあれば上司はmainを使えるし
オレはmasterを使える
何も意識せずにだ

問題解決

**デフォルトの名無しさん** · 2020/10/24(土) 20:07:50.61

>>111
リモート oritin/main に対してローカル master で作業すれば問題ないのでは？

**デフォルトの名無しさん** · 2020/10/24(土) 20:08:10.41

s/oritin/origin/

**デフォルトの名無しさん** · 2020/10/24(土) 20:13:40.11

>>112
だからその作業をユーザーにやらせるなってこと

**デフォルトの名無しさん** · 2020/10/24(土) 20:44:46.75

>>114
最初の1回だけでしょ？
・・・あー、リモートブランチ名省略して git push origin できるのは名前が同じ時だけか。
なるほどちょっと面倒になるね。

と思ったけど push.default を upstream にしとけば git push origin でいけそう。
https://git-scm.com/docs/git-config.html#Documentation/git-config.txt-pushdefault

**デフォルトの名無しさん** · 2020/10/24(土) 22:19:50.17

>>108
まあ確かにリリースブランチとか定期的に切り替えるときには便利だな
masterとmainの互換性はわからんけどw

**デフォルトの名無しさん** · 2020/10/24(土) 22:22:52.42

>>115
ブランチ名省略してgit push originなんて怖くてやったことないけど使う人いるのか？

**デフォルトの名無しさん** · 2020/10/24(土) 22:24:20.50

>>117
ここにいるよ

**デフォルトの名無しさん** · 2020/10/25(日) 00:35:44.89

それはわたしのおいなりさんだ

**デフォルトの名無しさん** · 2020/10/25(日) 09:05:03.86

>>117
ここにもいるよ

**デフォルトの名無しさん** · 2020/10/25(日) 11:53:45.18

>>117
怖いのは無知だから。勉強すれば怖くないよ
俺はいつもgit pushだな。originも不要

**デフォルトの名無しさん** · 2020/10/25(日) 12:11:04.99

>>119
oretin

**デフォルトの名無しさん** · 2020/10/25(日) 19:01:39.34

>>117
怖いなら-v ---dry-runでもつけてどうなるか確認してみるといいよ

**デフォルトの名無しさん** · 2020/10/25(日) 20:31:14.35

君のGit... ギットギトだね。。。
ほら。。。フォースプッシュ。。。
本番ブランチ。。。