[過去ﾛｸﾞ] Git 18 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
2: (ﾄﾞｺｸﾞﾛ MM34-njqB) 2022/04/23(土)08:13:23.56 ID:E3mWBeB+M(1) AAS
おまえら最近 --rebase しましたか?
62(3): (ﾜｯﾁｮｲ 8cdb-Yb1D) 2022/04/27(水)01:04:03.56 ID:9dk3kBsG0(1/5) AAS
>>55
gitのほうが面倒だろ
remoteが更新されたのが分からないし
１秒おきにfetch,diffするスクリプトを動かして、更新されたら関係者全員にラインしてるわ
238(1): (ﾌﾞｰｲﾓ MMcb-X/Ck) 2022/07/13(水)10:32:56.56 ID:1bHMUsjpM(1) AAS
>>235
そんな啓蒙が必要ってどんな環境？
自社開発でさすがに今時Gitの啓蒙が必要なんて考えにくいし、客先常駐だったら客の説得が先じゃね
ハードウェア系とか？
250: (ﾜｯﾁｮｲ cbdb-l4EN) 2022/07/13(水)19:30:06.56 ID:AX+MGypu0(2/2) AAS
>>248
プログラミングしたことない人はそう感じるらしいね
399(1): (ｵｲｺﾗﾐﾈｵ MM55-geFY) 2022/07/26(火)19:59:34.56 ID:StEemcQzM(2/2) AAS
>>398
話が長くてすまんが、要はorigin/devはなにかの省略形で、それは文脈によって決まるということです。
origin/devっていったら、普通はアレのこと、というのはありますが、一つの言葉に固執している様子を感じたので、原著に当たったほうがいいよというアドバイスになります。
452(1): (ﾜｯﾁｮｲ 2e14-n238) 2022/08/14(日)13:58:00.56 ID:eEFpmmgP0(1/2) AAS
>>448
数万行のコードなんて覚えてられない
どうせおまえがやってるのは100行以下のサンプルコードだけだろｗ
538: 534 (ﾜｯﾁｮｲ c31d-755I) 2022/10/02(日)19:05:01.56 ID:6kxI91N30(3/3) AAS
>>537
そうなんですね
インプレスの本ではVSCodeを使いなさいと書いてあったのでそうしました
694(1): (ﾜｯﾁｮｲ 6914-Tk+f) 2022/10/31(月)20:03:29.56 ID:oV1LtMOH0(11/19) AAS
> まあ仮にそうだったとして、Git内のdiffがあらゆる環境で同じdiffを生成するように小細工してるとでも？
同じdiffを生成するために、gitで実装してるんだろ
頭悪いのか？
依存ライブラリ（この場合はコマンドだが）を減らすのは
移植性を高めるための常識だ
704: (ﾜｯﾁｮｲ 6914-Tk+f) 2022/10/31(月)20:41:49.56 ID:oV1LtMOH0(18/19) AAS
自分が認めているもの以外「全部方針が狂ってるよ」
その理由は、自分が認めていないからだよ
世界が認めていても
「俺が認めていないから世界の方が狂ってるんだよ！」
734: (ﾜｯﾁｮｲ 8bbb-VzUj) 2022/11/01(火)02:08:49.56 ID:QdibabTL0(1/2) AAS
そもそも汎用性がある方が良いというのから幻想
道具は利用目的にあっているかどうかが全て十徳ナイフありがたがるやつは素人
851(1): (ﾜｯﾁｮｲ 6914-pSqO) 2022/11/05(土)13:57:20.56 ID:0q4aURph0(2/9) AAS
git add -Aで十分とかさぁ、開発経験なさすぎだろ
それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
通常なにかのバグの修正とか
複数の個別の問題の複合なのに
それ全部まとめんな
852(1): (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)13:58:29.56 ID:646uiMLL0(5/38) AAS
>>846
そもそも俺含めて大半のプログラマはGitを理解したいとは思ってなくて、
単に便利だから使ってるだけだと思うがな。
理解せずに使えるのならそれに越したことはない。
(この価値観が相容れないのは理解したからもういいが）
君はGitを履歴追跡ツールとしてしか見てないようだが、
俺はもっと一般的に、Git形式のDBとして見てる。(INSERT履歴が保持されるDB)
そして、俺は>>808と同意見で、
開発が今現在行われていないブランチは閉じられてた方が見やすいと思ってる。
常時存在するのはgit-flowでいうdevelopだけで、masterやreleaseはタグでよく、
hotfixを作るならまずmasterブランチを復活させ、そこからhotfixを発生させたほうがいい。
(なおreleaseブランチは最後にバージョンを打つ奴にはいいが、
俺は先にバージョンを打ってから更新部分を実装するので、俺のワークフローには合わない）
それ以外にも、featureX付加時の変更漏れ/不適切な変更によるバグ挿入が後で発覚することはあるから、
git-flow的にfeatureを作っては消しで行くなら、ブランチの復活はプログラマには疑問のないことだ。
featureX_patch0と新たな変更扱いしてもgitオブジェクトツリー自体は同じだが、
名前が似てるだけの別物扱いになるので、
featureXの開発『線』をメンテナンスする気なら、branchの復活が必要になる。
実は、とりあえず同じ名前で作り直せば自動的にくっつく馬鹿向け仕様か？と試してみたが、
まあGitの文化でこれはなかった。
が、まあ、俺的にはこれであって欲しかったね。
「同じ名前が昔ありましたが、そこにくっつけますか？(Y/N)」「Y」
「いい加減にしてくださいよ、何回目ですか？」「うるせーよ」みたいな。
ただこれ、branch側は --list オプションで表示を簡単に絞れるから、
Gitの思想としてはbranchは「消さずに全部残しておけ」で、
git-flowがGitの思想と合ってないだけだね。ならツール用意しとけと。
856: (ﾜｯﾁｮｲ 617b-8+ss) 2022/11/05(土)14:24:19.56 ID:646uiMLL0(6/38) AAS
>>851
> それはgitをバックアップとか途中セーブ機能とでも思ってんのか？
> 1 commit = 一機能の追加とか、一日の最後にやるものとか思ってるんだろ
そうだぞ。
ブッ込んでおけば後で何とでもなるただのバケツでしかない。
バケツの使い方を学べとか、知るかボケだ。
後でバケツから探し出すハメになった時、取り出し方をググって取り出せれば十分だ。
大方、プログラマの大半はこの程度の認識のはずだぞ。
そしてお前が望む、綺麗な管理記録は、これのサブセットでしかないんだよ。
だから例えば俺が780で言ったように、「コミットメッセージが空」を除外すれば簡単に得られる。
今のGitにこの機能がないだけ。（まあ近い機能はあるが）
DBならWHEREに条件を付加すればいいだけの楽勝案件で、Web系ならみんな出来るよ。
sedのワンライナーで済むことすらCで実装するGit界隈だと誰も出来ないのだろうけどさ。
まあGitにSQLインタフェースを付け加えればWeb系の奴等は文句言わなくなるんじゃないかな？
連中にとっては直感的になるから。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 1.943s*