Git 16©2ch.net

レス数が900を超えています。1000を超えると表示できなくなるよ。
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
804デフォルトの名無しさん (ｱｳｱｳｴｰ Sa7a-uHRg [111.239.44.76])
垢版 |
2019/10/19(土) 02:43:29.64ID:u6kJNe82a
>>800
だよな

>>803 >>798
https://hayabusa9.5ch.net/test/read.cgi/news/1571409806/
2019/10/21(月) 18:36:15.95ID:f5UjoAUh0
masterからdevelopブランチを切って、ローカルではdevelopからfeatureブランチ切ってそれをいじる
developにマージしてdevelopをプッシュする。不要になったfeatureは削除する
っていう一連の流れを勉強したんだけど、しまったここの関数ちょっとおかしいとかそういうほんとちょっとした変更でもいちいちfeature作るって作業はしたほうがいいの？
あんまり意味が無いような気が
2019/10/21(月) 19:05:05.50ID:QGk2ZXW40
チーム開発なら必要。必ずコードレビューするから、ローカルでdevelopへのmergeなんてしない。
2019/10/21(月) 21:35:01.75ID:f5UjoAUh0
なるほど
二人だけのチームで多分コードレビューなんてしもしないと思うんですけどその場合でも必要ですかね
あとfeatureブランチはリモートにはプッシュしないっていう認識で大丈夫ですか
2019/10/21(月) 21:52:05.56ID:QGk2ZXW40
featureの扱いというよりは、developへのmergeをどこでするか統一しておかないと、各々の環境でdevelopの履歴が分かれていくやろ
2019/10/21(月) 21:54:28.50ID:QGk2ZXW40
featureをリモートにpushして、コードレビューおよびdevelopへのmergeをおこなうのが一般的。ローカルのdevelopは、基本的にfetch or pullとfeatureの作成用途のみ。
2019/10/21(月) 22:39:49.24ID:f5UjoAUh0
むぅそもそもリモートで作業するってのが考えてなかったというかその辺りよくわからないですね
>>796なんですがリモートリポジトリってローカルで作業していったものをどんどん突っ込んでいくものという認識です
ちょっと勉強が足りなかったようです
2019/10/21(月) 22:47:28.39ID:QGk2ZXW40
普通はGitHubやGitLabみたいなホスティング環境を用意するからね
2019/10/22(火) 10:33:39.48ID:97MNeVVfr
2人に閉じた開発なら結合後にdevelopだけでごりごり開発してもいいよ
いつの間にか気持ち悪いマージコミットが多数生じるだろうけど
気持ち悪いと感じる人がいないならそれはそれで
2019/10/23(水) 03:06:06.75ID:gUefB5900
マージコミットも歴史の一環なんだから、必要と思う派だな俺は
2019/10/23(水) 05:29:04.43ID:rbcKcx270
マージコミットが気持ち悪いとか意味分からん
2019/10/23(水) 09:07:03.10ID:9MFdyPJfa
developからdevelopへのマージコミットがキモいということでは
2019/10/23(水) 09:08:03.44ID:dAk3xzay0
コミットツリーの美しさとかにこだわりが
ある人がいるらしい
2019/10/23(水) 09:20:06.84ID:9MFdyPJfa
それは海外の有名OSSでもわりといる
俺は個人的には全く気にしないけど
2019/10/23(水) 12:55:24.68ID:/Xl5BrJYr
>>815
そうそれ

マージコミットのあいだにも価値の多寡があるということ
歴史としての価値があるからこそノイズが多いと経緯を追い難くなる
そこを一切否定するならrebaseコマンドの存在意義も(ほぼ)否定することになる
2019/10/23(水) 13:35:25.15ID:9MFdyPJfa
気持ちはよくわかるが、pull requestベースでの開発だとコミットはあまり気にしなくなるよね
それよりcherry-pick厨はマジで○んでくれ
2019/10/24(木) 21:55:43.84ID:tJ6qR8Ubp
10人くらいのオフィスで現状何でもかんでもnasに突っ込んで管理してます
HTMLやらcssやらのファイルだけでなく、画像データやofficeやAdobe系のファイル諸々、トータルで2テラくらいあるんですが、git使った方がいいですかね？
2019/10/24(木) 22:37:22.25ID:X5jN+DYs0
Git v2.24.0-rc1

sparse-checkout　は2.24には入らない模様
2019/10/25(金) 00:29:24.66ID:pN2Np6rx0
>>820
あほ
2019/10/25(金) 02:19:18.84ID:NkkYeDGn0
>>820
賢い
2019/10/26(土) 04:05:16.93ID:5CwD3uct0
>>820
バイナリはあんまりメリットないと思うぞ
2019/10/30(水) 19:20:40.44ID:9OqgeVS50
Git v2.24.0-rc2
2019/10/31(木) 12:45:58.96ID:am2tAoCwa
>>825
rc0のバグが二件MLに投げられてたけど、
rc2では一件しか反映されてなくて、
ds/commit-graph-on-fetchは反映されてなかったので、
cookingのリプライで、この件はa corner caseでは無いってメールが投げられてる。

rc3が出そう。
2019/11/01(金) 18:52:14.66ID:iiwBdpI/0
うっかりデバッグする前にコミットしちゃったときに限ってデバッグするとバグが出るのはなぜなのか・・・・・・
828デフォルトの名無しさん (ｱｳｳｨﾌ FFb7-0B+f [106.171.80.130])
垢版 |
2019/11/01(金) 19:24:18.43ID:4VV6x0MuF
うっかりコミットしてもpush前ならなんとでもなる
2019/11/01(金) 22:53:41.80ID:e5+N+yHPM
バグがでたらその場でコミットするすらある
その後確実に直したかを確認できるように
2019/11/02(土) 11:55:22.78ID:KQBO0phR0
コミットはなんぼでもするでしょ
プッシュでさえみんなと共有してないブランチでなら構わずやることすら多々ある
2019/11/04(月) 15:43:58.15ID:c4+jomAP0
Git v2.24.0
2019/11/08(金) 20:10:08.64ID:0FK18fPT0
visual studioで使ってるけど本当に便利すぎて手放せないわもう
例えコミット細かくやりまくってもうどこで何をやったか履歴でよく分かんなくなっても関数の上に変更回数が出てしかもどのコミットだったかとかすぐ分かる
ありがてぇありがてぇ
2019/11/08(金) 23:58:01.51ID:0O3F1Ost0
>>832
おお！それ便利そうだな
2019/11/09(土) 00:33:45.05ID:18eViK1od
visual studioはやっぱり便利なIDEだよ
2019/11/16(土) 12:06:04.07ID:Hu173AQfa
VSってSVN統合はサポートしてないんだっけ？
2019/11/21(木) 21:00:22.52ID:qyUyDCEb0
新コマンドの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.17ID:gnIUHiL60
githubでプルリクをマージする人ってプルリクを送った側と受け取った側とでどちらが良いんでしょうか
個人的にはプルリクって、もしこの修正が問題なければ取り込んでくださいって意味だから
受け取った側が承認してマージまでするのが自然な形だと思うんですが、
なぜか今の職場ではプルリクを送った側が自分でマージするルールになっています
私がおかしいのでしょうか
2019/11/24(日) 13:34:18.60ID:GHgHXRJi0
>>837
そういうルールもありだと思う
承認する人が多忙だとその方が仕事が早いし
2019/11/24(日) 14:06:11.79ID:yrLXmC4Sa
それってアクセスコントロールしてない無秩序状態ってことだろ？
頭のおかしい開発者が勝手にマージしはじめたらめんどうだ

承認者とマージ実行者を別にするのはよろしい
マージ実行者を開発者全員にするのはよろしくない
2019/11/24(日) 14:19:50.78ID:80bKErqg0
それだってケースバイケースだろう。
たしかに頭のおかしい開発者が存在する場合はいろいろ考慮が必要だろうが。
2019/11/24(日) 17:03:56.66ID:gnIUHiL60
オープンソースのプロジェクトにプルリク送る場合って受け取った側が承認してマージまでするじゃん
githubを作った人の想定では、プルリクを受け取った側がマージするのが正しいんだと思うんですよね
ていうか自分で送り付けて（プッシュ）おいて、自分でマージするってことはそれはもう"プル"リクエストではなくて、
"プッシュ"リクエストじゃないんですかね
githubを作った人の想定通りに素直に使うのが自然で良いと思うんです
2019/11/24(日) 18:06:33.20ID:Af51XfXf0
開発効率を上げるとかバグを減らす為にルールを作るので
ルールを守るためにルールがあるのじゃない
2019/11/24(日) 18:15:15.68ID:gnIUHiL60
プルリクを送った側がマージすると開発効率が上がったりバグが減るんですかねちょっとわかりませんね
2019/11/24(日) 18:22:14.13ID:80bKErqg0
ここまでくるとちょっとウザい。
あんたの疑問はもっともだと思うからあとは職場の人とよく話し合ってくれ。
2019/11/24(日) 18:48:23.85ID:Af51XfXf0
どこにも書いてないこと言い出して逆ギレしてるようでは
かなりお荷物さんだろうねえ
2019/11/24(日) 21:03:03.40ID:gnIUHiL60
は？お前が死ね
2019/11/24(日) 22:15:27.62ID:Ak7CJVWZ0
社内に頭のおかしい人なんてそうそういないだろと思ったけど
こういうレスを見ると自信なくなる
最初の質問「私がおかしいのでしょうか」については
そうかもねと答えざるを得ない
2019/11/24(日) 22:23:39.72ID:siCmeb1h0
どんな解釈をしたら、お前”が”し ねになるのか分からない笑
君の質問は正しいよ、あなたがおかしい。
2019/11/27(水) 00:29:11.38ID:khFiWnk90
>>839
職場に頭がおかしい人がいるならgitで解決しようとしてる場合じゃない
2019/11/27(水) 02:07:52.53ID:yfCQIaSa0
私がおかしいのでしょうかと質問する人は大体周囲が見えてない自己中なので、何言っても無駄
2019/11/28(木) 00:29:54.88ID:pkrpUq4n0
お前の書き込みなんか何の価値もねえわ
向いてないから死ね
2019/11/28(木) 08:00:02.37ID:ASrVgGrO0
おお、マジで周囲が見えてない
ムダだったな
2019/11/28(木) 11:24:04.68ID:6K3wKFKj0
TortoiseGitのグラフ表示時矢印が古い方を指すように下向きに
なった。2.9.0　設定何か触ったかな　
2019/11/30(土) 06:10:34.31ID:38g5kEkf0
変更のない同一ファイルのときに

git commit -am “こめんと”

を打つとエラーになるけど、エラーを回避するコマンドとか無いかな？
もしくは更新・差分があったときのみcommitするようなパラメータとか
2019/12/10(火) 08:57:29.10ID:dElUWZFip
>>854
>もしくは更新・差分があったときのみcommitするようなパラメータとか
まさにこれがデフォルト動作だからエラーになってるんでは
更新・差分はないが直前のコミットメッセージを直したいということなのであれば git commit --amend -m "こめんと" すれば良い
2019/12/10(火) 14:02:57.28ID:wVKwLmOg0
--allow-empty でいいんじゃね
2019/12/11(水) 08:48:33.72ID:dTsaAtPFa
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.51ID:hsVb1UYsa
Git v2.25.0-rc0
2020/01/14(火) 14:04:10.95ID:4wHv5Np1a
Git v2.25.0

リリース直前にgit rebace -iの機能を巻き戻した模様。
2020/01/14(火) 19:51:55.90ID:XYlwauc30
「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.64ID:vNXxsU5/a
>>836
2.25に入りましたね
2020/01/15(水) 14:10:39.53ID:HHc8tRS5a
大体ググって覚えて使ってる個人の感想としては、
ざっくり『addしてcommitしてpush、後はbranch作ってなんか切ったり結合したり出来れば大体なんとかなる』というノリでgit使ってるんですな何か他に知っておいた方が良い操作とかあるんでしょうか？
ブランチ名やコミットメッセージを付ける等の補助的なオプションに関する知識は勿論前提として。
863デフォルトの名無しさん (ﾜｯﾁｮｲ a57c-otum [122.215.159.99])
垢版 |
2020/01/15(水) 14:17:31.11ID:4xMdZPyq0
壊れた時の治し方
2020/01/15(水) 15:53:47.54ID:lrragII8r
初期に便利だと思ったのは
stash
ignoreのバリエーション
skip-worktree
reset
reflog
あたりかな
865デフォルトの名無しさん (ﾜｯﾁｮｲ e3ad-NcMA [27.139.41.170])
垢版 |
2020/01/15(水) 18:52:02.01ID:5FatvImR0
stashなんか怖くて別の場所にチェックアウトしちゃう
2020/01/15(水) 19:33:55.68ID:351mhBoi0
>>862
何をおいてもgit rebase。これ使わないとgitの価値が無いと言ってもいいぐらい
2020/01/15(水) 20:55:58.51ID:LnXb7RmRM
ちょっと違うけど、vcodeのアドオンにあるgitのdiffとかhistoryを見る機能は便利。
2020/01/15(水) 23:01:29.73ID:T10o2wrU0
rebaseとか未だに有用性が理解できない
2020/01/15(水) 23:04:03.22ID:k9iUnicj0
はちゃめちゃに大きくなったリポジトリの整理でgc, filter-branchなんかは使わなきゃいけないときがあるね。
大体開発もクライマックスで泣きながらやる羽目になるイメージがあるけど。
2020/01/16(木) 08:30:24.22ID:Q/Kq6WCRa
>>868
神経質でええカッコしいの俺にとっては重要機能
2020/01/16(木) 13:31:27.65ID:G3KWlD+Dd
rebaseは-i以外めったに使わないな
2020/01/16(木) 21:01:11.48ID:J+/qaxiI0
遅くなりましたが皆さんありがとうございます、なんとなく枝を繋げればいいや
というイメージでしたがリセット機能や消去機能こんなに充実してるんですね。
正直広まってる理由オープンかつコストが掛からない上有名なソフトが集まっているから
だと思ってたんですが、コマンドで大体できるしGUIも綺麗ですしそこらのソフトウェアが
内蔵してる管理機能より遥かに有用なことを色々聞いて実感しました。
2020/01/18(土) 19:37:12.70ID:gdI50zyB0
masterブランチをpullし忘れてmergeがめんどくさくなる時あるんですが、どうすればいいですかね？
874デフォルトの名無しさん (ｱｳｳｨﾌ FF21-otum [106.171.73.72])
垢版 |
2020/01/19(日) 13:01:12.04ID:ehZNNwbSF
rebase
2020/01/20(月) 20:23:44.70ID:egaGjlTX0
>>873
pullを忘れない
2020/01/20(月) 21:58:48.20ID:DbNr2/Ajr
rebaseは下手すると似たところで何度も競合して余計面倒になるような
2020/01/20(月) 22:06:36.16ID:hWOi4sNW0
mergeがめんどくさくなった時点で気付くだろうからそこでやり直せばいい。
2020/01/27(月) 22:52:01.17ID:eRzXcwZO0
patch
2020/02/16(日) 11:10:07.51ID:v4WmcUGja
gitでファイル分割ってどうすりゃいいんだ

//old.cs
class Foo {...}
class Bar {...}

↑これを↓こうしたい

//foo.cs
class Foo {...}

//bar.cs
class Bar {...}


git mv old.cs foo.cs
cp foo.cs bar.cs
git add bar.cs
git commit
vim foo.cs # class Barを削除
vim bar.cs # class Fooを削除
git commit

これだとFooは履歴を辿れるけどBarは履歴を辿れないので困る
880デフォルトの名無しさん (ﾜｲｰﾜ2 FF3a-BDVY [103.5.142.120])
垢版 |
2020/02/16(日) 11:46:34.81ID:nYOrfTm7F
https://stackoverflow.com/questions/47401843/git-copy-file-as-opposed-to-git-mv
https://stackoverflow.com/questions/16937359/git-copy-file-preserving-history
https://thinca.はてなぶろぐ.com/entry/20090217/1234799036
2020/02/17(月) 19:49:42.59ID:uNPszME30
初歩的な質問で申し訳ないんだけど教えてください
今小さなプロジェクトを個人で動かしてて、部署のファイルサーバの自分のフォルダにリモートリポジトリを置いて、visual studioでコミットしてプッシュしてみたいな単純な使い方してます
それで今度チームでやることになってgithubとかgitlabとかの導入を考えているのですがプルリクエストというのがよく分かりません
色々サイト見ているのですがプッシュしたあとにプルリクエストを作成して……みたいなこと書いているんですが、プッシュしたらリモートリポジトリ変更されちゃいますよね？
プルリクエストされた担当者がコードをチェックするならプッシュの前じゃないといけないのではと思うのですが
よろしくおねがいします
2020/02/17(月) 19:59:10.01ID:TyLv2qwpd
ブランチの概念も知らないとみた
2020/02/17(月) 20:37:06.60ID:y136Nw0W0
>>881
別ブランチにコミットしたものをpushするんだよ。
んでもってそのブランチに対してプルリクエストする。
2020/02/17(月) 20:58:00.67ID:+X1gGa0lM
o - o - o - o <- ローカル/master, リモート/master
\ o - o - o <- ローカル/ブランチ1

ローカル/ブランチ1をpushするんだよ。
ブランチの切り方はgit branch --help見てね。
チーム開発の記事を読んでおくといいかもね。
ブルリクについてはgithubとかの開発について調べてみるといいよ
2020/02/17(月) 22:08:10.05ID:eqxbKRrg0
Git 2.25.1
2020/02/17(月) 22:41:22.23ID:uNPszME30
>>883-884
あぁぁそういうことですか。あ、いや自分でやってるときはgithub flowでしたっけ。masterとdevelop切ってそこからfeature切ってみたいなやり方してたんですけど
>>884だとリクエスト受けた側がmasterにマージする感じになってますけどmasterって製品版だからあまりいじっちゃまずいんじゃありませんでしたっけ。マージ先は受付側が決めるってことでいいんですかね
それと別ブランチ切らずにmasterブランチにいじってプッシュしてきたりしたらまずいと思うんですがそれは拒否できたりするんですかね
887デフォルトの名無しさん (ﾜｲｰﾜ2 FF3a-BDVY [103.5.142.122])
垢版 |
2020/02/18(火) 12:20:35.45ID:r+eOvEZJF
pull request 来てそのまま merge して repository 壊すタイプ
2020/02/18(火) 12:31:37.80ID:pMNjUdCaM
レポジトリは3つあるよ。
1. プルリクエスト受ける側 (オーナーA)
2. そこからforkして、じぶんのリモートになるレポジトリ(オーナーB)
3. 2からローカルにcloneしたレポジトリ(オーナーB)

pushは2と3のやりとりで、featureブランチ開発してpush。そのブランチをプルリク出して、レビュー。プルリクはGiHub/GitLabの操作。コードが良ければ、1のオーナーが2のブランチを1へマージ(っていうかpull)。

その後にmasterにマージするかは1の人次第だよ。masterの運用は、1の人が考えればいいよ。どんな開発かわからないけど、普通はデプロイするときにmasterにマージするんじゃないかな。
2020/02/18(火) 17:35:26.84ID:+p1UhD0YM
gitって初心者には難しくないですか？
まともなレベルと規模のチーム開発を経験しないと、その機能がなんのためにあるのかイメージし辛いし
こういうのってどうやるの？って毎度毎度ググる日々…
2020/02/18(火) 19:44:21.29ID:2AC9Ct1n0
無理してでも覚えてもらう以外なかろう。
pull, push, add, commit, checkout, status, diff
これくらいをとりあえず覚えてもらって、困ったら聞いてもらうようにするとか。
2020/02/19(水) 08:12:48.02ID:EqrEbewg0
>>888
理解しました。1.と2.が別物という認識がありませんでした。なるほど何分一人で一つのリモートに対してずっとやってきてたもので
2020/02/19(水) 15:14:55.91ID:EL2IXwnU0
リポジトリ壊して怒られたことある人います？
2020/02/19(水) 18:44:25.95ID:glv7RxyWd
いませんよ
2020/02/20(木) 09:20:40.65ID:TFr3ahU9M
壊されて怒ったことなら
895デフォルトの名無しさん (ｱｳｳｨﾌ FF57-IPX/ [106.171.73.169])
垢版 |
2020/02/20(木) 10:51:36.80ID:sbHTvmgoF
リモートのが壊れただけなら
自分のところにある正しいものをpush
2020/02/20(木) 14:25:46.13ID:mSs43Khqa
リポジトリ壊すとハカイダーの称号が与えられる
2020/02/20(木) 18:06:20.23ID:Nllb9nDe0
わりと push -f を気軽にやるのなとビビったことはある
2020/02/20(木) 20:06:31.80ID:tIiyieq40
>>793
遂に、先月GCCのリポジトリがGit に移行完了した模様。


It's 2020 And GCC Has Finally Converted From SVN To Git
Written by Michael Larabel in GNU on 12 January 2020 at 07:31 AM EST

https://www.phoronix.com/scan.php?page=news_item&;px=GCC-Is-On-Git
2020/02/24(月) 17:00:59.72ID:prJq+pJl0
githubの使い方覚えようと思ってsourcetreeとかGitKrakenとかCUIでやるかとか色々検討したけど結局いつものVisualStudioにエクステンション突っ込むので落ち着いてしまった
だめだVSに完全に調教されている。俺は軟弱なプログラマだ
900デフォルトの名無しさん (ｱｳｱｳｴｰ Sa9f-IPX/ [111.239.50.235])
垢版 |
2020/02/25(火) 03:43:59.15ID:4Jcf/lZea
すれち
2020/02/25(火) 15:38:12.24ID:gwHrzvDTM
ツールの話はスレチなの？
2020/02/25(火) 15:50:01.31ID:FJnE0Xtt0
>>901
GitHubの話がスレチなんじゃないか?

ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】
https://mevius.5ch.net/test/read.cgi/tech/1531824290/
2020/02/25(火) 16:58:47.93ID:vci/itY3d
>>902
でも>>899の言ってる内容はGithub限定の話ではないけど
レス数が900を超えています。1000を超えると表示できなくなるよ。
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況