224(2): デフォルトの名無しさん (ﾜｯﾁｮｲ c597-AMkR) [] 2022/11/14(月) 00:09:27.46 ID:0VMo1QiO0(1/4) AAS
OOPでGitとSubversionを問題なく交換可能かは、それこそ実際に結合テストしてから言ってほしいものだ。
Git開発陣営は少なくとも動くものを作っているけれど、
「OOPの原則に則れば交換可能でなければおかしい」なんてのは机上の空論でしかないし、せいぜい工学的仮説といったところだろう
作れてないんだから仮説の域を出ない。ちゃんと工学的に明らかにしてくれ。

253(2): デフォルトの名無しさん (ﾜｯﾁｮｲ a37c-H0Ic) [sage] 2022/11/15(火) 16:01:59.97 ID:u2Y2Sh/m0(1/3) AAS
rebaseって使う機会無いんだけどなぁ
以前、どこかの職場で履歴は一直線がいいとか意味不明な理由でrebaseさせられていた時があったわｗ
force pushするしかないし気味悪いｗ

127(4): デフォルトの名無しさん (ﾜｯﾁｮｲ b57b-3eqv) [sage] 2022/11/12(土) 12:54:11.71 ID:h41UD2lS0(15/29) AAS
>>120
多分な、開発現場において「ファイル内の」mergeが日常ってのはあまりないと思うぞ。
それは各自が勝手にどのファイルをどういじってもいい、ということだから。

gitによって開発フローが変わった！ってのがこの辺かもしれんが、
普通は担当を振り分けて、結果的に
「この期間にこのファイルを触るのは○○だけ」
と交通整理される。
同時に変更する必要があれば、同じ奴に同時にやらせるだけ。（注文が増えるだけ)
そして各自が変更したファイルをかき集めて、くっつけて終わりだ。
お前らはこれもmergeと言ってる気がするが、
これは「更新日時が新しければ上書きする」だけの話で、手動でも楽勝だし、
プログラマはこれをmergeとは言わない。

プログラマが言う「ファイル内」のmergeが日常的に発生するかどうかはその部署のオペレーションによる。
(が、会社とか統制取れる場所でこれをする意味はないから、OSS以外ではほぼないと思うが）

404(1): デフォルトの名無しさん (ﾌﾞｰｲﾓ MMa7-xFde) [] 2023/01/23(月) 09:17:09.28 ID:JALIr7W8M(1) AAS
>>402
pushしたならrevertしかないから、使ったことはある
>>403
その認識で合ってる

453(4): デフォルトの名無しさん (ﾜｯﾁｮｲ ce02-HBIL) [sage] 2023/03/14(火) 20:58:29.14 ID:144H+TDJ0(1) AAS
Windows向けGitって、mingwとかbashとかGNU系コマンドまでいろいろ入ってて
インストールしたら400MBくらいの容量食うことになるけど、
本当にあれ全部必要なの?

492(2): デフォルトの名無しさん (ﾜｯﾁｮｲ c5e6-FGqy) [sage] 2023/04/27(木) 09:18:11.67 ID:4Ldu38ha0(1) AAS
>>491
そういうものなんですか。
Subversionのときは、ブランチの作成自体が1つのコミットで、
ブランチの名前や、どういう作業を始めるのかをログに残しておけたけど、
そのへんの感覚も違うんですね。

501(1): デフォルトの名無しさん (ﾜｯﾁｮｲ c55f-ASru) [sage] 2023/04/28(金) 17:47:03.47 ID:dDRImt5V0(2/2) AAS
>>500
え？ブランチ作るごとに作業コピー作るってのが意味わからんのだけど？
そんなことしたらどっちでも作業コピー作る時間が圧倒的ネックになって比較の意味も無くなりそうだし。

515(8): デフォルトの名無しさん (ﾜｯﾁｮｲ 1610-Z+mA) [sage] 2023/05/07(日) 02:53:34.47 ID:9zTyX7Ss0(1/2) AAS
2点質問があります。もし詳しい人がいましたらご教授いただけると幸いです。

【自己紹介・置かれている状況】
私はGitが全くわかっていない人間です。業務もITとは無関係です。
私の部署はワードやエクセルで書類を作成したり、電話対応を行うのが主な業務です。
pythonやphpなど、プログラミング言語を使った業務は皆無です（エクセルで若干関数を扱う程度）。
現在、別部署やコンサル会社から「git使いましょう」とアドバイスを受けている状況です。

【質問】
1）エクセルやワードが使えるだけの人（高齢者や短時間勤務の主婦もいます）でもGitは扱えますでしょうか？
2）PCやタブレットが50台くらいあるのですが、環境設定は大変でしょうか？作業者は私になるそうです。

【余談】
「サル先生のGit入門」や「Gitの良さが分からない？ ちょっとそこに座れ」という記事は読みました。
専門用語が多く、理解できていません...

よろしくお願いいたします。

583(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 655f-zAQ/) [sage] 2023/06/22(木) 08:22:03.78 ID:KQ2YqOqM0(1) AAS
git pull A
は
git checkout A
git fetch origin A
git merge FETCH_HEAD
と同じ？

824(2): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 08:34:32.23 ID:Vn08TQPe0(2/7) AAS
>>821
簡単に対応する必要がないんだよ。

Cがmust、Aがオプションなら、最初から担当者にその旨伝え、分離した形で実装させなければならない。
それをせずに後付でAはやっぱり止めろ、と言うのはマネジメントの失敗であり、
担当者は適切な再実装時間を要求していい。

実際、799の場合なら、上側の実際の変更に6時間、
これを「清書」して下側の履歴に改竄するのに2時間といったところだろう。
「清書」しなくて良ければ次の仕事に取りかかれるので、この時点で効率が75%に落ちてしまっている。
25%も無能マネージャの尻ぬぐい保険に費やすのは馬鹿げている。
そして実際、殆どの場合は「やっぱAやめろ」なんて事にはならないし、
言われてから対応しても本修正(6時間)と同等の時間で対応出来るものだから、言われてからでいい。
事実としてAとC纏めて修正してしまったのだから、そのまま報告しとけ、でしかない。

>>823
「情報を落とすな」というセオリー通りだ。
> 開発プロセスの資産(812)
が開発プロセスの改善を目指すものなら、なおのことだ。
マネジメントが無能で修正指示不足(例:上記の「分離」指示不足)による手戻りが多かった場合、
それがそのまま見える形で記録されてないと意味無い。
799の忖度で「マネジメントも僕の修正も完璧、イエーイ、パチパチパチ」と小綺麗に改竄された履歴からでは、何も改善出来ない。

825(1): デフォルトの名無しさん (ﾜｯﾁｮｲ 317b-vj3y) [sage] 2023/08/20(日) 08:35:35.57 ID:Vn08TQPe0(3/7) AAS
>>822
そりゃ探せばあるだろうが、ここでの議論通り、gitでは「清書しろ」が多数派だろ。
この遠因になってるのは、適切なgrepが無く、クソ汚いcommit履歴が丸見えになってしまうからだ。
それを「歴史か物語か」という「選択」だと誤魔化すのは機能が足りてないから。

例えばcommitにレベルが付加されてて、799branchのコミットレベルは2、masterのコミットレベルは0としておけば、
master上に799のドタバタ奮闘記commitsがFFマージで連なっても、
レベル0だけを表示すればマージ人員用の小綺麗な履歴、
レベル2も表示すればパッチ作成者の実際の奮闘含めての履歴、が得られる。
改竄する必要もなく、情報も落としておらず、誰にも余計な手間がかからない。
gitにはこういう「こうすりゃ良かっただけだろ」的な仕様が全部抜け落ちてて、
全部マージ人員(=Linus)側に都合がいいだけの仕様になってる。
この違和感をお前らが感じないのは、お前らがコードなんて書いてないからだと思うぜ。

ついでに言うと「清書」されたcommitsが欲しければ、それはレベル1として「別パス」を「後付で」生成、
つまりスタート/エンドポイントが799branchと同じ、ただし途中の進行が違う別パスを「後付で」追加出来れば、
レベル0は淡々とした履歴、レベル1で修正内容が「清書」された履歴、レベル2で実際の履歴、が得られてみんな幸せだろ。
マネージャが無能でAは止めると確定してからレベル1の「清書」を作成だ。これが最大効率だ。
高い確率で必要ない「清書」を毎回ご丁寧にやる意味はない。