Git 17

■ このスレッドは過去ログ倉庫に格納されています
2020/09/02(水) 12:18:30.39ID:XN0SxNMq
ソースコード管理を行う分散型バージョン管理システム、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/11/04(水) 15:42:46.75
全部コマンドで、というか
git config で・・
2020/11/04(水) 17:50:40.26ID:Q20JRtoy
そういうのはリポジトリの .gitignore で除外するだろ
言語に対応した .gitignore を自動生成する仕組みとかあるからググれ
163137
垢版 |
2020/11/04(水) 19:03:17.34ID:RhljQsjd
>>160
gitignore自体gitの管理対象なんだから、ファイルのほうがいいだろ。
2020/11/05(木) 22:38:23.35ID:p8NevL67
git config　の core.autocrlf について教えてください

リモートのリポジトリにAとBというブランチがあります。
２つのブランチのファイルの改行コードはLFになっています。

下記手順でAとBをチェックアウトし、各ブランチの改行コードを見ると、AもBもCRLFとなっていました。

①git config --global core.autocrlf=true を実行しAのブランチをチェックアウト
②git config --global core.autocrlf=false を実行しBのブランチをチェックアウト

一度チェックアウトした後にcore.autocrlfの設定を変えても、その後にチェックアウトしたブランチには適用されないのでしょうか？
2020/11/05(木) 23:20:14.93ID:Jc1WkDDO
autocrlfを気にするということはWindowsでの開発だと思います。
autocrlf=trueでコミットしたんじゃないかと思います。

コミット内容はオプションを変えても変わりません。
これはレポジトリはLFにして、作業コピーはCRLFで扱うオプションです。

個人的にはこのオプションは、勝手にファイルを変えるものなので使う場面は限られると思います。
最近はWindowsでもLFが使えるようになってきてるのでLFだけにするか、もしくはWindowsだけで開発するならCRLFでそのままコミットしてよいと思います。
2020/11/05(木) 23:25:35.51ID:Jc1WkDDO
あ、ブランチはLFって書いてありますね。ふむー。AだけがCRLFのはずだが。
LFであることと、チェックアウトしたファイルがCRLFであることはどうやって確認したんですか？
エディタがCRLFに変換してるってオチじゃないですよね？不安ならodとかでダンプしてみるといいです。
2020/11/05(木) 23:45:37.13ID:p8NevL67
>>166
ご回答ありがとうございます。
LFであることの確認はgithubからソースをzipでダウンロードしてソースファイルをEmEditorで確認しました。
CRLFであることの確認はローカルにチェックアウトしたソースファイルを同じくEmEditorで確認しました。
odというもので再度確認してみようと思います。
168デフォルトの名無しさん
垢版 |
2020/11/06(金) 11:00:19.76ID:LTqO0fOq
EmEditorよりも櫻
櫻よりも禿丸
2020/11/06(金) 12:47:54.85ID:a+LGJjdY
同じエディタで確認してるなら改行コードの取り違いはなさそうです
ファイルの内容とか拡張子はなんですか？attributeが悪さをしてるとかだろうか
いずれにしてもautocrlfの理解は合ってると思います
2020/11/06(金) 12:52:42.30ID:a+LGJjdY
ちなみにgit configのヘルプにはname=valueではなくて、スペース区切りの指定に見える。
autocrlfを変えたあとにconfig --getしてみたらどうなります？変わってなかったりして。
2020/11/07(土) 00:10:19.49ID:/xSkaoCp
VSCode を使え！

GitLens などの拡張機能も色々ある
2020/11/07(土) 03:18:28.55ID:l+eJcypb
お、エディタ論争か？
2020/11/07(土) 15:45:39.89ID:cgvbFt64
便乗で質問

LF管理でCRLFへ自動変換はよく見るのですが
逆に
リポジトリ上ではCRLFで管理
ローカルではLFに自動変換も可能

みたいなことって出来ますか？
2020/11/07(土) 17:22:06.42ID:b176xE9N
リポジトリ上ではどう管理されてるかなんて気にする必要がない
2020/11/07(土) 17:28:53.28ID:MFxIcgBo
設定としては存在しない
そしてリポジトリ上でCRLFにするのは非推奨
2020/11/07(土) 19:15:02.73ID:cgvbFt64
設定としては～、ということはやり方が無きにしも非ずと
まだまだ触り程度しか使っていないので、必要になったらまた勉強します

ありがとうございました
2020/11/07(土) 21:10:07.76ID:26EDxQ47
非推奨ってどこに書いてある？
Windowsだけで使ってるからいつもCRLFで入れてるよ
2020/11/07(土) 22:00:24.80ID:ar+UP0ei
Gitの場合、テキストファイルもバイナリファイルも関係なくハッシュ作って管理してるだけ
2020/11/07(土) 22:13:20.58ID:3cYV0JqL
>>178
ハッシュしか持ってなかったら元データを復元できないのでは
180デフォルトの名無しさん
垢版 |
2020/11/08(日) 00:28:35.60ID:SXTLRNAJ
>>173
自動変換するわけがない。普段、改行コードをあまり意識していないだけでしょ。
181デフォルトの名無しさん
垢版 |
2020/11/08(日) 00:31:51.30ID:SXTLRNAJ
>>179
ハッシュ変換とハッシュ変換したデータを使う仕組みがごっちゃになってるよ。
2020/11/08(日) 03:05:08.77ID:YnyAcD/m
>>173
git hooks で調べろ。何でもできるぞ。
間違えてgithubの記事を見に行かないように。gitの機能だからな。
183デフォルトの名無しさん
垢版 |
2020/11/08(日) 12:17:19.96ID:SXTLRNAJ
>>173
なぜ改行コードを変えたいのかがわからない。
184デフォルトの名無しさん
垢版 |
2020/11/08(日) 14:00:20.31ID:M0llHupc
どうでも良いけど下手な環境で作業すると
保存する度に行間が開いていくよね
2020/11/08(日) 19:44:51.13ID:CpI3QDTu
え？
2020/11/08(日) 23:30:36.29ID:t/VkPMTp
>>180
gitに自動変換機能あるぞ
187デフォルトの名無しさん
垢版 |
2020/11/10(火) 00:41:12.93ID:c+4iqUmg
>>186
自動変換の設定を確認してないという話だろ
2020/11/11(水) 12:44:34.75ID:ylt8PecZ
最初のautocrlfの人戻ってこないな
解決したのか
2020/11/11(水) 15:59:24.66ID:iQgtLl5J
gitattributesの改行と文字コードのデフォルト値ってどっかに一覧ないですか？
改行と文字コードの自動補正はしてほしいけど想定外の補正されると困るんで把握しておきたいです
190デフォルトの名無しさん
垢版 |
2020/11/12(木) 21:58:43.24ID:m5jPdjVX
自動的に変換する設定を使うのが面倒。
2020/11/13(金) 10:03:02.42ID:woSrJ+Z7
gitの初心者です。質問してもよろしいでしょうか？

共有フォルダの[A]フォルダにリポジトリを作り作業するファイル類を入れてあります。

これを2人で共同で使うためそれぞれ[B]と[C]というクローンを作り、そこで編集します。

それぞれ[B]と[C]で更新して、1日の終わりに[A]を最新の状態にしておきたいのですが、

クローンして、更新してCommitして、最後にpushで合っていますでしょうか？
2020/11/13(金) 10:16:27.20ID:9KKZC7Fr
はい
193デフォルトの名無しさん
垢版 |
2020/11/13(金) 11:37:28.52ID:RWm0omqa
内容によるけど
全員 master で作業するんか？
branch して commit push して
確認後 merge する気は無いんか？
2020/11/13(金) 12:24:49.56ID:lJPbeFXM
コンフリクトの解消手順を教えて下さい
2020/11/13(金) 12:44:40.29ID:n34VhWUt
>>194
エディタで修正してaddしてcommitするだけよ
2020/11/13(金) 13:04:52.38
めちゃくちゃ細かい修正のときって-mはどうしていますか
考えるのがめんどうなので'更新'とか'修正'でいいですよね？
2020/11/13(金) 17:43:25.79ID:MS9okgUk
>>196
そこは回答が分かれるところですね。
自分だったら、主にどっちを採用したっていう概要とその理由を書くかな。
細かい差分はdiffで見れるから、後で見ても分からないものは書いておくよ。

他の人にも聞きたいんですが、コンフリクト解消ってどこまでやりますか？ビルド通って動かせるところまで？
evil mergeになるのが気になる。
2020/11/13(金) 18:36:18.45ID:KMQ/X74/
誰かが代わりに動くまで修正してくれるの？
2020/11/13(金) 18:38:13.21ID:5fX1gEph
恐ろしい書き込みを見た
これが13日の金曜日か…
2020/11/13(金) 18:51:25.55ID:MS9okgUk
コミットを分けるか、という意味です。言葉足らずですみません
2020/11/13(金) 18:52:58.07ID:35N+92Bf
コンフリクト解消とスカッシュを自由自在に操りたい
2020/11/13(金) 23:47:36.97ID:M0Lr/ts/
>>193
いつまでmasterなんか使ってんだ？
2020/11/14(土) 01:28:12.18ID:zCGno+9x
お帰りなさいませご主人様～ とかも駄目になるのかぬ
2020/11/14(土) 02:17:29.33ID:Q0fppD5p
言葉狩りに嫌気さしてきたからブランチの名前をslaveとかblackとかにしたい
205デフォルトの名無しさん
垢版 |
2020/11/14(土) 03:04:53.39ID:66xrGHZh
>>200
ブランチの概念がないの？
2020/11/14(土) 11:48:24.71ID:OfQ57GBv
>>200
まだまだ言葉足らず過ぎないか？
不特定多数の見る5chやでえ
マージをしているなかで互いの処理の競合を調停するための新規コードが必要になったとき二つの選択肢があると思う
1.テストが一部通らないことをコメントで断った上で、新規コードをマージコミットに混ぜるのを避ける
2.競合回避のための新規コードが混ざったことをコメントで断り、マージコミットで全部やる
個人の好みと程度問題じゃないかな
俺は差分を共有しやすいから1が好き
2020/11/14(土) 11:50:15.20ID:vc7ZeNxq
>>205
ブランチをマージするときの話ですよよ。文脈は把握されてますか？ご存知なければ無理にレスしなくて大丈夫ですよ。
2020/11/14(土) 11:53:34.61ID:vc7ZeNxq
>>206
evil mergeを避ける派ですね。
丁寧なレスありがとうございます。
言葉足らずなところを指摘、補足していただいてありがとうございます。
209137
垢版 |
2020/11/14(土) 22:18:57.62ID:eMR5CvED
>>202
変える技術的なメリット無い限りはそのまんまだろ。
技術的なメリットを説明しろよ。
2020/11/15(日) 02:58:48.98ID:bhsguIlX
作業ブランチで機能追加やクリーンナップを地道に進め、
最後にmergeした結果を見ると、コーディングを最初から一気にやり遂げた錯覚になり、
スカっとするな。
という一連の流れを脳内再生してから --squash のオプションを思い出す俺。
2020/11/15(日) 12:14:35.24ID:ofPGnU/6
>>210
お前エセだろｗ

作業ブランチで作業をしている途中で
あれ？これバグじゃね？
先にリファクタリングするべきだったなと
後から気づくことがある

そういうのを別のコミットに分けて
順番を並び替えつつ作業していくと
いきあたりばったりで作業したのではなく
綿密な計画にそって作業したように見える

それは錯覚ではなく、最終的にそうなったので
それをマージしたりしたときに後から修正を追いやすくなる
--squashしたら一つにまとまるからダメじゃん
2020/11/15(日) 12:25:50.44ID:ALi3WLRE
そんで author date を変え忘れていきあたりばったりがバレる
2020/11/15(日) 12:27:45.04ID:ofPGnU/6
>>212
バレてなんか問題でもあんの？
2020/11/15(日) 13:22:06.47ID:ALi3WLRE
>いきあたりばったりで作業したのではなく
>綿密な計画にそって作業したように見える

他人にバレてるのに自分じゃこう見えると思ってたら恥ずかしいってだけ
2020/11/15(日) 14:10:48.99ID:ofPGnU/6
>>214
どうでもよくね？
重要なのはソースコード、完成した結果だよ
途中の作業なんかどうでもいい
2020/11/15(日) 14:18:31.84ID:ALi3WLRE
ほんと、どうでもいいと思うよ。

>綿密な計画にそって作業したように見える

こんなの気にするのは>>211くらいｗ
2020/11/15(日) 14:20:02.90ID:ofPGnU/6
>>216
気にしてるのはお前だよ。「ように見える」なんだからどうでもいい部分
実際に重要なのは、意味があるコミットになっていてレビューや他のバージョンへの適用がしやすい点
いつまでもどうでもいい部分を気にしてるなよｗ
2020/11/15(日) 23:35:01.28ID:pj0VtiWP
gitの開発MLを見てればわかるが、
内部のテストからもmasterという文字列を完全に抹殺すべくパッチが投稿されてる。

個人的には言葉狩りは好きでは無いが、
リベラルに中途半端は無いから、
早めにmasterからmainに変えた方が良いかも。
2020/11/16(月) 03:21:24.45ID:ZICsfNV8
>>218
言葉狩りが始まったらやるよｗ
220デフォルトの名無しさん
垢版 |
2020/11/16(月) 10:56:32.52ID:sF1WJXNT
一番危険な敵は内部の一番無能な人間
2020/11/16(月) 11:50:11.80ID:pa4DKO5k
外部のキチガイが、内部に入り込んで包丁振り回すかもしれないぞ
222デフォルトの名無しさん
垢版 |
2020/11/16(月) 12:05:15.33ID:sF1WJXNT
書き忘れたけど無能な人ほど良く働くω
2020/11/16(月) 16:09:47.48ID:sYD91QvB
ソース管理規約を守らない奴は無能
2020/11/16(月) 22:48:43.54ID:Iqqc8SBv
無能が無能を叩く構図
2020/11/17(火) 00:01:38.69ID:qU694wOR
WindowsでSourceTreeを使ってみたら、Shift-JISのファイルがプレビューで文字化けしてるんだけど、
Gitで管理するときは大人しくすべてUTF8に変換するべきなんでしょうか
2020/11/17(火) 00:16:54.68ID:ep69fhBS
Git関係なくUTF-8にするべき
Visual StudioのプロジェクトならUTF-16とかもあるけど
少なくとも全部Unicodeにしとけ
2020/11/17(火) 00:23:07.14ID:cTkCP5Bm
Visual Studioでsjisファイルのプレビューを見てみたけど文字化けなんかしてないけどなあ
2020/11/17(火) 01:17:38.85ID:4RXTidLa
>>225
git自体はUTF8だろうがSJISだろうが管理できるよ
文字化けするのはSourceTreeの問題
2020/11/17(火) 02:15:40.13ID:wZV7GIAN
gitattributesに文字コード書くだけ
2020/11/17(火) 02:32:05.88ID:hUMTMGfY
Visual Studioがうんこだから仕方なくVSで管理する用のソースファイルはBOMつきUTF-8にしてる
本当はBOMなしUTF-8がいいけど
（/source-charset:utf-8の存在は知ってる）
231137
垢版 |
2020/11/17(火) 08:10:49.14ID:lJA+qRYx
>>230
visual studioもEditorConfig対応しているってよ。
2020/11/17(火) 09:08:16.34ID:iIrFjUs6
Gitは文字コードを管理できないというか実質的にUTF8強制になる
改行コードも固定するしかない
2020/11/17(火) 12:46:30.93ID:sslQDmWT
Visual Studioのプロジェクトにはプロジェクトファイルやリソースファイルも含まれていて、
UTF16やShift-JISで自動的に生成されるものが多いけど、
これらのファイルもUTF8にして運用するのがGitのやりかたということでしょうか？
MacやLinuxなどに持ってくることは考えていないです。
2020/11/17(火) 13:15:25.09ID:kX22Q/MP
別にutf8に固執する必要なんてないよ
2020/11/17(火) 13:54:19.11ID:ep69fhBS
UTF-16でもUTF-8でもいいよ
Unicodeならどっちでもいい
2020/11/17(火) 13:55:20.25ID:CjRdGkWC
Gitだと文字コードや改行コードが考慮されないから、Windowsだけで開発するならUTF8以外でもいいいけど、いずにせよ固定しないといけない
2020/11/17(火) 13:56:26.00ID:WArcbn8k
SJISでもいいといえばいいけど、LinuxユーザーやMacユーザーがメンバーにいると困ることになると思う
2020/11/17(火) 14:19:48.15ID:9dDm78mO
>>237
質問者はWindowsだけって言ってるだろ
2020/11/17(火) 14:22:19.09ID:NE44coqD
WindowsだけならSJISはまずいな
海外のWindowsじゃ使えない
やっぱりUTF-16じゃないと
2020/11/17(火) 14:26:50.42ID:3/q4MWZe
SJISのファイルを英語版のWindowsに持っていったら、Windows Indexとかどうなるんだろうな
2020/11/17(火) 17:01:55.47ID:74wM5f1E
batファイルがCHCPだけで問題なく使えれば全部UTF-8にできるんだがなあ
現実解でいえば多少Shift JISのソースが混ざることもあるよ
Gitでは困らないけど統一できるならしたいところ
2020/11/17(火) 17:11:02.74ID:nHdTOcnh
>>241
バッチファイルだけだよって言ったほうがわかりやすいｗ
243137
垢版 |
2020/11/17(火) 18:47:44.20ID:lJA+qRYx
>>241
Power Shell使わせたら？
バッチファイルしか使えないような環境は未サポートでいいだろ。
2020/11/17(火) 18:57:03.90ID:3gEjvWlt
>>243
勝手なこと言うなよ
245233
垢版 |
2020/11/17(火) 22:52:01.91ID:qU694wOR
何度もすいません。必ずしもUTF8にする必要はないということは、
SourceTreeで差分などが文字化けするのは諦めた上でということですか？
それとも、Shift-JISやUTF16のファイルが混ざっていても
文字化けさせない方法があるのでしょうか？
2020/11/17(火) 23:00:53.88ID:w1s1A3Uh
端的に言ってsourcetreeがアホってこと
2020/11/17(火) 23:25:46.72
空ディレクトリはプッシュできないのはなぜですか
2020/11/18(水) 00:17:09.23ID:cMpWLiaN
gitはファイルしか管理していない。
ファイルパスを保存しているからディレクトリが有るように見えるだけ。
2020/11/18(水) 00:57:04.47ID:dj5RIL/l
>>247
https://gist.github.com/dritoshi/2168873
2020/11/18(水) 01:10:01.63
>>248,249
ありがとうございました
2020/11/18(水) 04:02:44.61ID:uoM+CD8t
>>245
差分はwinmergeがおすすめよ
文字コードの認識能力は高いし、多くの改行コードにも対応してる
難点は、いろんな文字コードや改行コードが混ざってても気づかないところかw

gitとの連携もできるしね
2020/11/18(水) 08:35:52.41ID:kXa1mHp5
>>251
改行コードが混在してるときはMixedってステータスバーに表示されたかと
253137
垢版 |
2020/11/18(水) 12:24:59.97ID:6GRC5GM1
>>247
作業ディレクトリなどのように中身のファイルを無視したい場合は、.gitignoreを例外として全ファイルを無視する.gitignoreを入れておくといい。
2020/11/18(水) 12:36:04.63ID:t3uJEQyj
>>246,251,252
ファイルごとの文字コードは無理に統一せずに、
UTF16やShift-JISのときはSourceTreeの差分表示は文字化けさせたまま、
WinMergeで比較を行うということですよね？

WinMergeは普段から使っているので、
SourceTreeで文字化けしていてもGitの管理上は問題ないのなら、
それが楽かもしれないです。
2020/11/18(水) 18:13:59.21ID:aBokwQ7L
WindowsユーザーのGit初心者はTortoiseGitを使うのが一番楽だと思う
同梱のdiffツールも十分実用的
シェル統合は好き嫌い別れるけど文字化けのようなトラブルを独力で解決できるなら好きなツールを使えばよろし
256137
垢版 |
2020/11/18(水) 19:18:43.32ID:6GRC5GM1
開発初心者なら、こだわりのエディタとかないだろうから
Visual Studio Code + Git Graph
を使わせるのが一番いいと思う。
gitの機能がeditorに統合されているとやっぱり楽よ。
2020/11/18(水) 19:21:49.89ID:9OxgFlRx
コミットの改ざんを直感的なUIで出来るアプリほしい
コミットをくっつけたり
変更範囲の広いコミットを分割したり
コンフリクトを解消したり
258デフォルトの名無しさん
垢版 |
2020/11/19(木) 14:59:14.84ID:MCajbxoP
すいません
初心者なのですが、以下の状況に陥りました

1.origin/masterからブランチAを作成した
2.作業が途中だったが、他の作業が発生したのでAをコミットせずにスタッシュした
3.origin/masterからブランチBを作成した
4.ブランチBをコミットしてorigin/masterへマージした
5.ブランチAの作業を再開しようとしたらコンフリクトが発生した

ブランチAのチェックアウトもプルもスタッシュの復帰もできないのですが、
どの手順でAの作業を再開すればよいのでしょうか？
2020/11/19(木) 15:04:04.00ID:MmDwDVMn
A のチェックアウトで何かエラーが出るの？
2020/11/19(木) 15:33:04.91ID:s5sCnCc3
>>258
6.テキストエディタでソースコードのコンフリクトした箇所を修正しAの作業を再開した

これだけ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況