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/08/17(土) 13:59:47.08

Git v2.23.0

2019/08/17(土) 14:06:00.48

Highlights from Git 2.23
https://github.blog/2019-08-16-highlights-from-git-2-23/

2019/08/20(火) 07:47:09.82

resetも分割しろや

2019/08/31(土) 14:48:50.96

>>736
GUIなんていらない
CUIなら必要なレポート簡単に書けるでしょ
git log --name-status --pretty=format:"Xxx Yyy Zzz" |foo|bar|baz...

2019/09/04(水) 11:14:25.75

サブプロジェクトを使ったことがありません。
現プロジェクトの3つの派生プロジェクトを始めるることになりました。共通のソースは9割です。此の場合は、共通のソースをサブプロジェクトに移して使用するのが良いのでしょうか

2019/09/04(水) 11:15:55.34

747はサブプロジェクトじゃなくてサブモジュールの誤りです

2019/09/04(水) 11:36:25.80

逆じゃね

2019/09/04(水) 22:15:50.21

これからも派生が増えてくならそれでいいけど、あまり増えないなら、ブランチで管理するかな。

2019/09/05(木) 12:35:53.77

>>747
管理体制次第だな。
普通はブランチ管理じゃない？
共通ソースの管理者が別にいるならモジュール化も検討するけど、そこまで大きなプロジェクトならgitプロフェッショナル必要な気がする。

2019/09/06(金) 11:38:49.20

>>747です。
ご意見ありがとう。　変更が多いのは共通部分なんでブランチで管理すると他のブランチへのマージを忘れそう。

2019/09/07(土) 16:54:15.29

今後マージするかどうかは運用次第として、一旦ブランチはしておけば良い
ブランチしたのをマージしない運用にするのは簡単だけど、ブランチしないで分離したプロジェクトをマージするのは面倒くさい

2019/09/13(金) 16:19:53.06

保守

2019/09/20(金) 14:19:09.55

個人開発者です。
2年前までlocalでgitコマンドを使ってた。
その後、開発から離れてたんだけど、再度戻ってきた。

昨日からGithubへpushする様になって、色々勉強中。
ヨロピコ！

2019/09/20(金) 14:22:02.16

>>755
ちなみに参考になったのは、
実践Git、第4章
Web+DB Magazine vol. 50(2009)、はじめてのGit

Pro Gitって参考になる？

2019/09/20(金) 16:41:54.43

ProGitが一番

2019/09/20(金) 17:48:25.26

>>757
>ProGit
thx

iPadで読もうとSendToKindleってメールサービスでmobiファイル送ってみた。

ドキドキしながらKindleで同期すると本が来た。
ヨカっタァ。

しかし、すごいボリュームの本だ。

2019/09/20(金) 17:59:22.84

tree object
commit object
のデータ構造を理解した。

coutesy of WEB+DB vol.50

2019/09/20(金) 18:00:13.71

>>758
最近使い始めたAir Dropってので送ろうとしたらNGだった。

2019/09/20(金) 18:05:22.67

GitHubだけど
パソコンのwebブラウザで
new repository
は出来るのに
スマホのwebブラウザだと
new repository
のボタンが出て来ないのはなぜ？
あとクライアント(コンソール)からコマンドで
new repository
ってどうすれば出来る？

2019/09/20(金) 18:28:21.02

ここ良いね
https://git-scm.com/book/ja/v2

2019/09/20(金) 18:49:06.23

https://codenotfound.com/github-add-remote-git-gui-windows.html

2019/09/20(金) 19:32:07.56

>>761
俺もlocalのterminal.appで作業する際、remote(Github)にnew repositoryを作製する方法を知りたい。

多分、出来ないのかな？

2019/09/20(金) 19:40:20.88

pythonとかでスクレイピングでもすればいけるかもしれないが
最近はgithubも二段階認証になって色々面倒なことに

2019/09/20(金) 19:40:59.16

>>764
出来ない理由
terminal.appでnew repositoryできるとすると、数万のrepositoryがbotによって作製されるかもしれない。

shell scriptを書いてやれば、そういった嫌がらせも出来てしまう。
それは避けたいので、ボタンを使ったUIになってるのでは？◀New Repositoryが。

あくまで俺の妄想っす。

2019/09/20(金) 19:45:03.18

markdownで書いた、図入りのテクニカル文書を管理したいんだけど、blogでは色々面倒で、GitHub使おうかと思うんだけど、良いかなぁ？

ソースコードのsyntax highlightが出来て、imageも埋め込めるmarkdownを管理したいんだけど。

それとも、便利なblogサイトある？
livedoor blogをsyntax highlight plugin付きで試したら、大なり小なり記号＜、＞をエスケープしないとsource codeを表示できないので、ガッカリなのだ。

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

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