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/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... ギットギトだね。。。
ほら。。。フォースプッシュ。。。
本番ブランチ。。。

**デフォルトの名無しさん** · 2020/10/26(月) 09:45:49.24

$ git push origin master
error: src refspec master does not match any.
error: failed to push some refs to 'https://github.com/hogehoge/hogehoge.git'

糞だな

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

git branch master
git checkout master
git merge main
git push origin main
git branch -D main
git push --delete origin main
git gc
消したったわ

**デフォルトの名無しさん** · 2020/10/28(水) 13:58:07.50

久しぶりにgit使ったらbranchがデフォルトでmasterじゃなくてmainという表記になっていたのだが

**デフォルトの名無しさん** · 2020/10/28(水) 14:21:17.90

そうだね

**デフォルトの名無しさん** · 2020/10/29(木) 13:42:03.39

ローカルのgitがmasterでリモートのgithubがmainになってるね
クローンからリモートするならすんなりいくけど
その逆だと気づかずにプッシュするとmainへのリクエスト扱いになっちゃう
configでデフォルトのブランチ名変えられないのかな

**デフォルトの名無しさん** · 2020/10/29(木) 13:56:10.58

git remote set-head origin master

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

https://ngyuki.はてなblog.com/entry/20120827/p1

**デフォルトの名無しさん** · 2020/10/29(木) 19:36:03.79

散々ニュースで言われてるのに今頃になって対応とか遅くない？

**デフォルトの名無しさん** · 2020/10/29(木) 21:20:17.79

>>130-131
設定できるのかー

①githubで新規リポジトリ作成
②ローカルのリポジトリディレクトリに移動して$ git init
③$ git add . $ git commit -m 'ローカルスタート'
④$ git checkout -b main $ git branch -d master
⑤$ git remote add origin https://github.com/[user name]/[repository name].git
⑥$ git push -f origin main
ってやってる・・

**デフォルトの名無しさん** · 2020/10/29(木) 21:25:35.79

もうつぎからはリモートスタート（クローンスタート？）だとローカル側もmainブランチで始まるから
空リポジトリをクローンする方法でやる

**デフォルトの名無しさん** · 2020/10/30(金) 02:21:28.42

「gitのメインブランチは昔はmasterだった」
「嘘乙」
「なんでmasterからmainになったんですか？」
「masterは奴隷差別を連想させるからだよ
」

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

ホワイトナイトは差別用語なので禁止してください

**デフォルトの名無しさん** · 2020/10/30(金) 11:28:40.33

releaseとかsummaryとか使うところ出てくるかな？
integrationとかは無さそうかね。

**デフォルトの名無しさん** · 2020/10/30(金) 12:11:13.25

昔から develop ブランチを使ってるとこが多いでしょ

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

王様のブランチ

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

git flowしてたらreleaseブランチは普通にあるでしょ

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

それな

**デフォルトの名無しさん** · 2020/10/30(金) 19:04:56.80

してなかったら　という考えはないのか？

**デフォルトの名無しさん** · 2020/10/30(金) 19:06:03.15

「使うところが出てくるのかな？」に対して「既に使ってるところはあるやろ」って返しだから何もおかしくない

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

開発当事者でもないのにブランチ名変えろと
ポリコレissue投げまくる事件起こりそう

**デフォルトの名無しさん** · 2020/10/30(金) 19:43:14.51

tortoisegitでマージコミットを選択すると、親１との差分、親２との差分という形で別れて表示されますが、これを3-way表示にさせる方法はありますでしょうか？
テキスト比較できないファイルを外部ツールでdiffしており、競合の編集時はその外部ツールで3way表示できるように設定しています。
マージコミットからダブルクリック等でその外部ツールの3way表示が開くのが理想なのですが、そのような設定や手法はありませんでしょうか？

**137** · 2020/10/30(金) 19:52:27.03

すまんすまん、デフォルトブランチを変える話な……と思ったけど、開発観点からはgitのデフォルトブランチなんてどうでもいいか。

>>144
mster使わないのは別に構わないけど、開発者なら技術的な利点を主張して欲しいわ。
技術屋が形だけでも同意できる理由も用意せずにねじ込もうとするポリコレバカはくたばって欲しい。

**デフォルトの名無しさん** · 2020/10/30(金) 20:43:26.47

わかったわかった、ポリコレに配慮してブランチ名はすべてsha1ハッシュにしよう

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

>>144
起こってる

**デフォルトの名無しさん** · 2020/10/31(土) 10:36:44.35

秋葉でお帰りなさいませ御主人様が聴けなくなる日も近いか

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

メイド自体も主従関係の歴史を想起させるのでNG
家事の主体たる職業名を採用しメイドカフェはハウスキーパーカフェになります
衣装はズボンとエプロン

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

おかえりなさいまで、お代官様で

**デフォルトの名無しさん** · 2020/10/31(土) 14:46:00.48

女王様のムチSMプレイが無くなる日も近いな

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

ホットドッグにマスタードかけるのも禁止になりそうだな

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

マスターベーシャンも禁止

**デフォルトの名無しさん** · 2020/11/01(日) 21:34:55.35

Git v2.29.2

**デフォルトの名無しさん** · 2020/11/02(月) 22:17:08.12

ファストフォワードマージと分岐するマージはどっちを利用するべきなんでしょうか？

**デフォルトの名無しさん** · 2020/11/02(月) 22:36:10.14

ケースバイケースだから二つあるんだよ。

**デフォルトの名無しさん** · 2020/11/04(水) 13:54:17.76

pythonの場合
distディレクトリとegg-infoディレクトリは
git rmしますか？
それとも更新するたびにsetup.pyして最新版の.tar.gzもpushするのでしょうか。

**デフォルトの名無しさん** · 2020/11/04(水) 14:39:20.50

.ignore に描く

**デフォルトの名無しさん** · 2020/11/04(水) 15:42:04.95

ホームディレクトリに.ignore設置して云々とかあるけど
全部コマンドでできればいいのに・・

**デフォルトの名無しさん** · 2020/11/04(水) 15:42:46.75

全部コマンドで、というか
git config で・・

**デフォルトの名無しさん** · 2020/11/04(水) 17:50:40.26

そういうのはリポジトリの .gitignore で除外するだろ
言語に対応した .gitignore を自動生成する仕組みとかあるからググれ

**137** · 2020/11/04(水) 19:03:17.34

>>160
gitignore自体gitの管理対象なんだから、ファイルのほうがいいだろ。

**デフォルトの名無しさん** · 2020/11/05(木) 22:38:23.35

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.93

autocrlfを気にするということはWindowsでの開発だと思います。
autocrlf=trueでコミットしたんじゃないかと思います。

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

個人的にはこのオプションは、勝手にファイルを変えるものなので使う場面は限られると思います。
最近はWindowsでもLFが使えるようになってきてるのでLFだけにするか、もしくはWindowsだけで開発するならCRLFでそのままコミットしてよいと思います。

**デフォルトの名無しさん** · 2020/11/05(木) 23:25:35.51

あ、ブランチはLFって書いてありますね。ふむー。AだけがCRLFのはずだが。
LFであることと、チェックアウトしたファイルがCRLFであることはどうやって確認したんですか？
エディタがCRLFに変換してるってオチじゃないですよね？不安ならodとかでダンプしてみるといいです。

**デフォルトの名無しさん** · 2020/11/05(木) 23:45:37.13

>>166
ご回答ありがとうございます。
LFであることの確認はgithubからソースをzipでダウンロードしてソースファイルをEmEditorで確認しました。
CRLFであることの確認はローカルにチェックアウトしたソースファイルを同じくEmEditorで確認しました。
odというもので再度確認してみようと思います。

**デフォルトの名無しさん** · 2020/11/06(金) 11:00:19.76

EmEditorよりも櫻
櫻よりも禿丸

**デフォルトの名無しさん** · 2020/11/06(金) 12:47:54.85

同じエディタで確認してるなら改行コードの取り違いはなさそうです
ファイルの内容とか拡張子はなんですか？attributeが悪さをしてるとかだろうか
いずれにしてもautocrlfの理解は合ってると思います

**デフォルトの名無しさん** · 2020/11/06(金) 12:52:42.30

ちなみにgit configのヘルプにはname=valueではなくて、スペース区切りの指定に見える。
autocrlfを変えたあとにconfig --getしてみたらどうなります？変わってなかったりして。

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

VSCode を使え！

GitLens などの拡張機能も色々ある

**デフォルトの名無しさん** · 2020/11/07(土) 03:18:28.55

お、エディタ論争か？

**デフォルトの名無しさん** · 2020/11/07(土) 15:45:39.89

便乗で質問

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

みたいなことって出来ますか？

**デフォルトの名無しさん** · 2020/11/07(土) 17:22:06.42

リポジトリ上ではどう管理されてるかなんて気にする必要がない

**デフォルトの名無しさん** · 2020/11/07(土) 17:28:53.28

設定としては存在しない
そしてリポジトリ上でCRLFにするのは非推奨

**デフォルトの名無しさん** · 2020/11/07(土) 19:15:02.73

設定としては～、ということはやり方が無きにしも非ずと
まだまだ触り程度しか使っていないので、必要になったらまた勉強します

ありがとうございました

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

非推奨ってどこに書いてある？
Windowsだけで使ってるからいつもCRLFで入れてるよ

**デフォルトの名無しさん** · 2020/11/07(土) 22:00:24.80

Gitの場合、テキストファイルもバイナリファイルも関係なくハッシュ作って管理してるだけ