喪男のプログラミング

SIerは基本的にGitを信用してないので、CVSもしくはSubversionが推奨される
しかしライブラリアンに文系あがりの新人置いたり、経費削減で削ってしまい
杜撰な集中管理がなされたり、結局開発者にもSVN解放したりする為
管理不能に陥ってむしろGitを使った方が良かったのでは・・・という状況となることが多い
でも、Gitだと顧客説明が難しいから未だに出来もしない集中管理システムに拘り続ける

プルリク方式取ればSubversionで集中管理するよりよっぽどマシな管理できるんだけどなー
巨大なSI企業だと一回確立したやり方を崩すの無理なんだろうな

改革したがらない風潮が悪い

>>243
これの問題点はもっと業界の深い部分だと思うよ
Gitで恩恵を受けるのは主に開発、下請SIerであって、
プロジェクト方針を決める上流にとっては、下請と派遣に無茶言えばいい話
それに、分散管理って言葉自体顧客や管理職や監査の連中が嫌う言葉なので
採用すると上流SIerの営業上の負担も大きくなる

gitはマージもしくはアップデート対象外のファイルでも、編集したやつはいったんコミットしないとリモートからpullできないのがなあ。
俺潔癖性だからpullだけのために実装途中のコードなんてコミットしたくないよ。
頻繁にpushしあうようなチーム開発にはこの仕様って向いてないと思うんだが。
もしかしたらXCodeだけの制限かもしれないけど。

基本作業する時は別ブランチ切ってやるんだよ、
それで手が空いたらfetchしてリモートのマスターと手元のマスターは常に同期しとく
手元の変更を隠すgit stashってコマンドもあるし、pushする前ならrebaseって履歴を自由に変えられる手もある
神経質な人ほどgitは合うよ、ひとつのcommitに関係ない変更加えずに済むし履歴は綺麗に書き直せるから

Gitばっかり注目されてるけどMercurialも良いよ
少し前のプロジェクトで開発からSVNじゃなくGit使おうって意見が出た時、
GitじゃなくMercurialにしようって運用管理グループで持ちかけた結果
SVNがいいPM層とGit使いたい開発とMercurial使いたい運用で意見分裂してプロジェクトそのものがぽしゃってしまったけど・・・

>>246
それ完全にgitの使い方誤解してるよ
commitしないとpullできないっていうのは適切な作業単位ごとにブランチ切らないからで、
リモートのマスターに作業中のコードに影響ある変更されたら適宜作業ブランチにmergeとかrebaseする
誤解してる人多いけどcommitとpushは全く別物で、commitはローカルでどんだけ自由にやっても誰にも迷惑かからない
注意するのはリモートに変更及ぼすpushの時だけ、pushのときにローカルでしたcommitを綺麗にまとめ直したりする
開発人数が多くて頻繁にマスターの変更があるなら絶対にgitのほうが便利

Mercurialもいいよね
直接コード書く開発者にとったら集中管理が分散管理に勝る点ないと思う

git最初は戸惑うけど学習コスト払うだけの便利さはめっちゃあるからぜひ使ってみてね

俺はgitから使い始めたのでSVNがよく分からん

>>247
>>249
これまでの経験だと、ブランチ切りたがらないんだよお客さん側が。
理由は上で書いてた人のケースもあるし、常に全員が同じ最新ソースを参照して最新のバイナリをビルドできないと問題の共有と確認ができないというのもある。
ローカルにゴミ的にコミットした履歴を編集してまとめたりしてからpushできるのは知らなかった。
XCodeからはそういう機能は使えないみたいだな。
というか、XCodeならスナップショットがあるし、それならあまりgitにこだわる理由が生じないんだよね。

二重管理になるからブランチを切る場合はエクセルで管理してくださいとか謎なこと言われたことある
いまだに謎

客が切りたがらないなら開発側で構成管理決めて対顧客では構成管理が一元管理、
開発側は構成管理のリポジトリをマスタとして好き放題いじればいいんじゃない？
そうすれば顧客リポジトリには綺麗な履歴が整然と並ぶし、開発側は利便性重視で、悪い言い方をすれば汚く使える

>>255
完全に同意
客にはテスト済みかつリリース可能なマスターブランチだけ見せれば良い
そう決めて使ってればマスターにマージされるコミットログも自然ときれいになるし

あ、上のは顔も見た事ない知らない人たちが集まって一つのアプリを作ってるような場合ね。

それにしても喪板で一番有益なスレですね。
勉強になる。