Git 16©2ch.net

2017/08/15(火) 00:54:07.61

ソースコード管理を行う分散型バージョン管理システム、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 14
http://echo.2ch.net/test/read.cgi/tech/1457412803/
Git 15
http://mevius.2ch.net/test/read.cgi/tech/1486239735/

VIPQ2_EXTDAT: checked:vvvvvv:1000:512:----: EXT was configured

2019/09/20(金) 19:49:37.03

GitHub GistにMarkdown文書を置いた時に、imageファイルってどうやって管理すれば良いのだ？

imgurとかに置いて、url指定するってのがbest practice?

2019/09/20(金) 19:56:01.52

>>768
ここにいくつか解法が示されてる。
https://gist.github.com/Tatzyr/3847141

しかし、
GitHub上のフォームで画像をコピペするとGitHubのS3にアップロードされ、URLがはりつきますよ。

これは、どう言う操作の事だ？

2019/09/20(金) 20:05:34.11

>>769
そう言う事かぁ。
https://gist.github.com/kannankumar/4c613cac6d9db896062a16e1cc57d3e5

2019/09/20(金) 20:13:29.14

gistに貼り付けたmarkdown中にimage貼り付けたけどresize出来ん。
https://gist.github.com/uupaa/f77d2bcf4dc7a294d109
ここにresizing howto記載されてるが、Gistでは効果無し。

<img>タグを使えば上手くresizeされるんだけど、![](url)形式で書きたい。

2019/09/21(土) 09:19:25.03

ここまで酷い自演は久々に観た

2019/09/21(土) 10:51:11.39

>>772
自演じゃなくて、スレッド(のつもり)なんすけど。

Xcode11 Release来た。
XVim2.xcplugin動くかな？

2019/09/23(月) 02:44:37.78

過疎ってんだから日記帳にするなり好きにすればいいよ

2019/09/23(月) 06:23:26.61

>>774
あんがと！

Web+DB vol.50 2009の初めてのGit、って記事、ヨカっタァ。
tree object, commit objectのデータ構造がよく解った。

あと、Garbage Collectionの記事が読みたい。どこからも参照されなくなったcommit objectがpurgeされる話とか。

2019/09/23(月) 06:25:35.01

>>775
https://git-scm.com/book/ja/v1/Git%E3%81%AE%E5%86%85%E5%81%B4-%E3%83%A1%E3%82%A4%E3%83%B3%E3%83%86%E3%83%8A%E3%83%B3%E3%82%B9%E3%81%A8%E3%83%87%E3%83%BC%E3%82%BF%E3%83%AA%E3%82%AB%E3%83%90%E3%83%AA

ここに記事が

2019/09/23(月) 16:22:28.10

>>761
GitHubに対して出来る事は、git-remoteコマンドのオプションのみ！

new repositoryの作製はterminal.appからコマンド打って出来ない。

see git help remote

2019/09/23(月) 16:31:19.95

>>763 の
https://codenotfound.com/github-add-remote-git-gui-windows.html
ここの
Configure Git GUI
からの
Create New Repository
はどういう仕組みで実現してるのだろう

2019/09/23(月) 16:33:06.12

Fetch Immediately じゃなくて
Initialize Remote Repository and Push の方を選んだときの動作ね

2019/09/23(月) 18:06:09.35

>>777
api叩けばいいやろ

2019/09/24(火) 06:41:41.65

>>778
Configure GitHub
のセクションに記載があるとおり、WebサイトでNew Repositoryする。
Git Gui on Windowsからはできないんじゃ無いの？

2019/09/24(火) 06:42:08.00

>>780
API Referenceはどこに？

2019/09/24(火) 09:51:28.93

>>782
ほい
https://developer.github.com/v3/repos/#create

2019/09/24(火) 14:40:27.59

なんか希望が見えて来た
有賀豚

2019/09/25(水) 10:48:49.61

>>783
これダァ。
great THX.

gg://github rest api

2019/09/25(水) 12:00:16.79

stackoverflow
how to create repository in github through github api

github community GitHub API Development
REST API v3 Not able to create repo using the code given

2019/09/27(金) 20:11:00.86

>>637
>>672
GCCのgit への移行は、もうちょっとらしい。

GCC's Conversion To Git: "Within The Realm Of The Practically Achievable"
https://www.phoronix.com/scan.php?page=news_item&;px=GCC-SVN-To-Git-September-2019

2019/09/29(日) 21:44:10.87

それって副産物としてSubversionからGitへの変換プログラムが生まれるってことだよな?

2019/09/29(日) 21:44:46.12

/s/Subversion/SVN/

2019/09/29(日) 22:05:29.01

一般的な応用を期待しているならgit svnという十分に便利なものが既にある

2019/09/29(日) 23:01:05.62

じゃあそいつはGPLじゃないからつかわんかったってことか

2019/09/30(月) 12:17:14.76

RMSがもっと若ければ
とっくにtigとか造ってんじゃね

2019/09/30(月) 18:54:35.24

>>788
>>791
GCCのSubvesion のダンプはかなり大規模かつ複雑でgit svn ではgitのリポジトリには
変換できないらしい。

なのでESRが自分のツール(https://gitlab.com/esr/reposurgeon) で変換しようとしている。

2019/09/30(月) 19:01:18.14

svnのダンプが開発者にも謎な物になってしまってるのが
原因らしいが

2019/09/30(月) 21:25:24.70

ドキュメント大事って話か(´・ω・`)

2019/10/17(木) 20:11:40.33

共有フォルダ上にリポジトリ置いてローカルで開発ってのをやろうと思ってるんだが大丈夫じゃろか
前からいる人はずっと一人でやってた環境らしくてバージョン管理というものをやったことがないらしい
調べたけどSVNはそういうの止めろってことらしいからgitを考えているのだが

2019/10/17(木) 22:17:08.28

大丈夫じゃよ

2019/10/18(金) 20:38:42.21

サンクス。ちゃんと動いた。ほっとしたしリモートからプル出来たときはちょっと感動したわ
ありがとうvisualstudio。そしてgithubもtortoisegitも申請しなきゃいけない会社は潰れろ

2019/10/18(金) 21:13:42.86

Git v2.24.0-rc0

2019/10/18(金) 22:44:03.39

>>798
githubみたいなクラウドサービス使うのに許可がいるのは当たり前だろ

2019/10/18(金) 23:02:32.82

共有フォルダSVNがダメならgitもダメじゃないの？なんか差分あったっけ

2019/10/19(土) 00:32:21.03

共有フォルダにベアリポジトリ置くなら可能

2019/10/19(土) 01:23:53.50

>>800
いやいやｗｗｗ

2019/10/19(土) 02:43:29.64

>>800
だよな

>>803 >>798
https://hayabusa9.5ch.net/test/read.cgi/news/1571409806/

2019/10/21(月) 18:36:15.95

masterからdevelopブランチを切って、ローカルではdevelopからfeatureブランチ切ってそれをいじる
developにマージしてdevelopをプッシュする。不要になったfeatureは削除する
っていう一連の流れを勉強したんだけど、しまったここの関数ちょっとおかしいとかそういうほんとちょっとした変更でもいちいちfeature作るって作業はしたほうがいいの？
あんまり意味が無いような気が

2019/10/21(月) 19:05:05.50

チーム開発なら必要。必ずコードレビューするから、ローカルでdevelopへのmergeなんてしない。

2019/10/21(月) 21:35:01.75

なるほど
二人だけのチームで多分コードレビューなんてしもしないと思うんですけどその場合でも必要ですかね
あとfeatureブランチはリモートにはプッシュしないっていう認識で大丈夫ですか

2019/10/21(月) 21:52:05.56

featureの扱いというよりは、developへのmergeをどこでするか統一しておかないと、各々の環境でdevelopの履歴が分かれていくやろ

2019/10/21(月) 21:54:28.50

featureをリモートにpushして、コードレビューおよびdevelopへのmergeをおこなうのが一般的。ローカルのdevelopは、基本的にfetch or pullとfeatureの作成用途のみ。

2019/10/21(月) 22:39:49.24

むぅそもそもリモートで作業するってのが考えてなかったというかその辺りよくわからないですね
>>796なんですがリモートリポジトリってローカルで作業していったものをどんどん突っ込んでいくものという認識です
ちょっと勉強が足りなかったようです

2019/10/21(月) 22:47:28.39

普通はGitHubやGitLabみたいなホスティング環境を用意するからね

2019/10/22(火) 10:33:39.48

2人に閉じた開発なら結合後にdevelopだけでごりごり開発してもいいよ
いつの間にか気持ち悪いマージコミットが多数生じるだろうけど
気持ち悪いと感じる人がいないならそれはそれで

2019/10/23(水) 03:06:06.75

マージコミットも歴史の一環なんだから、必要と思う派だな俺は

2019/10/23(水) 05:29:04.43

マージコミットが気持ち悪いとか意味分からん

2019/10/23(水) 09:07:03.10

developからdevelopへのマージコミットがキモいということでは

2019/10/23(水) 09:08:03.44

コミットツリーの美しさとかにこだわりが
ある人がいるらしい

2019/10/23(水) 09:20:06.84

それは海外の有名OSSでもわりといる
俺は個人的には全く気にしないけど

2019/10/23(水) 12:55:24.68

>>815
そうそれ

マージコミットのあいだにも価値の多寡があるということ
歴史としての価値があるからこそノイズが多いと経緯を追い難くなる
そこを一切否定するならrebaseコマンドの存在意義も(ほぼ)否定することになる

2019/10/23(水) 13:35:25.15

気持ちはよくわかるが、pull requestベースでの開発だとコミットはあまり気にしなくなるよね
それよりcherry-pick厨はマジで○んでくれ

2019/10/24(木) 21:55:43.84

10人くらいのオフィスで現状何でもかんでもnasに突っ込んで管理してます
HTMLやらcssやらのファイルだけでなく、画像データやofficeやAdobe系のファイル諸々、トータルで2テラくらいあるんですが、git使った方がいいですかね？

2019/10/24(木) 22:37:22.25

Git v2.24.0-rc1

sparse-checkout　は2.24には入らない模様

2019/10/25(金) 00:29:24.66

>>820
あほ

2019/10/25(金) 02:19:18.84

>>820
賢い

2019/10/26(土) 04:05:16.93

>>820
バイナリはあんまりメリットないと思うぞ

2019/10/30(水) 19:20:40.44

Git v2.24.0-rc2

2019/10/31(木) 12:45:58.96

>>825
rc0のバグが二件MLに投げられてたけど、
rc2では一件しか反映されてなくて、
ds/commit-graph-on-fetchは反映されてなかったので、
cookingのリプライで、この件はa corner caseでは無いってメールが投げられてる。

rc3が出そう。

2019/11/01(金) 18:52:14.66

うっかりデバッグする前にコミットしちゃったときに限ってデバッグするとバグが出るのはなぜなのか・・・・・・

2019/11/01(金) 19:24:18.43

うっかりコミットしてもpush前ならなんとでもなる

2019/11/01(金) 22:53:41.80

バグがでたらその場でコミットするすらある
その後確実に直したかを確認できるように

2019/11/02(土) 11:55:22.78

コミットはなんぼでもするでしょ
プッシュでさえみんなと共有してないブランチでなら構わずやることすら多々ある

2019/11/04(月) 15:43:58.15

Git v2.24.0

2019/11/08(金) 20:10:08.64

visual studioで使ってるけど本当に便利すぎて手放せないわもう
例えコミット細かくやりまくってもうどこで何をやったか履歴でよく分かんなくなっても関数の上に変更回数が出てしかもどのコミットだったかとかすぐ分かる
ありがてぇありがてぇ

2019/11/08(金) 23:58:01.51

>>832
おお！それ便利そうだな

2019/11/09(土) 00:33:45.05

visual studioはやっぱり便利なIDEだよ

2019/11/16(土) 12:06:04.07

VSってSVN統合はサポートしてないんだっけ？

2019/11/21(木) 21:00:22.52

新コマンドのsparse-checkoutが盛り上がっているけど、
v2.25 に入るかどうかはまだ不明。
https://public-inbox.org/git/pull.316.v4.git.1571147764.gitgitgadget@gmail.com/T/#me0705177b18287f1037278d870f86d8cba58ccc3

2019/11/24(日) 12:50:33.17

githubでプルリクをマージする人ってプルリクを送った側と受け取った側とでどちらが良いんでしょうか
個人的にはプルリクって、もしこの修正が問題なければ取り込んでくださいって意味だから
受け取った側が承認してマージまでするのが自然な形だと思うんですが、
なぜか今の職場ではプルリクを送った側が自分でマージするルールになっています
私がおかしいのでしょうか

2019/11/24(日) 13:34:18.60

>>837
そういうルールもありだと思う
承認する人が多忙だとその方が仕事が早いし

2019/11/24(日) 14:06:11.79

それってアクセスコントロールしてない無秩序状態ってことだろ？
頭のおかしい開発者が勝手にマージしはじめたらめんどうだ

承認者とマージ実行者を別にするのはよろしい
マージ実行者を開発者全員にするのはよろしくない

2019/11/24(日) 14:19:50.78

それだってケースバイケースだろう。
たしかに頭のおかしい開発者が存在する場合はいろいろ考慮が必要だろうが。

2019/11/24(日) 17:03:56.66

オープンソースのプロジェクトにプルリク送る場合って受け取った側が承認してマージまでするじゃん
githubを作った人の想定では、プルリクを受け取った側がマージするのが正しいんだと思うんですよね
ていうか自分で送り付けて（プッシュ）おいて、自分でマージするってことはそれはもう"プル"リクエストではなくて、
"プッシュ"リクエストじゃないんですかね
githubを作った人の想定通りに素直に使うのが自然で良いと思うんです

2019/11/24(日) 18:06:33.20

開発効率を上げるとかバグを減らす為にルールを作るので
ルールを守るためにルールがあるのじゃない

2019/11/24(日) 18:15:15.68

プルリクを送った側がマージすると開発効率が上がったりバグが減るんですかねちょっとわかりませんね

2019/11/24(日) 18:22:14.13

ここまでくるとちょっとウザい。
あんたの疑問はもっともだと思うからあとは職場の人とよく話し合ってくれ。

2019/11/24(日) 18:48:23.85

どこにも書いてないこと言い出して逆ギレしてるようでは
かなりお荷物さんだろうねえ

2019/11/24(日) 21:03:03.40

は？お前が死ね

2019/11/24(日) 22:15:27.62

社内に頭のおかしい人なんてそうそういないだろと思ったけど
こういうレスを見ると自信なくなる
最初の質問「私がおかしいのでしょうか」については
そうかもねと答えざるを得ない

2019/11/24(日) 22:23:39.72

どんな解釈をしたら、お前”が”しねになるのか分からない笑
君の質問は正しいよ、あなたがおかしい。

2019/11/27(水) 00:29:11.38

>>839
職場に頭がおかしい人がいるならgitで解決しようとしてる場合じゃない

2019/11/27(水) 02:07:52.53

私がおかしいのでしょうかと質問する人は大体周囲が見えてない自己中なので、何言っても無駄

2019/11/28(木) 00:29:54.88

お前の書き込みなんか何の価値もねえわ
向いてないから死ね

2019/11/28(木) 08:00:02.37

おお、マジで周囲が見えてない
ムダだったな

2019/11/28(木) 11:24:04.68

TortoiseGitのグラフ表示時矢印が古い方を指すように下向きに
なった。2.9.0　設定何か触ったかな　

2019/11/30(土) 06:10:34.31

変更のない同一ファイルのときに

git commit -am “こめんと”

を打つとエラーになるけど、エラーを回避するコマンドとか無いかな？
もしくは更新・差分があったときのみcommitするようなパラメータとか

2019/12/10(火) 08:57:29.10

>>854
>もしくは更新・差分があったときのみcommitするようなパラメータとか
まさにこれがデフォルト動作だからエラーになってるんでは
更新・差分はないが直前のコミットメッセージを直したいということなのであれば git commit --amend -m "こめんと" すれば良い

2019/12/10(火) 14:02:57.28

--allow-empty でいいんじゃね

2019/12/11(水) 08:48:33.72

Multiple Git vulnerabilities in 2.24 and older
https://github.blog/2019-12-10-multiple-git-vulnerabilities-in-2-24-and-older/

2019/12/26(木) 12:40:02.51

Git v2.25.0-rc0

2020/01/14(火) 14:04:10.95

Git v2.25.0

リリース直前にgit rebace -iの機能を巻き戻した模様。

2020/01/14(火) 19:51:55.90

「Git 2.25」リリース、「git sparse-checkout」コマンドの追加や細かい機能強化が行われる
2020年1月14日17:15 末岡洋子
https://mag.osdn.jp/20/01/14/171500

2020/01/15(水) 10:03:41.64

>>836
2.25に入りましたね

2020/01/15(水) 14:10:39.53

大体ググって覚えて使ってる個人の感想としては、
ざっくり『addしてcommitしてpush、後はbranch作ってなんか切ったり結合したり出来れば大体なんとかなる』というノリでgit使ってるんですな何か他に知っておいた方が良い操作とかあるんでしょうか？
ブランチ名やコミットメッセージを付ける等の補助的なオプションに関する知識は勿論前提として。

2020/01/15(水) 14:17:31.11

壊れた時の治し方

2020/01/15(水) 15:53:47.54

初期に便利だと思ったのは
stash
ignoreのバリエーション
skip-worktree
reset
reflog
あたりかな

2020/01/15(水) 18:52:02.01

stashなんか怖くて別の場所にチェックアウトしちゃう

2020/01/15(水) 19:33:55.68

>>862
何をおいてもgit rebase。これ使わないとgitの価値が無いと言ってもいいぐらい

2020/01/15(水) 20:55:58.51

ちょっと違うけど、vcodeのアドオンにあるgitのdiffとかhistoryを見る機能は便利。

2020/01/15(水) 23:01:29.73

rebaseとか未だに有用性が理解できない