気づいたら、あれ？いつの間にかバグ入ってる
どこの修正でバグ入れちゃったんだろ？
っていうのを、そのフォルダバックアップでどうやって探すんだよ

git使っていれば1日に数回～十数回、細かい修正をするたびににコミットするし
それを2分探索で探せるから、あっという間にバグ入れたところを見つけられるというのに

相当な健忘症だな。
自作Diffツールくらい作っとけ1人開発多いなら。

バグを入れたときにそれがすぐ見つかるなら、
バグ修正リリースなんて不要だろうなぁｗ

別にgitが自動でプログラミングする訳でもない。
とかいってメモ帳で開発すんの？

終了ですけど

教育などしなくても、勝手に自分で学んでいく
お前が勉強するのが嫌なのを他の人のせいにするな
無能はお前だけや

うちはSVNだけど、必須。
バージョン乱立して痛い目見たことがないのかな。

というかSVNは過去バージョンも再生できるし
修正したコード部分だけハイライトもできるし、
無しで開発とかあり得ないレベル

>>63でマージの話をしてますよ？
わからないなら、どこがマージか書いてあげましょうか？

複数プロダクト同時開発してたらgitを使いたくなるぞ
特にマージ・チェッリーピックリベースなどの最低限の知識があるならな
分岐して別の修正や追加機能があって、しかも同じバグ修正が必要
マージやチェリーピックを使えば簡単に対応できるんだ

同じバグでもともと同じソースなのに現状ではソース自体が変わっているほかに
呼び出されるシチュエーションが違っている事がどれだけあるか

同じ個所に同じ修正入れるわけにはいかないんだぞ
すべてgitが悪い

それはgit使わないと、もっと苦痛ですね
お前の技術力が低いから苦痛だって話じゃなくて

gitを使うのと使わないのではどちらが苦痛かって話をしてます
比較しないのであれば、お前はなにも言ってないのと同じことなんですよ。

完全に手段が目的化してる悪い例。

1人開発だもの。
出来上がった成果物を引き渡し、
引き渡された先がgitなり構築すればイイかと。

保守側、改修側は勿論必要だろう。
出来上がってから動けば良いんだから、そっちはちゃんとやれば？

1～3名くらいの人数限られているpjだとgit構築するより svn+Junitとかの方が納期通りの進捗に有用だから

一つ画面と周辺モジュールとかしばらく全部ロックっちゃう無能だから誰も共有しませんてw

・案件に応じて適切な言語を選ぶ
・自分が得意な言語でごり押しする

動作環境買わんとアカン時点で終了
Windowsだけで動作するC#、VB.net コスパ最強だろ

全国的な企業ですら十分こなせるほど性能も高くなってきたオープン系に
せいぜい数か月の素人を突っ込んで世界規模のトラブルを起こす
それが現代のITなんだよ

鯖寿司だって素人が握ったら人を殺す

相手のコントリビューションもありがたいんです。
でも、これ事実上俺が書いたことになってるじゃんｗｗｗってのが
相手はただ俺の言った通りに書いただけ

まあIssue来たって考えれば、修正コードの提案付きだから
それよりかはいいんだけどさ。コードマージすればcontributorsが増えるし

じゃあその1行修正された問題を
自分が認識してたかどうかで考えたら？

もし認識してなかったなら、そのPR送ってきた人は
問題を見つけてくれた人な訳で、
しかもその発生場所も特定し修正案も出してくれてるなら
問題のうち9割は片付けてくれてる人なんだよ

コードという表層は自分で書いたものかも知れんが
そこに至るまでのことを考えたら、単純にこれ俺の！
みたいな気分にはならなくなるんじゃね？

もしその問題を認識してたら、自分をせっついてくれた
マネージャーだと考えるとか

いや逆だよｗ

他人のコードなのに、俺が全部指示したら俺のコードじゃんｗ

ブランチのマージはキツいかもね

svnは分散して作業するって概念が無いから、必ずどこかmerge元のツリーに細かいコミットログが残ってるから、仮に細かく見たければそっちを見に行けば良い。逆にtrunkのログはスッキリして見やすいし。

gitだと個人やチーム単位のリポジトリで開発進むが、svnは分散して無いからsvnのコミットログさえ見とけば全ての状況を必ず把握出来るし。

なんでpushしないの？また猿未満のチームの話？

1. 他の人にレビューをお願いする時、または自分がレビューする時

それぞれのコミットが意味のある単位で小さくまとめていればレビューしやすくなる

2. コミット単位で取捨選択できるようになる

このコミットはOKだけど、こっちはいらないとか変更が大きすぎるので後に回そうとか言える
必要なコミットだけ抜き出してプルリク作ってと言える

3. 他のバージョンやブランチに再利用しやすくなる

最新バージョンで当てたパッチ＝コミットを旧バージョンにも適用したいから
そのコミットだけ抜き出す（cherry-pick）がしやすい

このようにrebaseされてないと意味のある単位が分断されてしまって
レビューや再利用するときに大変になる

そのブランチ上には細かい単位でコミットログが残っている。

分散的なgitだと各拠点でそれが済まされている可能性があるのでその痕跡を中央に持っていくためにrebase必要だが、svnだとシンプルに全員が中央で作業してるから、そもそも不要かなと。

– ○の修正
– ○の修正にバグが有った訂正
– △の修正
– ○の修正は筋が悪かったので◎として実装し直し
– □の修正
– △の修正にバグがあったので訂正

みたいな細かいログ見てもレビューできないし
途中の試行錯誤なんて見ても意味がない

意味があるところだけ残してレビュー依頼しろ

なのでsvnでrebaseの機能欠落と言う訳じゃ無く、あまり必要性が無いと言う主張。

そのまとめたブランチの中に>>194みたいなコミットが多数含まれていたら
レビューできねーだろ。まさかクソ長いコード全部見ろと？

そもそもsvnだと分散して無いから細かいコミットも全部中央に残ってるから、どれをまとめようとか考える必要も無い。
レビューとか相手の立場でまとめたいならブランチ切って纏めれば良いが、細かいコミットもどこかのブランチには必ず残る。

184 自分：仕様書無しさん[sage] 投稿日：2020/11/04(水) 11:19:50.02
>>182
> rebaseの恩恵ってコミットした単位でログが見やすいってだけで、実質は対して変わらないと思うんだが、むしろそれが重要になるケースを知りたい。

1. 他の人にレビューをお願いする時、または自分がレビューする時

それぞれのコミットが意味のある単位で小さくまとめていればレビューしやすくなる

2. コミット単位で取捨選択できるようになる

このコミットはOKだけど、こっちはいらないとか変更が大きすぎるので後に回そうとか言える
必要なコミットだけ抜き出してプルリク作ってと言える

3. 他のバージョンやブランチに再利用しやすくなる

最新バージョンで当てたパッチ＝コミットを旧バージョンにも適用したいから
そのコミットだけ抜き出す（cherry-pick）がしやすい

このようにrebaseされてないと意味のある単位が分断されてしまって
レビューや再利用するときに大変になる

例えばtortoiseSVNだとmerge元の細いリビジョンをチェックボックスで選択していけば、複数コミットを纏めてコミット出来て対した手間も無い。但し、何個も残したいコミットがあるものをtrunkへマージするのは、残したいログ個数分だけコミットが必要になってしまうが、しかし、そもそも、マージ元のブランチには開発時のコミットログが必ず残っているので、後で必要になってから開発時のブランチを見に行く事も可能なので、実開発ではあまり気を使う価値が経験上無かった。

書いてて思ったが、少し気になるのがtrunkへマージする人が開発した人と違う場合、trunkだけ見てると開発者の名前が登場しない事かな。

お前が言ってるのって、ディレクトリ管理でもやれるって言ってるのと同じだよ
ああ、具体的に言ってやろうか？ 新しくブランチを作るのが1秒未満でできなければ苦痛
ブランチを切り替えるのが3秒でできなければ苦痛
ネットワークつないでないと作業できないのは大きな苦痛

> 複数コミットまとめても良いし。
それもrebase。作業中にコミットをまとめておくことで
「trunkから再度ブランチ切って自分のコミットを・・・」の自分のコミットを
少なくできるから楽になる

Keeping a Branch in Sync

svnだとtrunkとの同期とtrunkへの書き戻しはコマンド1つで自動で出来るが、ただコミットログは一つにまとまる。feature branchを作って、それをtrunkヘ戻す時にあえて複数のコミットだったかの様に戻す必要性は無いって思想なんだな（もし見たい場合は開発当時のfeature branchの履歴見てねって事）gitだと開発当時の履歴見てねって出来ないから履歴ごとmerge必要なのか。

コードをながめたとき
いろんな修正がごっちゃになってると
わけわからなくなるだろ

意味がある単位に分けろ。
分離できるならなるべく分離しろ。
そして1コミット単位でリリース可能なようにしろ

複数人で作業してるなら、細かくメンテナンス（マスターに追尾）しない限り
コンフリクトは必ずと行っていいほど発生するよ

細かくメンテナンスしてればコンフリクトは発生しないけど
svnじゃそれは事実上無理

自分の担当の開発でここをこう書き換えました。
そして開発中にtrunkが更新されたのでマージしてこう書き換えました。
みたいな話をされても困る
trunkの更新の話なんて関係ないんだから

最新のコードからの修正という形にしないとレビューが困難になる

あと何でも仕様を知ってる仕様担当者、コーディングで困った人助ける担当者、新しい派遣の席を作る椅子担当者もいた
派遣をエレベーターの下から上に案内するだけの奴もいたけどあれはただの多重派遣か

ソフトの要件を決める
↓
ソースごとの要件を決める
↓
ソースごとの担当を決める

だからソースってなんだよ？

具体的な例として、C言語、テトリスでググって検索して出てきたこれ
ソースコードが1ファイルしかない
https://github.com/kaneyann/Tetris
（ちなみに俺は関係者でもないし現在のコードも仕様も知らん）

仮にこれにが古いテトリスの仕様で↓ボタンで回転するとして
これを右回転、左回転のボタンに分けるという仕様変更を行うとする

と同時に他の人が一番下に落ちたときの膠着時間
すぐに固定されてしまうのを数秒間左右に動かせるように変更するとする

この２つの対応を同時にやるとき、
お前はどうやって担当を決めるんだよ？

一つのプロジェクトを二人以上の人が担当することなんて当たり前だろ？
その人たちが同時に２つ以上の機能を開発することも当たり前だろ？
そうすりゃ共通部分に同時に手を入れることだってあるだろ
コンフリクトがおきないと思ってる方がおかしい

ちなみに一人で開発してても、同時に複数の機能を作ったりすることはあるからな
特に開発中に気づいたバグ修正を先にリリースするとか

そうすりゃ、開発中に気づく、つまり今開発してる内容とバグが有る場所が近いわけで
その場所はコンフリクトする可能性が高くなる

ファイルをなるべく分けていたとして、例えば10個に別れていたとして
何人まで同時に作業できるというのか？

その担当を決める方法を言ってみなさいということ

俺の最終的な答えは「だからコンフリクトは絶対起きるんだよ」なのでよろしくｗ

> 風に決めるだけ
その「決める」をどうやって決めるかを聞いてる

上のテトリスのソースコードが10個に分かれていたとして

仮にこれにが古いテトリスの仕様で↓ボタンで回転するとして
これを右回転、左回転のボタンに分けるという仕様変更を行うとする
というとき、

> お前はソース1～5、お前は6～10
お前が担当者を決める立場だとして
どちらが担当するのか、どうやって決めるの？
もしくは、どうやって決めてるの？

どこを修正するのかわからないのに、どうやって担当者決めるんだ？
まさか1つのファイルだけで修正が終わるとでも思ってるのか？
複数の人が同じファイルを修正するときどうするんだよ？
それを早く言ってくれよ

大規模かどうかは関係ない。同じような箇所を修正すれば衝突する
お前、チケット見た段階でソースコードの同じ箇所を修正しないって
どうやってわかるんだ？ありえない話をお前はしてるよな

つまりこれはソースコード完璧ならコンフリクトは発生しないと言ってるのと
同じことなので、完璧なソースコードなんて現実にはありえないってことで論破できる

このスタイルで開発しても、featureブランチが作られた順番にマージされるとは限らん
ブランチの内容が上流より古くなってしまったら、rebaseを使ってfeatureブランチを最新版から生えてる状態にする

git fetchしてorgin/developを最新にする
次に
git checkout feature/hoge
git rebase origin/develop

とすればfeatureブランチが最新コミットから生えてる状態になる

多分図で見た方が分かりやすいから
ググったり、慣れるまではGUIでrebaseがおすすめ

rebase時にsquashやfixupによるコミットの結合も活用すれば、あとあと履歴が見やすくなるし、rebase時にコンフリクト解消する回数が少なくなる

まあ確かにfeatureを細かく切るってのは運用保守の段階なら良いが大幅な改変が必要な時には
無駄が多い。

というか代案も何も答えは明白ですよ。シンプルな設計、トップダウンでツリー状に機能が綺麗に分かれるような仕様要件なら分散管理は効率よく機能し、複雑な仕様設計ならgitかっけー的な運用したらプロジェクトはデスマーチ必至。そういうときはgitでも集中管理的な運用をする必要があるということですな。おそらくgitスレがIP表示なのはgitの運用方法でケンカした結果でしょう。

>>396
それは結局、運用による。

結局、いつも車輪の再発明で、webのUIとかがちょっと新しいとかそれぐらいの違いしか無いのに誰かが騒ぎ出す。

そしてどんなモダンなシステムも最後の最後は通知が必要で、結局、最後はoutlookを開くのさ。

重要なメールをしたら必ず電話
この基本も知らない奴らが「その件なら1ヶ月も前にチケットにコメント書いてますけど」とか「slackに流してるのに、まだ対応してないとかふざけるな」とか平気で言う
「pullして無いのそっちですよね」

商社をクビになった社員が顧客情報を持ち出して
商社のテンプレートで振込先変更の連絡を入れてきて
売上金をだまし取られた詐欺事件が横行している

>>410
svnだろうが何だろうが行単位でコンフリクト発生してる状態じゃ相手先のブランチにpushなりcommitなり出来無いんじゃ？

>>411
パッチでも結局1コマンドで退避、復元出来るから対して問題ないのでは？svnだとローカルリポジトリの状態とか保持する必要無いからstashに対するモチベーション低いだけ？

またはwordなら版管理機能あるから、それを使え

ブランチはかならず終わったらマージしてトランクに戻すとか
そういうルールについては宗教戦争になるので言わないが

ブランチとか関係なく全部の動きをサクッと見たいとか、git使うとき気にする必要のある要素多すぎとかw
The working directory
The “index” or staging area
The local head
The local copy of the remote head
The actual remote head

あと、お試し実装とか自分だけのプロトタイプとかを作りたい時でも
ローカルでリモートと同様にバージョン管理ができる

ソフトウェアも最新に保たなければバグに遭遇したり
脆弱性を狙った攻撃の危険がある
ハードも経年劣化で故障するし、電力効率も最新の製品より劣る状況になる

クラウドを高可用性考えたり
多要素認証設定したりして動かす方が安心で安い