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

2018/06/26(火) 21:33:24.80

>>265
たとえば？

2018/06/27(水) 00:23:55.22

>>266
今時のIDEなら、ソースの編集画面で、行が修正されてたかどうか表示があるよね？

AndroidStudio はこれがカレントブランチのHEADから修正されてるかどうかを表示してくれる
最新バージョンだと、この修正されてるかどうかの表示から、行の固まりを直接コミットできたりする
add -p がソースの編集画面でできるってことね

全体的に、ソースの編集が、ファイルを編集するのじゃなくて、コミットを編集するイメージでできちゃうのがいい

2018/06/27(水) 02:00:45.52

>>267
それが「酷く見劣りする」のかい？

2018/06/27(水) 04:19:45.96

>>267
正直ニッチ需要

2018/06/27(水) 10:20:54.35

VSは、ファイルシステム上のソースを編集するIDEに、レポジトリを操作する機能を追加しただけ
Android Studioはレポジトリ上のソースを直接編集するIDEになりつつある

前者が一周遅れているのを酷く見劣りすると表現した
後者はニッチなんかじゃなくて、これからIDEの基本的機能になるよ

2018/06/27(水) 10:29:05.13

>>270
具体的に

2018/06/27(水) 10:36:13.05

>>271
>>267

2018/06/27(水) 12:35:11.22

>>270
どうでもいい機能

2018/06/27(水) 13:00:46.70

この辺どうでもいいって言ってる奴は、コミットする時statusやdiffで確認とかしてなそう
gitignoreも適当で何でもかんでもコミットに突っ込むタイプ

2018/06/27(水) 13:06:25.02

>>274
根拠のない決めつけ頭おかしい

2018/06/27(水) 13:08:26.72

>>270
いらない機能だね

2018/06/27(水) 13:09:55.91

マウント取りたいだけやろ？

2018/06/27(水) 14:05:29.15

>>275
>>267みたいな機能は、>>274みたいな奴には必要ない機能だからね
逆にコミットを丁寧に作りたい奴にはとても便利な機能

2018/06/27(水) 14:49:54.17

無駄な機能使って悦に浸りたいだけか

2018/06/27(水) 17:09:02.20

底辺には必要ない機能

2018/06/27(水) 20:20:31.88

中央管理に逆戻りしてるだけにしか思えん。

2018/06/27(水) 22:46:24.77

どこが中央管理？

2018/06/28(木) 01:01:00.14

これだからコミットオナニストは困る

2018/06/28(木) 01:24:53.49

糞みたいなコミットでプルリク投げんなよ
買ってもらったGithubが泣いてるぞ

2018/06/28(木) 03:05:25.22

ﾌﾞｰｲﾓへの賛同者なし

2018/06/28(木) 03:11:08.11

MS が周回遅れなのはいつもの事だろ

2018/06/28(木) 03:12:58.41

GUIも
インターネットも
OSSも
Gitも
いつも手のひら返し

2018/06/30(土) 02:36:01.41

Supercharging the Git Commit Graph
https://blogs.msdn.microsoft.com/devops/2018/06/25/supercharging-the-git-commit-graph/

MSの人がGit 2.18 のcommit graph について熱く語っている。

2018/06/30(土) 07:37:56.40

>>288
>>255

2018/06/30(土) 10:51:20.67

>>288
ありがとう

2018/06/30(土) 14:13:16.44

>>288
thx!

2018/06/30(土) 14:36:14.41

>>288
この改善は、普通の規模のリポジトリにはほとんど影響無い

モジュール分けしてなくて馬鹿みたいにでかい原始的なWindowsのリポジトリをそのままGitで管理するようにしたら、log --graph の表示が遅すぎて使い物にならなくなって、しょうがないから git に対策入れたって話

2018/06/30(土) 15:13:57.50

>>292
よく読んでみ
WindowsじゃなくてLinuxを指標としてるから

2018/06/30(土) 16:03:54.28

>>293
指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ

Linuxカーネルリポジトリで異様に改善されてるのは branch --contains だけ
これはそんな頻繁に使うもんでもないし、ブランチ全部ローカルにpullしてくる必要もないんで特に問題にならん
log --graph 6秒も許容範囲

それにくらべて、WindowsリポジトリはGVFS使ってチートしてるのに、log --graph が24秒もかかって、
これは使ってる人切れるだろ
今回の改善でこれがなんとか5秒になるわけだ

2018/06/30(土) 16:28:43.58

>>294
自分に都合のいいコマンドだけ取り出すとは苦しいね
>指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ
Gitについては言及なしかい？

2018/06/30(土) 16:45:16.91

>>295
Git のレポジトリが普通の規模のリポジトリ
コマンド1回あたり数百ミリ秒が数十ミリ秒になったって意味ない
だからほとんど影響無いって >>292で書いてる

俺にとって都合の悪いコマンドのことを書いてくれない？

2018/06/30(土) 17:20:25.83

>>296
どうやら数値が目に入らないようだ

2018/06/30(土) 17:26:41.23

>>296
お前が許容できるかどうかじゃなくて純粋に数値を見なさい
6秒近くかかってたのが1秒もかからなくなることに価値を見いだせないならこの業界向いてないよw

2018/06/30(土) 17:51:45.08

>>297-298
Linuxカーネルで6秒が1秒になったのなんて、Windowsリポジトリで24秒が5秒になったのに比べれば全然たいしたことないな
6秒を問題とするなら、Windowsリポジトリが5秒になったのなんて全然問題解決してないじゃん阿保かと

2018/06/30(土) 18:04:27.07

git使っててコマンドライン操作にこだわるのはいいけど
コミットグラフ意識してないひとマジでちゃんと勉強してほしい

2018/06/30(土) 18:17:49.02

なにをどう意識すりゃいいんだっけ？

2018/06/30(土) 18:21:22.82

>>300
意識したらどうなるの？

2018/06/30(土) 18:21:50.47

>>300
ちゃんとコマンドラインにこだわってる人は、
log --graph --branches --remotes --pretty=format:～
とかを使ってコミットグラフ表示を見てると思うけどね

2018/06/30(土) 18:35:18.00

>>299
阿呆はお前やろｗｗｗ
悔しかったらお前もGitのパフォーマンス改善してみれば？

2018/06/30(土) 18:38:07.46

>>299
これをたいしことないと思えるとはすごいな
仕事でもいまだにXPのRAM2GBとか使ってそう

2018/06/30(土) 19:09:03.95

>>305
巨大なレポジトリで頻繁に log --graph 見るようなときはローカルブランチで作業中とかなので、コミット範囲指定すれば一瞬で結果返ってくるし特に気にならない
いま試しにlinuxカーネルレポジトリクローンしてみたけど、master上だと確かに数秒かかるけど、ローカルブランチからならコミット範囲指定して一瞬だわ

2018/06/30(土) 19:25:00.31

ストップウォッチで6秒を誤差1秒以内で押せる人だけが、
速くなったすげーすげーと喜びなさい

2018/06/30(土) 19:35:18.92

pullするときにガンガンマージコミット作る人とかいるやん？
ちゃんと設定しといてほしい

2018/06/30(土) 19:44:02.17

>>308
何を？

2018/07/01(日) 12:15:12.44

>>309
git config --global --add merge.ff false
git config --global --add pull.ff only

2018/07/01(日) 13:21:15.23

>>310
その設定嫌いだから断る

2018/07/01(日) 16:05:21.27

addやcommitする際に特定の文字列が含まれているフォルダ以下を除外する方法を教えてください
datasets-XX、datasets-YYのようなフォルダを除外したいです

2018/07/01(日) 16:22:29.58

.gitignore じゃなくて？

2018/07/01(日) 19:59:41.54

.gitignoreに*datasets*と書いたんですけどadd *とやると無視してくれませんでした

2018/07/01(日) 23:12:13.45

>>311
この設定が嫌って、、
gitをSVNみたいに使ってるところとか？
こわい

2018/07/01(日) 23:20:32.85

>>315
押し付けがましい変な奴

2018/07/02(月) 00:33:57.45

>>314
すでにコミットされてるファイルが存在するフォルダは.gitignoreに追加しても無視できない
それをあえて無視したい場合には以下のどっちかを使うんだけど
git update-index --assume-unchanged
git update-index --skip-worktree
どっちを使うべきかは git update-index でググってみて

2018/07/02(月) 02:50:26.22

プロはgit pullなんか使わない

2018/07/02(月) 05:54:16.00

>>318
そんなこと言ってるやつがいたら、そいつはプロじゃない

理由が上から目線で馬鹿はミスするから使うなだったら
完全にアウト。自分（ミスした本人）が理解してない証拠

2018/07/02(月) 08:33:58.94

おれも普段はfetchとmerge使って
pullはffが確定してる特定条件でしか使わんなあ

2018/07/02(月) 09:37:34.88

fetchとmergeで済むならpullでいいだろｗ

2018/07/02(月) 09:50:53.90

例えばmvはcpとrm使ってやれるけど、mv使うでしょ？
それと同じだよ。楽な方使え

それにgitのよくある使い方は、pullしたブランチにコミットを追加するのではなく
新たにそこからブランチを切って作業する。
そしてpullしたブランチっていうのは通常他人の作業ブランチ。
だから他人がコミットを追加する。

つまり何が言いたいかというと
1. pullしたブランチは、他人の手によって成長する
2. 自分はそのブランチにコミットを追加しない
ということなんだから、ffは高い確率で確定している
多くの場合はgit pullでOK（--ff-onlyつけときゃffできないときエラーになる）

fetchしてmergeは、cpしてrmするのと同じで、無駄な作業をやってるだけ
そういうのは丁寧な作業でもなんでもないから

2018/07/02(月) 11:11:12.46

merge するときだけ fetch するわけじゃなくて、上流の状態を確認するために fetch は頻繁にやってるのよね
だから merge するときも、まず fetch してブランチの確認してから、問題なければ merge する手順でやる

あと >>322 は、今の一般的な git の使い方とは思えない
他人の作業ブランチをpullするとか自分のとこじゃかなりレアケースで、mergeするのはmasterなりdevelopとかの上流のブランチなことがほとんどだよ

2018/07/02(月) 12:07:23.83

mergeするのは
自分の作った自分だけがコミットするフィーチャーブランチを
他の人とも共有して使うブランチにマージする時、
っていうのが多いよね

フィーチャーブランチを作ったのがだいぶ前でも
コンフリクトがなさそうなときは
masterブランチのヘッドにリセットハードしてからフィーチャーブランチをマージ、
コンフリクトしまくる場合はいったんmasterブランチをフィーチャーブランチにマージしてコンフリクトを解決してからmasterブランチにマージ、
時間あるときはリベース
そんな感じじゃないの

2018/07/02(月) 12:37:42.51

>>324
だいたいそんな感じだけど、masterのヘッドにリセットハードってチェックアウトじゃダメなの？

2018/07/02(月) 12:58:12.03

>>325
実は>>324に書いてる方法はあまりやらず、本当はpullしない派なので、、
異端なのかな、、

fetchしまくって常にmasterブランチの動向を監視、
他の人の作業でmasterブランチが成長してきてmergeできなさそうになってきたら
再度フィーチャーブランチを作って
元のフィーチャーブランチの作業をすべてチェリーピック、
フィーチャーブランチの作業が終わればmasterブランチの先端に合わせて（リセットハードして）フィーチャーブランチをmerge
こんな感じ

2018/07/02(月) 14:12:01.33

>>323
> 他人の作業ブランチをpullするとか自分のとこじゃかなりレアケースで、mergeするのはmasterなりdevelopとかの上流のブランチなことがほとんどだよ
master、developも含めて、他人だよ。

masterやdevelopに自分が直接コミットすることはない。
このブランチからはgit pullするだけ。
そしてそれは常にffになる。ffにならないのは異常事態
誰かがとんでもないミスをしたということ

ffになったかどうかはgit pullのログ見てればわかることだし
--ff-onlyつけてれば、ff以外は弾かれる

つまりは、あんたは
fetchして問題ないか"毎回"確認してmergeしてる
俺はgit pullして"問題があったときだけ"確認してる

2018/07/02(月) 14:26:56.91

俺の場合

> fetchしまくって常にmasterブランチの動向を監視、
git pullしまくって常にリモートのmasterに
ローカルのmasterを追尾

masterが変更されるたびに、
フィーチャーブランチをgit rebase master
マージできる場合は、git rebase masterは成功する
コンフリクトが起きればマージできないということ
「mergeできなさそう」なんて曖昧な判断はいらない
コンフリクトを解決すれば、当然またマージできるようになる

ただしプルリク出したあとは、他の誰かがレビューしたってことなので
その作業が無駄（分かりづらく）にならないようにmasterをマージする方法に切り替える
（masterをマージすることで逆に分かりづらくなる場合はgit rebase masterする場合もある）

2018/07/02(月) 14:30:09.48

>>326に書いてある

> 再度フィーチャーブランチを作って
> 元のフィーチャーブランチの作業をすべてチェリーピック、

git rebase master一発で↑これ相当のことをやってることになる

>>326はmergeできなさそうになったらやると言ってるが、
俺はmasterが変更になるたびにやってる。
git rebase masterならそれが可能。しかも簡単。

2018/07/02(月) 15:06:13.90

>>327
別にpullが失敗するかどうかだけを確認してるわけじゃない

masterからブランチ切るときとか、masterにマージするときには、origin/masterの状況がどうなってるか確認したいからまず fetch する

2018/07/02(月) 15:07:13.34

>>328
fetch はフィーチャーブランチがカレントブランチのままできる

いちいち master を checkout して pull しまくるとかマゾなの？

2018/07/02(月) 15:09:33.33

>>331
じゃあお前どうやってんの？

2018/07/02(月) 15:10:25.75

あ、なんだ。masterをfetchしまくってるマゾだったかｗ

2018/07/02(月) 15:12:01.47

ごめん。masterをfetchしてmergeしまくってるマゾだったねｗ
絶対ffは成功するのに、わざわざfetchして確認（何を？ｗ）してから
mergeしてご苦労さんｗ

2018/07/02(月) 15:20:43.68

fetchはカレントブランチに関係無く、すべての上流ブランチ取り込めるの知らないの？

2018/07/02(月) 15:24:39.46

>>335
え？まさか、masterにcheckoutする作業、
つまりgit checkout masterって叩くのが面倒って
だけの話をしてるの？
え？まじでコマンド操作が苦手なだけってオチ？

2018/07/02(月) 15:25:32.61

カレントブランチ変更はいろいろ面倒だから頻繁にはやりたくないけど、
originの状態は常に把握しておきたいから fetch を使う
そして fetch 済みなら pull 使う必要もない
これだけのこと

2018/07/02(月) 15:30:11.71

>>336
お前ほんとにgit 使ってプログラム書いてる？
コミットしてないファイルとか整理せずに checkout いきなりすんなよ

2018/07/02(月) 15:34:27.49

あと自動ビルドとか文法チェックとかcheckout 契機にはじまってしまうからな
頻繁にはやりたくない

2018/07/02(月) 15:34:59.30

>>337
うわｗｗｗ
ローカルにリモートのブランチを持ってこないとか言い出した。
そうかお前、ローカルのmasterブランチないんだね。リモートのmasterしかないんだね。
すげー変な使い方ｗ

>>338
コミットすりゃいいじゃん。
他にもstashすればいいし
何いってんの？gitの使い方知らないの？

2018/07/02(月) 15:36:10.00

>>339
> あと自動ビルドとか文法チェックとかcheckout 契機にはじまってしまうからな

自分で間違った使い方した上に、
自分で自分の首を絞め、
そして自分に文句を言ってる図ｗ

2018/07/02(月) 15:37:59.89

checkout時に、自動ビルドや文法チェックなんて
する間抜けはまずいないから、ネットでググったら
すぐこいつ見つけられそうｗ

2018/07/02(月) 15:40:51.79

>>340
>>337のどこにローカルにリモートブランチ持ってこないなんて書いてあるんだ？
必要なときにはローカルに反映させるが、それを頻繁にはやらない

2018/07/02(月) 15:45:52.53

>>342
IDEが自動ビルドとか文法チェックやってる
checkout して内容変われば当然やり直す

IDEじゃなくてもバックグラウンドでそういう監視プロセス動かすことも多い

2018/07/02(月) 15:47:54.07

>>340
リモート確認するためにstash やコミットするとか
やっぱりマゾか

2018/07/02(月) 16:40:10.67

pull じゃなくて fetch しておくとどんな差分が落ちてきたか diff origin/master とかで見れるから便利だったりするお

2018/07/02(月) 20:20:10.71

自分の作ったフィーチャーブランチすら複数同時並行で作業が進むことだってよくあるんだから
いちいちローカルのmasterブランチの位置がリモートと比べてどうなってるかチェックしたってよくない？

2018/07/02(月) 22:15:33.22

>>347
したってよいの？

2018/07/02(月) 22:31:54.58

よいよね

2018/07/02(月) 22:36:51.87

fetchに課金されるわけじゃないんだから好きにしたらいい

2018/07/03(火) 09:52:17.03

>>345
リモート確認すればいいだけでは？

2018/07/03(火) 10:30:06.33

ギットハブには来ない
投げっぱなしの外注先
branchもない
mergeできない

2018/07/03(火) 12:19:50.29

git使ってプログラムかいてるだってwプププw

2018/07/03(火) 12:32:09.53

gitを使うことが目的になってる人たちがいるからレスバトルで荒れるね

2018/07/03(火) 15:11:35.13

たとえ荒れてても建設的な議論が出来ればそれでいい

2018/07/03(火) 17:26:46.66

でも残念ながらくだらないマウントの取り合いなんだよね

2018/07/03(火) 22:22:22.03

>>356
おまえいつもくだらないマウント取られてるよなwアホなん？

2018/07/04(水) 01:33:58.31

>>352
山下達郎来た

2018/07/04(水) 09:23:58.32

これまでひとりでプログラムかいてたのでバージョン管理ツールを使ったこと無く
チーム開発業務でgitを使うことになったのでいくつか質問させてください

ブランチ　チェックアウト　コミット　プッシュ

の流れでやってくださいとはいわれたんですが
それぞれがリモートローカルどっちで何がおこるか正確にわかってなくて
万一社内のファイル破壊したら怖いので
対応するコマンドとリモートローカルどっちにどんな影響があるか知りたいんですが

gitの使い方を説明するブログってまずローカルにファイルを作ってプッシュするところからはじめてるものばかりなんですが
最初からリモートに社内のファイルがあってそれを更新する場合initは不要なのでしょうか

cloneはread onlyでbranchではなくリモート側に何の影響もないであってますか？

branchはローカルで行うものでリモートには影響はあたえませんか？

デバッグ等には設定ファイル等複数のファイルを更新するんですが
最終的にリモートに反映させるファイルを１つだけにすることって可能でしょうか

その場合どの段階でどうやってファイルを限定すればいいのでしょうか

あとBitBucketっていうアカウントを作るよう指示されたんですがGitとはどういう関係があるんでしょうか
リモートのおき場所を提供してるクラウドサービスぐらいの認識で
すでに社内ファイルがおかれてる場合はウェブ上の作業は必要なく
ローカルでgitコマンドを叩くだけで大丈夫でしょうか？

具体的にコマンド含めて教えていただけるとありがたいです
初歩的な質問ですいませんがよろしくお願いします

2018/07/04(水) 09:28:04.47

>>359
プッシュさえしなければ何してもOK
プッシュする前に何をプッシュしようとしてるのか必ず確認すること

2018/07/04(水) 09:34:19.76

branchやcheckoutを行っただけでは
リモート側にはそれを行ったことすら通知はされないってことで大丈夫でしょうか？
間違って（必要のないファイルまで）branchやcheckoutをしても
やり直したり取り消したりすることはできるということでしょうか？

2018/07/04(水) 09:44:13.84

>>361
プッシュさえしなければ何してもOK
プッシュせずにいろいろ試してみて

2018/07/04(水) 09:47:47.96

すばやい返答ありがとうございます
とりあえずコミットまですすめて
pushするときだけリーダーに確認とってみます

2018/07/04(水) 21:56:02.05

BDR

2018/07/05(木) 09:32:00.00

リモートブランチとローカルブランチの使い分けについて教えてください。
よく推薦されているブランチとしてmaster、develop、feature、release、hotfixがありますが、これは全部リモートブランチに作るものなんでしょうか。
例えばf1という機能追加を行いたい場合、どのようなフローになるのが適切でしょうか。
・masterからdevelop/d1をブランチ
・develop/d1からfeature/f1をブランチ
・改修
・feature/f1をdevelop/d1にマージ
・develop/d1からrelease/r1をブランチ
・リリース作業
・release/r1をmasterにマージ

上記で問題ない場合、普通に使う分にはローカルブランチの出番がないように思えます。
そもそもfeatureブランチはローカルに作るものだったりするのでしょうか。

GitHubとかのWebサービスは使わずに自社内完結で開発者10人以下のプロジェクトです。