X

Git 16©2ch.net

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 転載ダメ©2ch.net (ｴｰｲﾓ SE4a-N0rP [1.114.6.147])
垢版 |
2017/08/15(火) 00:54:07.61ID:brNIopECE
ソースコード管理を行う分散型バージョン管理システム、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
0238デフォルトの名無しさん (ﾜﾝﾄﾝｷﾝ MM52-7qxP [153.147.204.171])
垢版 |
2018/06/09(土) 20:07:09.85ID:54mp5fzVM
ローカルなリポジトリならなんでもいいからgitlab固有のメリットではないかな
gitlabは多機能だから他のサービスを乱立しなくても開発環境を作れるのが便利(jenkinsやめてgitlab-ciなど)
あとはブランチのアクセスコントロールは便利だと思う
本当はSVNみたいにサブディレクトリ単位でアクセスコントロールしたいけど…
0239デフォルトの名無しさん (ｴﾑｿﾞﾈ FFc2-MvoD [49.106.188.51])
垢版 |
2018/06/11(月) 10:48:33.34ID:tK3aH3wFF
社内とか部署内専用でやるならgit単独で充分
0244デフォルトの名無しさん (ﾜｯﾁｮｲ 9b23-MvoD [122.215.159.99])
垢版 |
2018/06/12(火) 16:48:02.14ID:bLF3+6cr0
単にどこまで戻るかっていうより
失敗したとこまで戻ってやり直しても
それ以降の上手く行ってる部分はそのまま継続したいっていう
みんなが持ってる願望
0245デフォルトの名無しさん (ﾜｯﾁｮｲ 9ba5-Bw3Y [114.145.153.21])
垢版 |
2018/06/17(日) 14:20:59.87ID:5vfOsDgm0
Git で使っている、SHA-1だけど去年位からそろそろやばいっていう感じになってきて、
object_id っていう感じで切り出しを進めていたんだけど、次の2.18 でほぼ外出しできる模様。

次の次ぐらいで、SHA-1を置き換える動きが加速するかもね。
0254デフォルトの名無しさん (ﾜｯﾁｮｲ cda5-GwbS [114.145.153.21])
垢版 |
2018/06/25(月) 22:22:27.55ID:7fjVRnvb0
Introducing Git protocol version 2
Friday, May 18, 2018
https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html

git 2.18 から protocol v2 の機能が入ってきた模様。

1) Server-side filtering of references
2) Easy extensibility for new features like ref-in-want and fetching and pushing symrefs
3) Simplified client handling of the http transport
0261デフォルトの名無しさん (ﾜｯﾁｮｲ 3d23-kvBu [122.215.159.99])
垢版 |
2018/06/26(火) 18:41:01.36ID:ZJbD0Mnn0
powershell化するん
0267デフォルトの名無しさん (ﾌﾞｰｲﾓ MM43-AhjV [49.239.67.75])
垢版 |
2018/06/27(水) 00:23:55.22ID:+AZ8QKRkM
>>266
今時のIDEなら、ソースの編集画面で、行が修正されてたかどうか表示があるよね？

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

全体的に、ソースの編集が、ファイルを編集するのじゃなくて、コミットを編集するイメージでできちゃうのがいい
0270デフォルトの名無しさん (ﾌﾞｰｲﾓ MM43-AhjV [49.239.65.228])
垢版 |
2018/06/27(水) 10:20:54.35ID:YqT9Fk5fM
VSは、ファイルシステム上のソースを編集するIDEに、レポジトリを操作する機能を追加しただけ
Android Studioはレポジトリ上のソースを直接編集するIDEになりつつある

前者が一周遅れているのを酷く見劣りすると表現した
後者はニッチなんかじゃなくて、これからIDEの基本的機能になるよ
0280デフォルトの名無しさん (ﾌﾞｰｲﾓ MM43-HtAK [49.239.64.15])
垢版 |
2018/06/27(水) 17:09:02.20ID:osq4knhsM
底辺には必要ない機能
0291デフォルトの名無しさん (ｱｳｳｨﾌ FFa1-GJJ6 [106.171.73.36])
垢版 |
2018/06/30(土) 14:13:16.44ID:QJJEkoJ9F
>>288
thx!
0292デフォルトの名無しさん (ﾜｯﾁｮｲ cd2b-6D2o [116.81.170.118])
垢版 |
2018/06/30(土) 14:36:14.41ID:+q6tlra70
>>288
この改善は、普通の規模のリポジトリにはほとんど影響無い

モジュール分けしてなくて馬鹿みたいにでかい原始的なWindowsのリポジトリをそのままGitで管理するようにしたら、log --graph の表示が遅すぎて使い物にならなくなって、しょうがないから git に対策入れたって話
0294デフォルトの名無しさん (ﾜｯﾁｮｲ cd2b-6D2o [116.81.170.118])
垢版 |
2018/06/30(土) 16:03:54.28ID:+q6tlra70
>>293
指標にしてるのはWindowsとLinuxカーネルのリポジトリ両方だろ

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

それにくらべて、WindowsリポジトリはGVFS使ってチートしてるのに、log --graph が24秒もかかって、
これは使ってる人切れるだろ
今回の改善でこれがなんとか5秒になるわけだ
0299デフォルトの名無しさん (ﾜｯﾁｮｲ cd2b-6D2o [116.81.170.118])
垢版 |
2018/06/30(土) 17:51:45.08ID:+q6tlra70
>>297-298
Linuxカーネルで6秒が1秒になったのなんて、Windowsリポジトリで24秒が5秒になったのに比べれば全然たいしたことないな
6秒を問題とするなら、Windowsリポジトリが5秒になったのなんて全然問題解決してないじゃん阿保かと
0306デフォルトの名無しさん (ﾜｯﾁｮｲ cd2b-6D2o [116.81.170.118])
垢版 |
2018/06/30(土) 19:09:03.95ID:+q6tlra70
>>305
巨大なレポジトリで頻繁に log --graph 見るようなときはローカルブランチで作業中とかなので、コミット範囲指定すれば一瞬で結果返ってくるし特に気にならない
いま試しにlinuxカーネルレポジトリクローンしてみたけど、master上だと確かに数秒かかるけど、ローカルブランチからならコミット範囲指定して一瞬だわ
0313デフォルトの名無しさん (ｱｳｳｨﾌ FFa1-mzC7 [106.171.82.190])
垢版 |
2018/07/01(日) 16:22:29.58ID:ep584YMHF
.gitignore じゃなくて？
0317デフォルトの名無しさん (ﾜｯﾁｮｲ cd2b-6D2o [116.81.170.118])
垢版 |
2018/07/02(月) 00:33:57.45ID:kpcF7b8m0
>>314
すでにコミットされてるファイルが存在するフォルダは.gitignoreに追加しても無視できない
それをあえて無視したい場合には以下のどっちかを使うんだけど
git update-index --assume-unchanged
git update-index --skip-worktree
どっちを使うべきかは git update-index でググってみて
0322デフォルトの名無しさん (ﾜｯﾁｮｲ f598-yQv9 [114.170.106.140])
垢版 |
2018/07/02(月) 09:50:53.90ID:zKK+kKI/0
例えばmvはcpとrm使ってやれるけど、mv使うでしょ？
それと同じだよ。楽な方使え

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

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

fetchしてmergeは、cpしてrmするのと同じで、無駄な作業をやってるだけ
そういうのは丁寧な作業でもなんでもないから
0323デフォルトの名無しさん (ﾌﾞｰｲﾓ MM71-Yrxd [210.149.250.145])
垢版 |
2018/07/02(月) 11:11:12.46ID:cyzwZYxBM
merge するときだけ fetch するわけじゃなくて、上流の状態を確認するために fetch は頻繁にやってるのよね
だから merge するときも、まず fetch してブランチの確認してから、問題なければ merge する手順でやる

あと >>322 は、今の一般的な git の使い方とは思えない
他人の作業ブランチをpullするとか自分のとこじゃかなりレアケースで、mergeするのはmasterなりdevelopとかの上流のブランチなことがほとんどだよ
0324デフォルトの名無しさん (ﾌﾞｰｲﾓ MM61-Ajo2 [202.214.230.221])
垢版 |
2018/07/02(月) 12:07:23.83ID:RTcL8EDCM
mergeするのは
自分の作った自分だけがコミットするフィーチャーブランチを
他の人とも共有して使うブランチにマージする時、
っていうのが多いよね

フィーチャーブランチを作ったのがだいぶ前でも
コンフリクトがなさそうなときは
masterブランチのヘッドにリセットハードしてからフィーチャーブランチをマージ、
コンフリクトしまくる場合はいったんmasterブランチをフィーチャーブランチにマージしてコンフリクトを解決してからmasterブランチにマージ、
時間あるときはリベース
そんな感じじゃないの
0326デフォルトの名無しさん (ﾌﾞｰｲﾓ MM71-Ajo2 [210.138.6.113])
垢版 |
2018/07/02(月) 12:58:12.03ID:hdADTtxTM
>>325
実は>>324に書いてる方法はあまりやらず、本当はpullしない派なので、、
異端なのかな、、

fetchしまくって常にmasterブランチの動向を監視、
他の人の作業でmasterブランチが成長してきてmergeできなさそうになってきたら
再度フィーチャーブランチを作って
元のフィーチャーブランチの作業をすべてチェリーピック、
フィーチャーブランチの作業が終わればmasterブランチの先端に合わせて（リセットハードして）フィーチャーブランチをmerge
こんな感じ
0327デフォルトの名無しさん (ﾜｯﾁｮｲ f598-yQv9 [114.170.106.140])
垢版 |
2018/07/02(月) 14:12:01.33ID:zKK+kKI/0
>>323
> 他人の作業ブランチをpullするとか自分のとこじゃかなりレアケースで、mergeするのはmasterなりdevelopとかの上流のブランチなことがほとんどだよ
master、developも含めて、他人だよ。

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

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

つまりは、あんたは
fetchして問題ないか"毎回"確認してmergeしてる
俺はgit pullして"問題があったときだけ"確認してる
0328デフォルトの名無しさん (ﾜｯﾁｮｲ f598-yQv9 [114.170.106.140])
垢版 |
2018/07/02(月) 14:26:56.91ID:zKK+kKI/0
俺の場合

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

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



ただしプルリク出したあとは、他の誰かがレビューしたってことなので
その作業が無駄（分かりづらく）にならないようにmasterをマージする方法に切り替える
（masterをマージすることで逆に分かりづらくなる場合はgit rebase masterする場合もある）
0329デフォルトの名無しさん (ﾜｯﾁｮｲ f598-yQv9 [114.170.106.140])
垢版 |
2018/07/02(月) 14:30:09.48ID:zKK+kKI/0
>>326に書いてある

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

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

>>326はmergeできなさそうになったらやると言ってるが、
俺はmasterが変更になるたびにやってる。
git rebase masterならそれが可能。しかも簡単。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況