Github使えないエンジニアwwww ->画像>3枚

わたしです(´・ω・｀)

たわしです(´・ω・｀)

gitは使えて当然だけどgithubとかいう糞サービスのステマはやめろや

ギットとかいうのが嫌われる理由がわかった。
チーム内にギットルール厨が湧くからなんだ。

ギットルール厨になったからには、ちゃんと
みんなのブランチを全部代わりに管理しないと。

git厨って納期間に合わないよね。自分の手持ち分とかヘーキで毎回遅らせてくる。

おい、 git厨、なんとか言えよ
盛り上がらねーだろうが
こうやってネタ振りしてるんだから無視するな！

かまって、かまって、かまって、ちょん♪

すまん。gitはコマンドラインとrebaseはよく使いこなせん。

私はDocker使えない

githubは覗き見るだけ

ギット厨を黙らせるのは、そんなに難しくはないだろうけどね。
キーワードは「責任」。

まあ、おれは逆責任を回避するために、むやみに騒ぎはしないけどね。

>>11
そもそもギット厨は最初から騒いでいない
ということを指摘すると、お前は黙るだろｗ
お前を黙らせることなんて簡単だ

まあ、このスレではまだ、ギット厨は来てないけど、
一時期はそりゃあもうねぇ・・・

チェリーピック使えないチェリーボーイおるか？

>>6
君はgitとgithubを混同してるね

わけのわからんツールを使うより、ファイル名に最新版とでもつけてバックアップフォルダに放り込む方が圧倒的に便利

プログラマーでgitもsvnも使えない奴本当にいるの？

プログラマーじゃないやつが紛れ込んでる

>>18
だよね
>>16の方法でソースコード管理やってたら仕事にならんもんな

え？まじでしょぼいIT企業ってフォルダ名とかファイル名に日付書いて管理してんの？

>>16
最新版が溢れて真の最新版が分からなくなるよな

内製してるけどそんなもんだよ
しょぼいシステムしか作っとらんから

>>20
組み込み系だとそのほうが手っ取り早い。ほぼ全員git使えないのにどうやって教育していくのか頭痛いぞ
業務系はルール作れば従ってくれる
WEB系は勝手にごちゃごちゃツール使うけどコーディング全然進まん

>>23
最後の一行わかりみ過ぎる

>>23
組み込み開発者だからgit使えないというのが意味分からん理屈

Web系のやつって「ボクが学生時代からつかってるお気に入りの環境にしました！」みたいなの多そう
しかも各人別なやつ理想にしてて（言語やフレームワークも）

ツールの勉強はよくしてるし言語も新しいやつに対応してくれる
でもどれでもハローワールドレベル
ネットの記事をなぞりましたで終わってる

>>23
> ほぼ全員git使えないのにどうやって教育していくのか頭痛いぞ

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

>>28
git導入しようぜって声かけたら多数決で否決されるんだけどどうすればいいの？

お前がしっかりマニュアル作ればよくね

>>25
組み込みは個人プレーだからね
自分ひとりがわかる方法で管理すればいいだけ
その選択肢としてgitは有望だと思うがディレクトリやフォルダで管理したって大差ないよ
同じように出来るという意味ではなく生産性が変わらないという意味ね
むしろフォルダ管理のほうが効率がいい場合すらある

>>30
ネットにマニュアルはたくさんあるけど作る意味あるの？

>>21
組み込みだと客先ごと、ハードウェアごとに最新版が異なり分岐していく
ソースの系統別進化図みたいなものがないとわからなくなる
あっちで直したのにこっちで直してないとかもよくある

>>31
一人開発プロジェクトでもバージョン管理システムないとやってらんないけどなあ

>>34
一度経験しちゃえばそうなると思うよ
各自がスタイル確立してるからやり方を変えるきっかけがない

キーワードは「責任」

>>34
開発の時にいるか？
自動でタイムスタンプ名でフォルダ作ってバックアップすることスクリプトでコト足りるだろ
1日100回更新掛けて誰が管理仕る？
5枚は作らされると言うのに。
Excelログテスターが出て来る連結後で良いだろ。

>>37
いるだろ。

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

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

>>38
1人開発で「あれ？いつの間にかバグ入ってる」
「どこの修正でバグ入れちゃったんだろ？」

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

>>39
git使ってりゃわざわざdiffを自作する必要もないやん
git diff便利やで

個人的には、Githubは個人開発だったら別にいらない
gitは個人開発でも使った方がいい、って感じだな

ハブは覗き見て参考にするから使う

>>37
そんなアホなことするくらいならgit使った方が早いわw

>>43
1人開発なら、メモ帳で FileSystemObject をたった6行書くだけ。
だから git厨とか言われるんだよw

>>44
それgit使うより手間かかってるよね

>>39
アホか、お前はいつの間にかバグを入れてしまったということがないのか
嘘はつくなよ。それなりの経験があれば誰しもやったことがあることだ

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

それからdiffの話なんかしてない
diffは所詮差分がわかるだけ
いつバグを入れたかはわからない
いちいち過去のやつを引き出して確認するかｗ

2分探索でバグを混入させてしまったコミットを調べることができる
の意味もわからんのだろうなｗ

>>44
・メモ帳起動する
・6行書く
・ファイル保存する
・Wクリックする

終了ですけど

画面コード書いて、コーヒー一口飲んだらWクリック
それ以上に速いのって何かある？

>>46
別にgitが自動でバグ探す訳でもない。
1人開発だぞ？w
まさかバージョン管理ツール無いと1人開発出来ないの？

>>47
ゴメンね。
1人開発で話してくれるかなあ。

git使わんと分岐管理とか過去との差分とかやっとれんわ

>>50
お前、プログラム向けのテキストエディタ便利
これ無しで開発とか考えられんわって言ったら

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

>>53
負けず嫌いなのは構わないが
有り得ないイチャモン系の質問投げて 回答要求とか止めてくれw

やり取りの最初に「1人開発」忘れてコーフンしちゃったgit厨w

ひとりでもgit使った方が効率いいからな

一人だとブランチやdiffが必要ないって理屈がよく分からないな

開発環境新しくユーザー作ってGitローカルインストールしてパス設定あれこれやってリポジトリ設定からブランチ切ってる間に画面5〜6枚作り終えてるわ。
Yahoo！で働いてたらその時間にはリリース済だよw

開発環境入れる時に同時にgit入るだろ
ひとりならローカルリポジトリで事足りるから特にgitの設定なんていらんよ

>>59
1人開発だしバックアップDiffだけで十分だからいりませんw
毎来月には環境スクラップだしw
「無いと出来ない」とか言って無いよね現場とかで。
その段階で真性の厨だよマジでw
git無い震災前とかは引き籠りだったのかな？
svn vss 無いと出来ません！とかw

>>60
だからdiffだけでどうやって
コードをマージするのさ？

gitはローカルに入れておくツールだよ
エディタにこだわるのと一緒
自分ひとりで完結できる世界

>>52
複数プロダクト同時開発してたらgitを殺したくなるぞ
特に中途半端な知識の段階だとな
分岐して別の修正や追加機能があって、しかも同じバグ修正が必要
ひさびさにキレちまったよ

>>63
殺したくなるのは、お前自身じゃねーの？
この無能が！って（笑）

>>63の解説
git使ってなくてソースコードを一元管理してないから
あちこちにコピペした汎用関数のバグ修正に追われている

結局git使ったことないから面倒臭そうというイメージだけで手を出せないんだろうな

面倒にも２つの意味があって

作業が面倒 と 勉強するのが面倒
プログラマの素質がある人は作業が面倒だと思って
その面倒さを避けるために時間をかけてプログラムを作ったりするｗ

プログラマの素質がない人は勉強するのが面倒で
面倒な単純作業を繰り返す

gitbucketが手っ取り早くてよいよ、在宅フリー
ソースは全部gitbucketにぶち込む

自分のビジネス領域に被らない分野、かつビジネスに還元できる言語に
限定してgithubにもソース上げてるが、ちらほら星貰えるようになった
まぁ誰もみてないんだろうけどcommit commentが悩ましいね
これきっかけで英語もちょっと意識するようになった、もう今更だけど

>>61
1人開発でマージもクソも無いわなw
winmergeでログ取るだけだろw

多人数前提で考え過ぎだよw
プログラマ不足だから1人で設計製造当たり前w

>>60
一人開発だからというよりは使い捨てプログラムしか作らないからだな

>>69

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

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

winmergeで差分とればマージなんかしなくても
バグ修正できるだろ！！！！！

って言って欲しい（大爆笑）

>>72
実際にやったことある？
整合性とれるようにコミットするのがどれだけ苦痛か・・・

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

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

>>74
> 整合性とれるようにコミットするのがどれだけ苦痛か・・・

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

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

>>72
何度言い張ろうが、1人開発でgitは不要
完成したら引き渡すから保守側でやってくれ。
お前ら時間あるんだから。

>>74
別にvss時代も一緒だったからgit厨が特別大変なコトやってる訳でもなく。

>>75
やっぱりロクにgit使ってないな
git使わなかったらこの作業は全部消えるんだぞ？

>>78
1人開発なら不要な作業
時系列バックアップからdiffれば十分

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

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

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

なんでgitの話してんだ？
githubのスレなのに

>>79
一人開発だからgit不要じゃなくて一人で使い捨てプログラムしか作らないから不要と言わないと賛同は得られないだろうな
一人開発で保守改修やってる人も大勢いるんだからそういう人にはgit必須だもんね

必須か？

>>76
言い張るっていうのは「理由がない」ときに使う言葉やで
つまりお前が書いたそれは理由がないから、お前が言い張ってる

ちょっと実験的にコード書き換えて
うまく行った or うまく行かなかったら
書き換えた部分を戻したり差分を見たかったりするわけだが
gitならそれがgit diffするだけで見れる

必須やなぁw

vssと一緒
いらんわ
svnで十分かも

Git使えない上にメリット理解できない池沼プログラマって実在するのか…
いやネタだよな？

↑1人開発と言う前提無視して、さりげなく書き込んだつもりの負けず嫌いgit 厨w

1人開発でもgit使ったことあればgitナシでの開発なんて考えられんだろ
一々言葉にしなきゃ通じないってこと自体驚きなくらい当たり前の話だぞ

githubのスレですよ

SVNは動作が遅すぎる
チェックアウトしたり履歴見たりしてるだけで日が暮れる

Gitって英語が多くて、意識高くて品質低い系の文系アホと相性良さそう

>>87
一人開発でも有用だから

相性がいいとか以前に普通使わない選択肢がないだろ
流行り廃りやトレードオフと無縁な所にある数少ないソフトウェアの一つだと思うぞ

>>90
svnってマージがアホだったけど今は改善されたのかな

そもそもマージってソース管理ソフトの役割じゃないよね
というか元ソースを変更しようとしている人を検知して欲しいんだわ
エディタレベルで連動してくれよ

SVNしか使えない老害が一人で粘着してるだけ

>>95
自動マージはソース管理ソフトの役割だぞ

>>94
マージトラッキングならかなり前からある

githubの話は？

>>88
>>92
無くてもヘーキで即、開発終わりました
gitやgithubは1人開発には不要だから、unitテストで自動化くらいしておきなさい
ソースコード嫌いなのは判ったからw

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

つかNTTDの政策投資銀行案件に性能試験参加したがgitと名のつくものは使用しておりませんでした。
svnで十分だそう。

githubも組み込んでCIまわすっていうのはある程度の人数超えたら有効かもしれんが
1人でやるなら構築に時間かかりすぎて無駄じゃないの？
年単位で担当するならともかく普通は３か月でしょ？
開発環境構築するだけで３か月終わっちゃうよ

ワイも役所仕事でgithubは使った事ないな
イケイケのWEB系だけやで
WEB系と言うても業務系じゃなくてネットショッピングとか本物のWEB系ね

SVN使うメリットがないので使わない

ここの老害はSVNで十分と言ってるだけ

SVNが特別gitと比べて簡単なわけでもなく
高速でもなければ便利でもない
だから廃れた

老害なんてその内消えるから気にすんな

廃れるも何も
使ってるのおまえらだけだよ

もうこれ単なる老害スレだなこれ

git使ってほしいヤツがgithubスレで騒いでgit使わせようとする
ギトハラ

引退してくれればそれで良い

おっさんだがgitが普及して本当に楽になった

チームにgit使えない老人が一人いたら本当に迷惑なんだよな

逆張り厨って脳障害あんの？やっぱり
病気だろこれ

新しいこと覚える気のない奴ってこの業界向いてないだろ

>>105
高速とか必要無いでしょw
そもそもアンタの仕事、そんなに早くないし

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

でもさsvnとvssで20年近く前からある機能をgitに置き換えただけで今さら何か特別視するアンタ達ってw
相当遅れてないか？
git担当って富士通で2年目新人の仕事だったぞw

何でもかんでも共有化だからスキル詐称が1人混じってると3カ月目にはロックだらけになって、手を付けられない部品が増えて来るだけで、モジュールクラス単位で切り離しが始まると。

今のプロジェクトとかどうせ銀行案件でもプログラマ4〜5人しかレギュラーいないんだから貴重なプログラマリソースを1人やらせてないで、gitにしろhubにしろテスター辺りから1人持って来て管理だけやらせればイイ。

ただ仕事の時間をgitに逃げてるようなプログラマだから、成果量は大した事無いし、さほど使えないのは承知だけどな。

個人的にはsvn、redmine、winmergeで十分。
差分リビジョン表示されればOKですわ。

こんなとこで使えと言わなければならないほど使われていないのが現状で
採用している企業が常識だー勉強しろーと数年わめいて名前だけは定着したけどうちの会社では使ってない
ジットって間違えて読んでる人たまにいるよね

言語もCOBOLで十分とか言いそう

二年目の新人が正しくマージできるなら大したもんだ
怖くてみな逃げているというのに

マージはマージする技術云々じゃないからな
コードをマージ可能な適切な修正内容にするのは難しい
初心者は一気に大量の修正を多なって、無関係な修正も多数入れ込むから
マージが怖いとかじゃなくて、適切な修正を行うのが難しい

そのうちVisualSourceShredderでも十分とか言い出しそう

>>119
事務処理やるのにCOBOL以上にやれる言語は皆無だよ

>>119
COBOLが適切な場面もある
言語の選び方は２種類ある

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

COBOLでできる事は他言語も可能だから選ばれない

レガシーシステムの保守だけで関係ある言語

唯一無二と証明されるCOBOL

必死にCOBOLワールド設定してマウント取ろうとしてるサマが草

必死のgitワールド in GitHubスレ

COBOLが得意な場面で他の言語が出てくる余地があるのかな？

例えば単純計算の大量バッチ処理
むしろ何でも「出来ます」的な言語じゃやらせる意味がない

そもそもCOBOLは特定分野で最速なのがメリット
Javaみたいな汎用言語はその器用さゆえに速度を犠牲にしてるんだよ
速度的に対抗できるのはCぐらいじゃないか

COBOL vs Git

ファイッ！

>>129
> COBOLが得意な場面で他の言語が出てくる余地があるのかな？


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

>>123
COBOLの最大のライバルはSQL

Web系の人間は世界が狭いので若造が多いので
LinuxでJavaでGitな世界だけが標準だと思い込んでる（Java部分は何かWeb系っぽい歴史の浅い軽薄な言語に置き換え可）
そして詳しいはずのGitも個人レベルでしか使ったことがなく、安易にpush -fしてトラブル起こす

>>133
レッテル貼りしようとしても無駄だよ

>>133
お前push -fしてトラブル起こしただろｗ

これだから老害はw

新人なんでGithubを使わない共同開発とか想像も出来ない
Githubなしでコードレビューとか自動テストとか
どうやってたの？
そういうの無しの暗黒時代だったわけ？

GitHubなら保護されたブランチの設定がある
特定ブランチのforce pushやブランチの削除を防止できる

必要があってforce pushする場合も--force-with-leaseの方がオヌヌメ
リモートに未知のコミットがある場合はpushに失敗するのでより安全

そもそも普通のワークフローならメインのブランチを直接触らないはず
先にプルリクエスト作れよ

ジジイになると最新のもの受けつなくなるからな

>>135
なんでわかった！？

push -fごときで何やらかしたんだ？

>>131
何億もする汎用機は不要！（月額レンタル代の話な）
たかだか１０００万円買い切りのサーバーで何でも出来る！！
しかも技術者はPC界隈から集める事ができる！！！
オープン系はどれだけ画期的だったことか
そりゃ汎用機も落ち目になるよね

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

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

push -fでトラブルを起こした事がない奴は素人

1行修正のプルリクが来た
→ うーん、これはちょっとまずいからこうしてほしいなぁ（1行の修正を俺が訂正）
→ 相手、俺の言うとおりに修正する

これ書いたの実質俺じゃん？ｗｗｗ
みたいなのってどうしたらいいんだろう

>>144
レビュアーを評価するシステムがないとすると、
誰もレビュアーをやりたがらなくなり
コードの品質にも影響がでるので、
ちゃんとレビュアーも評価する様なシステムを
作るように提言するといいと思う

>>145
いや、別に評価とかどうでもいいんだけどねｗ
そもそも俺のプロジェクトだし

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

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

>>146
コメントに実質俺が書いたって書いとけばいいんじゃないの

>>146
ああ、OSSの話ね
自分のコードが他人のものになったみたいで微妙みたいな話か

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

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

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

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

>>147
マージの担当の人が天才的人物で良くそれやってるわ
まわりが萎縮しちゃうから良くないよな
前の会社でも天才と言われてたらしい

>>148
> 自分のコードが他人のものになったみたいで微妙みたいな話か

いや逆だよｗ

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

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

バグじゃないんだけどなｗ

相手「こうしたら便利じゃね？」
→俺「せやな。でもそれ問題あるから、こうしてね」
→相手「はい」
→相手がコミットしたことになるが、そのコードは俺が支持したものｗｗｗ
→さらに俺が近々同じ行を別の目的で書き換える予定ｗｗｗ

ギットなんて、ただのジジよけだろ？

相手：具体的な提案と解決策を提示
俺氏：「ちょっと変えて！」
相手：「OK」

俺氏ほとんど何もしてないんじゃ・・・

マージボタンを押したよｗ

フォルダに入れたぞ

>>95
マージを人がやるからミスる

>>157
これからはもうエディタを監視してマージを全自動にするべきだと思うんだわ
リアルタイムマージにするか、それともエディタの背景に他人が編集中のソースがゴースト表示されるぐらいやって欲しい
せめてソースの編集を開始したら自動的にリードオンリーのロックをかけるようにして欲しいぐらいだ
ルールベースでロックかけると絶対アンロック忘れが発生するしな
xlsをファイル共有してる時のロック具合がちょうどいいぐらいだわ

>>158
Githubをちゃんと使えてるならソースを複数人が
同時編集してても問題ないと思わね？

マージが一番難しいよな
誰が何の目的で何やったのか判断して、前後関係が見極めてマージしないといけない
コメントが適当な奴がいると泣きたくなる

> 誰が何の目的で何やったのか判断して、前後関係が見極めて
それはマージと全く関係ない話
マージしなくても修正全てに当てはまること

ファストフォワードなら問題ない

github cli 使ってる？

使ってない

使ってる

>>160
>誰が何の目的で何やったのか
それをコミットログに書かないやつを死刑にするだけでいいだろ

>>160
プルリク見ろよ

こまめにprだしてこまめにマージすればいいだけじゃないのか

Gitない時代にコードレビュー自動テストどうやってたん？って書き込みあったけど
昔はコードレビューも自動テストも仕様書すらなかったからな

gitができたのは2005年だ

junitの登場は2002年

>>169
リーマンの頃に既にユニットテストはやってたが。

単体テストなんて昭和の頃にはやってた気がする

>>169
嘘つき

>>169
やり方知らなかっただけと言うオチで恥を晒してしまったね

>>169
いきなりgitになってからできた文化じゃないぞ

少なくともコードレビューはCOBOLの時代にやってた
自動テストもMSXでやってた

単体テストってさ
ビルドして実行が手軽に出来ない開発環境においては
滅茶苦茶有効だよな
「次のビルド予定時刻は２時間後です」みたいな規模の開発あるじゃん？
下手すりゃ１日１回とかね
それでも単体テストはやらせてくれる
そういう環境に放り込まれたら単体テストってむしろ手軽に実行できる存在なんだわ

>>160
＞マージが一番難しいよな
＞誰が何の目的で何やったのか判断して、前後関係が見極めてマージしないといけない
＞コメントが適当な奴がいると泣きたくなる

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

業務で使う場合大抵のケースでsvnの方が直感的で使いやすい。gitはlinuxカーネル開発時にsvnだとパフォーマンスが出ないから開発された経緯があった記憶があるが、ssd登場によってもはやパフォーマンスも対した問題じゃ無くなると、もうsvnのうな中央管理で良いじゃんってなる気もする。

どうやってsvnでrebaseするの？
直感的かどうか以前に、重要な機能がsvnにはない

>>181
rebaseの恩恵ってコミットした単位でログが見やすいってだけで、実質は対して変わらないと思うんだが、むしろそれが重要になるケースを知りたい。

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

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

>>182
>gitだと個人やチーム単位のリポジトリで開発進むが、

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

>>182
> rebaseの恩恵ってコミットした単位でログが見やすいってだけで、実質は対して変わらないと思うんだが、むしろそれが重要になるケースを知りたい。

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

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

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

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

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

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


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

よくある話だが、ある機能を追加するためにコードを修正していた。
その機能追加作業を開始して数日後、直接関係ないバグを発見した。
依存性があるためそのバグを修正しないことには機能追加ができない。

このバグは他でも影響しそうだから、早くリリースしたいし
機能追加の修正に含めてしまっては、レビューの量が増えてしまう

だからすでに機能追加のコミットはいくつかあるが
バグ修正を先にリリースし、そのあとに機能を追加したように歴史を修正する

素早いリリースとレビューの負担が減るという大きな恩恵がある

>>182
> svnは分散して無いから
別の（顧客の）プロジェクトは、分散させないといかんよ

>>184
rebaseやるやつでそこまでコミット粒度をしっかり考えてる奴なんて見たことないがな。

>>187
俺がやってるが？
ってか、普段から適宜git rebaseでmasterからの修正に直したり
git add -pとかで適切なコミットに入れておかないと
マージするときにコンフリクト起こしまくって大変だろ
開発中はあちこち修正しなきゃいけなくて理想通りの順番で作業なんてできない
だから小さくコミットして入れ替えたり統合するわけだが
svnじゃ面倒でやってられんよ

>>188
馬鹿か？それ実質コンフリクトしてるわけだから意味ないだろ。

それコーンフレークやないかい

>>189
コンフリクトしてないことにたいして、
実質コンフリクトとはどういう意味ですか？ｗ

それコーンフレークやろ

>>184
なるほど、でもレビューの話しとかってtrunkへマージする前の話しだから、svnだと開発用のブランチで済んでいる前提。

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

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

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

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

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

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

>>193
？？？
「中央に持っていく」だけならpushでしょ？
rebaseは「細かい単位でコミットログが残っている」ようにするためだけの操作ですよ
分散型であることとは関係無い

>>194
ある程度まとめてレビュー依頼するなら、まとめたブランチで依頼すればいいだけ。と言うか、修正単位でブランチ切れば良いだけ。気に入らないならいくらでもブランチ切り直せば良いだけ。

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

>>195
そうなんだけど、実運用で考えると、svn方式で何ら問題は(ほぼ)無いと思うって話し。

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

>>196
> ある程度まとめてレビュー依頼するなら、まとめたブランチで依頼すればいいだけ。

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

> そもそもsvnだと分散して無いから細かいコミットも全部中央に残ってるから、どれをまとめようとか考える必要も無い。

「気に入らないならいくらでもブランチ切り直せば良いだけ。」
でしたっけ？大量の気に入らないブランチが大量に残ってますね。大量にｗ

「全部中央に残ってる」って言ったのはお前だからな

>>199
大量に気に入らないブランチが残ってる？
それで良いんだよ。何なら個人名とか入ったpersonalなブランチ切っても良いし、それがsvn。

>>200
本流にマージされないゴミブランチが残ってることで何の意味があるの？
手段と目的を履き違えているな
ソースコード管理ツールというのはボツ案を残す場所ではない

ついでに補足すると削除してスッキリする事も出来る。ただログには残るので復元は可能。昔のリポジトリでドキュメントが入ってるから今見たら80万コミット超えてるが運用上何も困っていない。

gitの話しかしてないな
Githubの話ししろ
メロンパンのスレで
メロンの話ししてるようなもんだぞ

やっぱりコーンフレークやないか

>>202
電気がない暮らしをしてる人は、電気がなくても困ってないと言うもんなんだよｗ

>>205
だからそれがあるなら知りたいんだよな。まあ便利なインフラが安いのは理解出来るが。

>>206
↓これに対するお前の反論は「俺はそんなものない世界で生きてるから不要」だろ？

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

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

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

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

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

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

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


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

>>207
いや、1、2、3のどれも重要だとは思う。但し、svnで運用する場合は1、2、3のどれもmergeを使っても結構簡単に実現出来る（実現出来るし、そう言う設計思想だと思っている）。

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

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

SVNの作者はなぜブランチをコピーとして実装するのがいい考えだと思ったのか

trunk, branches, tagsを使う標準に従ってない変な構成のリポジトリをgitに移行するのが難しい

GitとGihubの違い説明できないバカおる？
最近ガチで居たので気になった

このスレにいっぱいおるぞ。
むしろだれもGithubの話ししとらん。

>>208
あのさぁ「svnでも頑張ればできる」って言ってる時点で
ダメだってわかってるの？

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

svnの欠点はサーバーに大量のゴミコミットログが残ってることだな
宝探ししたいんじゃねーんだから
ゴミがたくさんあるのはデメリットでしかない

Githubについて話したいことがあるなら、話してもいいんだよ？
はい、みんな注目！
これから>210や>211がGithubについて皆が聴く価値のある話をするよ！

GitHub Actionsってオープンソースは全く制限無いの？

Githubにはライブラリ利用者としてお世話になっているけど、自分でソースコードをアップロードとか、他人のソースをコミットとかやったことない。

よくわからないからコマッタ

くまったくまった

しねばこまることはなくなるよ

COBOLと専用エディタの使い方だけ覚えていれば飯が食えた昔と違い、
今は山のように覚えることがあり、しかもどんどん増えていき終わることがない
こんな無理ゲーやってられない
自分はGithub以前にまずGitの使い方が覚えられなくて詰んでる

おれは最初にジットって教わったから間違えてジットって言ってしまって困る

>>220
基礎ができてないからそうなる

>>222
基礎つーても新しい技術の基礎だから世界が違う
木造平屋建て専門大工が超高層ビルを建てようとするようなもんだ
時代の境目に生きる者はつらい

>>223
そこまで大袈裟な違いではなくて、ずっとノコギリだけ使ってた人がチェーンソーの使い方が分からん、覚えられんと言ってるだけじゃね

Gitのオプションの多さに目が回る
あんな旧態依然としたコマンドラインツールのオプションを覚えるために
成長の止まった脳細胞を使いたくない

老害は言い訳ばっかり
やらない理由を作るのだけは優秀だな

>>226
やったうえで言ってるんだよ
言語覚える前にGitで詰んでる

>>225
普段使っている中でそんな大量のオプション使う必要あるか？

オプションなんて必要になった時点で調べればよい
どんなオプションがあるかだけなんとなく頭に入れておけばいい

今時の開発環境はgit対応してるだろ
日常で使う数少ないコマンドさえ覚えられないならGUIで操作するところから入ればいいのに

コマンドだるいならsourcetree使いなさい

歳のせいにするな、自分が無能なだけだろ
俺は40代だが普通にgitもGitHubも使ってる
GitHubの俺のリポジトリで一番スターが多いのは200オーバーな

評価してやるからURL貼ってみろ

>>227
gitでヒィヒィ言ってるのに言語が理解できるとは思えない

言語は必須
Gitは便利ツール

GitHub社みたいなショボい会社に会社の生命線を預けるのが意味不明
自社でGitHubっぽいサービス作れば良くね？

GitHubはMicrosoftに買収されますた

>>236
マイクロソフトがしょぼいってw

CIで時間がかかっていってGitHub Actionsに乗り換えてるんだけど
今更だがGitHub Actionsすごすぎね？

オープンソースなら無料なのに並列数20で制限なしとか
やっぱクラウド自社で運営してるMicrosoftは違うな
買収されてからかなり良くなってる

Azure DevOpsのパイプラインがよくできてたからノウハウがGitHubに生かされてるね

他のCIサービスだと、無料で大量のテストをやるのは気が引けるんだが
金持ちマイクロソフトなら遠慮しないですむ

どうせgithub使うんだから結局commit早くたってclone/push/pull/fetchでネットワークアクセスして遅いだろ。
まあgithubと言う名前だけどsvn-serverとしてそのまま動くからなぁ。結局、みんな分散分散言っといて中央リポジトリがシンプルで大好きなんだよな（笑）

分散も中央も両方できるからgitを使うんですよ。
gitは中央を捨てたわけじゃありません。両対応なんです。
それだけでもsvnより優れてるってわかるでしょう？

svnよりgitの方が多機能なのは誰でも知ってるし否定もしないしgithubは便利。ただgithubしか知らないのは微妙

svnで十分派の皆さんはとりあえずこの辺に目を通して、svnとgitの考え方の違いを知ってから文句言っていただきたい

https://qiita.com/kaityo256/items/81e7951a1ca2706955a4

自分のコミットでプロジェクトが滅茶苦茶になるかも
それを集中攻撃で責められるかもと思うと
恐くてコミットできません

gitを使えばプログラムの競合が起こらないと信じ込んでいた
新人でもない中堅ＰＧがいっぱいいた

>>247
そうか。だがそれはgitの問題ではないし、gitが優れていることに違いはないよな

gitのせいじゃないとか優れてるとか劣ってるとか
そういうのはいい

問題があるのを認識してないのが問題なんじゃ

そんな会社辞めて転職しろ

>>249
人の問題か、技術（git, github）の問題をかをはっきりさせてるだけ

すぐ人の問題に帰着しようとする脳が腐った論法は富士通のにおいがする

>>252
何があったか知らないけれど
社会のせい会社のせいにするのがキミだ

人の問題は人の問題で、そういう問題があるっていうのは事実でいいんだよ
うちの社員は馬鹿ばっかりだから、うちの会社では導入できません。というのも
導入できない立派な理由

だけどそれを、うちの社員は馬鹿だからgitは難しい。つまりgitは難しいという問題がある。
gitの問題だ。って問題をすり替えてはダメ。

問題をすり替えると、問題の解決策が変わってしまう。
うちの社員が馬鹿という問題だって理解していれば、
その馬鹿に勉強させるか、クビにして入れ替えるっていうのが解決策となる
問題をすり替えてしまうと、本当に解決しなければいけない問題が見えなくなってしまう

>>252
君は楽観的すぎる
Fだけじゃないんだよ

>>245
内容が微妙だった。mergeとか絶対にどっちでも変わらないし。

svn脳といえば、
・ブランチを作成するのに躊躇する
・マージしてからテストする
・古いコードでの上書きが頻繁に発生する

>>245
今ですらsvnとgitを併用してるやつの記事なんて信用できるのか？

git脳がsvnｗを使った場合というケースが抜けてる

>>258
今の話なの？

SVN脳だとresetやrebaseがまず理解できない

svn+ローカルリポジトリ=git
と考えればsvn使いにもイメージしやすいと思うがなぁ

リポジトリが複数あるって気持ち悪くてダメだわ
やはり中央に一つであるべき

ソース管理の粒度ってどれぐらいでやってる？
・少しでも更新したら（ビルドができなくても）コミット
・ビルドエラーは関係なく、自分の中で区切りのよいところでコミット
・ビルドエラーが出ないところでコミット
・最小限の修正が終わるごとにコミット
・ある程度の修正群の１つのまとまりごとにコミット
・修正プロジェクトが完了するごとにコミット
・製品リリースごとにコミット

コミット（push）するタイミングってどうしてる？

粒度

>>263
分散管理ツールでも普通は中央レポを運用で指定してるもんだろ。大した問題じゃない。
てかいちいち中央と同期とるシステムのがめんどくセーわ

>>254
それは使えない方が馬鹿なんじゃなくて、教える方が馬鹿なだけ。
gitのコマンド全て教える必要なんてないし最低限必要なことはgitでなくても結局必要になる。

>>264
お前コミットメッセージ適当だろｗ

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

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

だいたいコミットとpushのタイミングは別だ
pushとマージのタイミングも別だ

作業ブランチで小さくコミットしていって
最悪でも他の人に見せるとき、
区切りのいいときやCIにテストさせたいときにpushする
pushしても終わりじゃない。さらに修正を入れるのも普通
コミット追加して、rebaseして
作業ブランチはいくらでもgit push --forceしていい

そして作業ブランチが完成してテストもOKになったらマージするだろ
そうすりゃmasterブランチにそれら複数のコミットが取り込まれる

サーバのソースをリアルタイム修正してる（CTRL+Sで保存される先が本番サーバ）なんだけど
おまえらは違うの？

別ブランチが長く運用されてマスターと統合不可になってるのが嫌

管理ソフトが余計な管理増やしてる

>>264
ちなみに管理する側からすると毎日コミットしてって言ってる(gitならpush)。下手な進捗報告されるより一番手っ取り早くて確実。

>>270
そんなことして壊したらどうするんだ！

>>274
その緊張感がいいんじゃないか
自然とテストも増えるよ
修正して即テストが習慣になるし、ユーザーがいつどんな操作するかを考えながらコーディングするようになった
いいことばかり

> 修正して即テストが習慣になるし、

テスト実行するだけじゃダメだろｗ
バグってたら直せよ、時間をかけて

>>271
定期的にmasterからマージすりゃいいんじゃね？

>>271
svnだとrebaseができない（面倒くさすぎて事実上不可能）から
ブランチとマスターが剥離していっちゃうんだよね

乖離って言おうぜ

Ｇｉｔはローカルがすぐこわれて使いづらい

>>280
俺は壊れた事ないなぁ
何したら壊れたの？

ほかのブランチ見たらこわれた
チェックアウトしたらこわれた
ファイルセーブしたらこわれた
こわれまくり

自分で改行コード勝手に変換しといて管理外でファイルが変わってるから扱えないとかエラー吐きやがる
人間なら首絞めて殺してるところだ

何もしてないのに壊れた

svnは何をしてもなかなか壊れなかった

イケてるエンジニアを装いたい人間の不誠実な態度が
Ｇｉｔの進歩を遅らせてきたにちがいない

壊れないかどうかじゃなくて、
開発しやすいかどうかだ。重要な点は。

svnは開発が苦痛で仕方なかった。
ソースコードを書く時に間違えないことが前提になってる
「これでいいかなー、エンター・・・あー、あれ忘れてたー！」
という苦痛がsvnには常につきまとってた

svnはまるでCTRL+Sのように頼れるやつだった
gitはフォルダ丸ごとコピーと同じノリ

gitはフォルダ丸ごとコピーと同じノリとは
どういうことをしてるの？

仕組みを理解する頭がなく、
ふんわり感覚で理解したつもりになってます、
という告白だろ

>>236
マイクロソフトがしょぼい会社？？？

>>278
コンフリクトして無い限りsvnでも1コマンドだと思うんだけどな。rebaseの方が楽な気はするけど

>>280
分かる。操作ミスなんだろうけど、調べるのも面倒だしローカルgitが絶対に健全なのかどうかを(チームメンバと同一状態かいなかを)確認する手段が無いから結局cloneしちゃう。

コーンフレークやないか

>>292
git checkout master
git reset --hard origin/master
すれば楽になれるのに

>>291
> コンフリクトして無い限りsvnでも1コマンドだと思うんだけどな。rebaseの方が楽な気はするけど

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

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

>>295
trunkへのコミットを自分のブランチにマージするだけじゃない？ソフトが自動で差分見てマージしてくれてコンフリクト起こった所だけ専用のdiffソフトが出てマージの仕方を選ぶだけ。気持ち悪くなったらtrunkから再度ブランチ切って自分のコミットを古いブランチから選択してマージしても良いし、複数コミットまとめても良いし。gitだとコンフリクトしてももっと楽？

>>294
経験的にそんなぐらいじゃ治らんな。自分の操作が相当適当って事かも知れないけど。

>>296
どっちからどっちにマージしようが
自分の変更と相手（master）の変更で同じ箇所をいじってればコンフリクトになるんだよ
コンフリクトの数が少なければ修正は楽
だからこまめに修正しないといけないが、それはこまめにtrunkをマージしてればいいってわけじゃない
そんな変更が多数入ったブランチなんてレビューできねーだろ

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

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

>>206
> 気持ち悪くなったらtrunkから再度ブランチ切って自分のコミットを古いブランチから選択してマージしても良いし、
それがrebase。簡単なやつなら1コマンドですぐ終わる。

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

>>297
それってcloneするのとほぼ同義だぞ
やったことないでしょ？

それコーンフロストやないか

>>297
git fetchした？

みんな当たり前のようにコンソールコマンドベースで話してるが
ＧＵＩ使ってないのか

GUIの利点は一覧性が高いことだから、過去のcommitの確認の時とかには使ってる

普段はvscodeやtortiseGit
特にIDE連携は便利でいいね

>>303
GUI使ってるけどみんな使ってるGUIアプリが違うからコマンドで説明した方が多くの人に通じるだろ
コマンドが共通言語みたいなもんよ

>>299
納得した。それは間違いなく一手間減る。svnだとGUI側で過去コミットログ引っ張って来て連続自動コミットするしか方法が無い。

svnでもgitでも操作方法はたくさん資料があるんだけど
運用方法はないんだよね

git-flow

ムチムチ

https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf

お好きなものをどうぞ

>>307
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Keeping a Branch in Sync

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

svnを使ってた頃は、svnの使い方が全くわからなかった
間違ったとき修正が大変でこんなんでどうコミットしていけば良いんだよと思ってた
開発がすごくやりづらかった

svnの使い方がわかってないだけかと思っていたが
gitになってからやりたいことができるようになったので
svnというツールが悪かったんだなぁと気づいた

巻き戻しの大変さに違いがあるもんか

やっぱり、こういうのは、ちゃんと管理者にやらせなきゃダメだな。
専任の管理者を決めて、コミットだのプッシュだのマージだのは
すべてそいつにやらせるべし。
技術者には一切触らせちゃいけない。

そういう管理こそ、新人にでもやらせればいいんだ。

マージ担当（笑）がいる会社って都市伝説じゃないの？

コミットを専任の担当者が？
マジで？

コメット担当者ってwww

俺はコメント担当者だった

コメットさん

60代がわいてでたぞー

こんにちはGitHub普及担当の皆さん

パワーをメテオに！！

キングベヒーモスさん

>>316
あるよ
インテグレーションチームて呼んでた
マージして動作確認するチーム

>>316
ソース管理担当者はいたよ
マージだけじゃなくてコミット含めて全部その人を通さないと出来ない

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

マージする担当者を置くのは意味分かるけどコミットの担当者は理解不能だな

コミットするのに判子集めるの？

責任者ってことだよ
バグをリリースしたら全部コミットの担当者の責任になる

責任のなすりつけ合い乙

最低な職場やな

そう、責任者をちゃんと決めないから、
責任のなすりつけ合いになるんだ。

ギットはそういう傾向がさらに強い。
ギットさえあれば管理者が要らないぐらいに思われてるようで。
ルール厨なんてのが涌くのがその証拠。

これどうするんですか？みたいに
ちょっとずつ質問や確認のふりして
相手をだまくらかしつつ要求範囲を広げていくのは
ＳＥの必須技術といえよう

責任者はやりたくないけど自分の合意無しに何かやるとキレて足引っ張りモードに変形して
そういう時だけ生き生きと活動するアニマルだらけの動物園

>>332
管理者「ルールを作るで！」

わいがルールや！

非正規のルールは俺が決める by 派遣王 竹中

git我慢の子であつた

>>326-327
githubをFreeで利用してる貧乏ゴミカス企業かな
「Team以上で利用して毎月xxドル払うのが嫌だ」っていう貧乏奴がいて
全員同じアカウントでチェックアウトとかコミットとかしてた

誰がコミットしたか分からんからコメントルールとかできたが守られないままデグレが起きたんで
責任者を用意してそいつにマージを全部投げてたら、そいつが出て来なくなってリリース遅れますってあったわ

コンフリクトの修正を恐れるやつは大抵コード内容を理解していない。

そもそもコンフリクトというものが起きることが理解できない
ソースごとに担当を割り振るもんじゃないのか？

>>341
いや、機能ごとに割り当てだろ

それコーンフレークとちゃうか

>>341
ソースごとって？

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

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

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

そないやったらコーンフレークちゃうか…

>>342
そうか？
普通はソースごとに割り振りだろ
一つのソースに複数人が手を入れるなんておかしい

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

>>346
> 普通はソースごとに割り振りだろ

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

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

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

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

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

>>347
ソースが一つなら担当は一人に決まってるだろ

>>348
つまりお前は同時に開発ができないって言ってるんだよ
現実的じゃない
大規模なゲームで一人で開発してるなんてあり得るか、アホが

コーンフロストやろ

例えば初期化処理とか複数人が一つのファイルを編集する部分だよね

複数人が開発するんだったらなるべくファイルわけるでしょ
大勢が同じファイルを編集するとかってソース管理ソフト使っててもできれば避けたい

>>352
俺が聞いてるのは「どうやって担当を決めるか」なんだわ

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

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


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

ソース振りかけるんやったらコーンフレークちゃうがな

>>353
各人の開発負担が均等になるよう、お前はソース1〜5、お前は6〜10てな風に決めるだけ
コーディング部隊のリーダーの仕事の一つだと思うが

>>355
質問に答えてほしいんだが

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

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

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

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

必要最低限の箇所だけ修正しないからそういうことになる

>>356
しつこいなあ
頭割りなんだから何だっていいんだよ
名字の頭文字順、席が近い順、身長順、その日出勤してきた順、くじ引き…お好きにどうぞ

コンフリクト起こさないように無理くりやるって完全にアンチパターンだし、
バージョン管理ツール使う意味ねーわ。

コーンフレークやな

>>358
しつこいも何も答えてないからね
つまりお前はソースコードを見ないで担当者決めるんだろ？

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

早く済ませたいならコーンフレークちゃうか

チョコクリスピーやろ

オールブランやな

担当者なんてredmineみて各自勝手にチケットとっていくだけだろ？
修正なんて大抵は1ファイル数行だ

機能追加ならもうちょい規模が大きいがそれは凍結するだろう

複数の人が無秩序に同じファイルを修正するケースが思いつかない
VB.NETみたいに1ファイルに1万行あるようなケースならともかく
普通の言語なら数十行だろう

どれだけ大規模なら衝突しちゃうんだい？

なんも関係してない複数プロジェクトのソースマージは結構神経を使うからなあ、どうだろう・・・。

同じ場所を複数人で修正するパターンって
要するに共通で使うようなフレームワークに相当する部分が未完成ってことでしょ？

1ファイル1万行の糞コードならどんなVCSを使っても無駄だ

低能がうじゃうじゃいるスレだな

>>365
> どれだけ大規模なら衝突しちゃうんだい？

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

>>367
ソースコードが単一責任の原則を守れてないとか色々ある
最初から完璧に設計されていて、小さくモジュール化されていて
変更が入るたびに、その内容に応じて設計もちゃんと再構成していれば
コンフリクトが起きる可能性は低くなる

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

>>365
本当にチーム開発したことあんの？

チーム開発してると手の遅いやつが文句言い出すけど
定期的に手元のソースを最新にしてからそういうことを言ってほしい

おまえたちって本当に末端のゴミPGなんだな・・・呆れたよ・・・

四半期の会計期間ごとに大規模システムの改修計画の予算がおりて
別々のチームが同じソースの改修を同時進行で進めるケースとかに参画したことがないんだな

道端の犬のクソにたかるウジ虫を見ている気分になる

あいつSESかよ
技術者じゃないじゃん

采配がヘタなだけじゃん。
そんなのをSVNやギットのせいにすんなや。

何かを修正する時に、ソースコード単位で采配なんてできないって話だぞ

数千人規模だと逆にソース管理失敗って聞いたことないよね

>>376
上から采配が落ちてくるならそうだろうね。
それならバージョン管理ツールに神経使う必要もないだろうね。

上から采配が落ちてこないんなら、それは上がサボってるだけのことで、
まあ下手以前に論外だな。

これバージョン管理ツールであって平行開発の為のツールじゃないよね

並行開発しないチーム開発なんてありえんだろ。なんでこんなに愚かなの？

ファイルごとに担当者決めるなんて非現実的だってまだ理解できないのかよ

並行開発しないチーム開発なんてありえないのに適したツールがない

分散の場合は同期とるのが余計に面倒に思えるんだがどうやってるん？
git入門とかでググっても老人PGが疑問に思う一番重要なところが説明されてない。
git屋はエスパーPGばかりで以心伝心なん？

それともlinusみたいにおまえのコードはマージしてやんねぇとかケンカばかりしてるん？

>>385
gitは小さな変更だけを含むfeatureブランチのチームでレビューしてからマージを繰り返すスタイルがよく使われる
Git FlowとかGitHub Flowとか
でか過ぎるとレビューしづらくなるし、コンフリクトの影響も大きくなるからだ

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

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

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

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

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

ブランチ開発してるときに元の関数のインターフェース変わったりしたら
なんぼリベースしようがマージしようが解消できんと思うのだが

やっぱコーンフレークやないか

>385
そう。
クソコード入れるより喧嘩する方が正しい。

> gitは小さな変更だけを含むfeatureブランチのチームでレビューしてからマージを繰り返すスタイルがよく使われる

これが知りたかったんだよね。
git、git言うからどれだけ効率がいい開発手法なのかと思ったら全くの逆で、非効率で泥臭い方法だったか。

内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで、
分散管理のせいでマージ、レビューするまで分からないとかデメリットがでかすぎる。

OSSの開発が遅くバグが放置される理由、forkしまくる理由はすべてgitのせいだな。

gitは糞ってこき下ろすだけの
代案無しの野党みたいな奴しか居ねえな

gitのブランチのマージは怖い

>>390
>内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで
それがすぐできるならまあどんなバージョン管理しても問題ないだろ。
多分お前はできてないだろうが。

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

>>391
いいえ、単にgit知らなくてググってもちゃんとした説明ないから質問しただけですよ。
古い集中管理型ならコーンフレークの遅延はなく、単体テストしてコミットしたのにちゃぶ台返しされるリスクも少ないでしょう？
だから分散管理で問題になるこの同期の遅延リスクをgitではどうやってるのという疑問でしたが、
泥臭くケンカしながら解決するということで疑問は解決しました。

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

SVNは一つのブランチで闇鍋して
コミットしようとして初めてコンフリクトになるか
ロックという偽りの安心感を与える道具に頼るかだ

GitFlowもどきをSVNでやる事は普通ない

ボクが考えるgitの運用方法が一番正しいんだみたいな

ある程度複雑性や規模をもった要件に対しては分散管理は非効率でしかなく、
結局Linuxの例を出すまでもなく、OSS陣営の多くの開発がMSより10年遅れてると言われるのも頷ける。
今ではMSもgitに手を出すからブラウザ開発に失敗したり、Windows10はAppleのように互換性切り捨てだらけになってしまった。

縛りのない開放感なんて所詮、責任の放棄でしかないんだよ。
馬鹿な大臣がハンコを無くそうとしてるのと同じ。

>>395
gitflowってsvnの一般的な運用だとdevelopがtrunkってだけだな。featureもreleaseも古くからある運用そのもの。
hotfixって言うリリース後の修正は、svnだと、該当バージョンのreleaseブランチ延ばすんだがな。

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

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

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

>>397
>>最後はoutlook
最後は電話

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

メールこそ正義
証跡をあとから編集できるslackや何言ってたかわからない電話のやりとりなど業務連絡のうちにはいらない

まあおれだったら、素直に会社に行くんだけどね。

SVN使っても変わらないは流石に老害の暴論

だからまあ、前にも言ったけど、こういうのは、
ちゃんと管理責任者を決めて、そいつにやらせなきゃダメだよ。
そいつはsvnでもギットでも日付フォルダでも好きにやればいい。

で、tortoiseなんて末端作業員のマシンに入れさせちゃダメ。
リポジトリURLは、会社のトップシークレットだと思わなきゃ。

同じくDVCSのMercurialはrebase機能あるけど
拡張機能が必要
できれば使ってほしくないみたいな感じ？

gitは最初からrebase可能
何をしようとしているか分かっているんだから
邪魔をするな！と言うリーナスの思想が現れている

force pushをfeatureブランチ限定にしても、
rebaseをすると、それをする前のfeatureブランチの履歴が失われると言うデメリットはある

>>399
メールとSlack併用してる現場で言動一致しないリーダーがいるときに
「メールをエビデンスにしたい」一心でメールで重要事項を周知すると
出荷前のブタのように発狂するから怖い

>>397
おまえなんも知らんのだな・・・メール頼みは怖いぞ

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

内部の人間の問題はセキュリティだけじゃ何ともならんよ
出したときにID,パスワード,アドレスを全部消すか変更しとけよ
それでも別のアドレスで接触も可能
そんなもん人間の問題だし、捕まったなら追跡できたわけで完全な抜け穴だったわけでもない
抜かれても追えない、気が付かない方がよっぽど怖い

>>394
gitでも中央管理をすりゃいいだけだろ
分散管理が「できる」ってだけで、分散管理が必要のないケースでは分散しなきゃいいだけ

別にgitが管理してくれるわけじゃない

なるほど。だからgit使えるだけでマウンティング取る開発経験のない若いPGがgit使うと
デスマーチ、開発放棄になるのも当然だな

てかマージがうまくできないならpushすんな
ってのができるだけでもgitの価値あるだろ。
その辺、中央管理だといちいち普通の作業でも同期とるっていうのがクソ厄介。
ある程度コミットが整ったらpushっていう分散管理のが明らかにまともだわ。

SVNにはstashもない

stash相当の事は自分でパッチファイル作ってやる必要がある
めんどくさい

ハッキリ言ってsvn擁護派では無いが、

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

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

GitHubありがとう！
わからないとこ検索したら凄い人見つけて真似して解決した
ありがとうGitHub！

ソースとってきて修正して戻す
っていうスパンが長すぎたら結局どうにもならんでしょ
迷惑かけない程度に手を速く動かせよ

>>412
svnだとコンフリクト起こしたらはっきりストッパーになるだろ。
まあそれがいいという人もいるかもだが、無駄なプレッシャーだったり効率悪くしたり、あんまいいことだと思わん。

>>415
本気で言ってる意味が理解出来ない。gitだと行単位でコンフリクト起こしても自動で解決してくれるとでも言いたいのか？？

バージョン管理システムに幻想を抱きすぎ

>>416
そのコミットは捨てといて他のところをいじるってのができるだろ。
コンフリクトがどれくらい致命的かわからんのだから一般にそのコミットを入れないで他をいじるってのが、
中央管理だとやりづらいってことだ。
一人で一点だけ見てればそういうことはないんだろうが。

コーンフロストなのかコーンフレークなのかどっちや

コーンフロスティやろ

gitなんて大した技術がいるものでも無かろうに
未だに触ってないのはよっぽど頭の固いやつだけだ

ドキュメントのバージョン管理ツールください
末端にはマイナーバージョン3つくらい違うやつしかこない

>>422
降ってきたドキュメントの整理したいって意図？
ドキュメント作る側で管理してないとほとんど恩恵無いんじゃないの

つ えんぴつ

つ ノート

>>413
パクられた人 「おい、ドロボー。カネ払え。」

最新バージョンを編集してくれと言われたから、コミットハッシュはどれですかと聞いたのに、
とにかく最新バージョンをいじれの一点張りの馬鹿がいたりする。
自分らの使ってるものなのに何もわからんって輩が巷には多い。

最新バージョンをいじればいいんじゃないか
特定に何の情報が足りなかったんだ

>>426
最新バージョンという情報で十分だろ

>>421
何使おうが他人の勝手だろう。
既に触っているべきだとか原理主義的で脳みそカッチカチだなw　リアルで馬鹿すぎw

>>426
おまえもわかってないじゃないか

俺も最新バージョンで良いと思うが、最初に言質をとっておかないと
「あとでそんなこと言った記憶はない」って暴れだして面倒だろ

社内でめんどくさすぎる

天才 「できましたー」

バカ 「最新、最新のやつ編集しといて」

天才 「branchが最新だったので編集しましたー」

バカ 「はあ？masterの最新のつもりで言ったんだよ！」

天才 「なら最初からそう言えよ( ﾟдﾟ)､ﾍﾟｯ」

>>433
チェリーピックで大体対応できるだろ

>>434
馬鹿

エスパー要素が必要になるよな

>>433
特定のbranchとmasterが逆の方がありそうじゃね?

>>434
賢いな

チェリーピックって何か響きがやらしい

>>439
やらしい事に現実世界だとあと一歩と言う所でなかなかチェリーピックし放題にはなら無いもんなぁ

masterじゃなくてmainですわよご主人様♪

え？


ﾔﾊﾞｲﾔﾂｷﾀ・・・？

>>431
開発スピードが速いと毎日幾つもコミットがあるので
コミットハッシュなんか決まるわけないだろ

だいたい同じコミットハッシュなんか複数のブランチに存在する
コミットハッシュを聞いても最新バージョンにはならない

なぜSQLiteはソースコード管理にGitを使わないのか？
https://www.sqlite.org/whynotgit.html

おまえが使える技を全員が使えるなら使ってる
おまえしか使わないものを全員は使わない

>>445
This article is not advocating that you switch your projects away from Git.
You can use whatever version control system you want.
If you are perfectly happy with Git, then by all means keep using Git.
But, if you are wondering if there isn't something better, then maybe try to understand the perspectives presented below.
Use the insights thus obtained to find or write a different and better version control system, or to just make improvements to Git itself.

>>447
社交辞令みたいなもんじゃん。
なに慌ててるの？ｗ
ひょっとしてバレたら困ることでも書いてあったのかな？ｗｗ

>>443
じゃあ入れるタイミングテキトーでいいんすね？って聞くと大抵文句言い出すんだが。

>>449
それgitの問題か？

> to understand the perspectives presented below.
肝心の理由もここにかいてくださいな…

フォッシルかギットか？
って話なのでSVNとかCVSとかVSSは問題外

>>450
gitの問題ではないがツール馬鹿の問題やな。
馬鹿は無理してわからんもん使うなや。

>>447
完全にgitってちょっと...って皆が薄々思ってる事が書かれてるなw

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

gitの一番のメリットはやる気が出ること
コメント欄に「〇〇を修正」って書く習慣が出来るだけでけっこう違う

git以外でも一緒じゃねーか

gitのっていうから誤解があったな
バージョン管理ツールのメリットな

Mercurialはなんでgitに負けたの？

アルファベット3文字じゃないから

hgって略称があるフォー

svnはマージがアホすぎて使うの嫌だったな
今はマシになったのかな

Mercurialでググったら一番上にネガティブな記事きてるのも影響あるんじゃね

>>23
組み込み系だけど
バージョン管理ツール使わないのは、ありえないわ

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

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

バージョン管理ツールは、怠けものエンジニアほど便利さに病みつきになるから
とりあえず使っておけ

>>433
というか、ブランチは別の機能を試す時や別プロジェクト派生のときだけで
普通は最新版といえばトランクを差すだろうに

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

>>422
ＳVN使えばいいじゃん

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

>>422
それはツールの問題じゃない・・・

こまめなコミットすらめんどい
監視下のファイルが変更されたら適当なコミットメッセージで勝手にコミットされる設定、どうせできるんだろ？
どうやるのか教えろ

>>465
gitの話やで

>>468
お前にはDropboxで十分だ

たいては社内で数人のチームで使うのに分散gitにするメリットって何ですか。

>>471
ローカルだけでブランチきって試行錯誤いろいろできること

>>470
hooksとかでできるんだろ
隠してないで教えろ

>>471
サーバーに繋げない環境でもcommitできる

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

リスク管理ができてねえだろうがよ
だれしもサーバー飛んだら仕事が飛ぶのは怖いはず
最初から分散しとけ

>>472
>>474
それは個人で利用するメリットであってチーム関係なくね

>>475
バージョン管理ツールのサーバーは最低でも日次バックアップとってるでしょ

>>476
チームだと試行錯誤しないんか？

人間が最初からミスをしない完璧な存在だったらフォークもローカルブランチもGit Flowも要らないが
普通は色々改善点に気づいて修正する
最初から完璧な物など作れない

ウダウダとルール決める前に、ますは責任者を決めろっつーの。
老害たちはお前らと違って「責任」ってのを負ってるんだよ。

責任者「原因はコイツのミスです」

>>476
チームのリポジトリに個人で試行錯誤してる過程を入れられてもウザいだろ

>>482
個人的って、業務時間に試行錯誤してるんだから、それは業務だろ。その間のエビデンスを報告出来ないなんて何年社会人やってるんだって感じだぞ

>>483
それでゴミコミットを各自がたくさんpushしてんの？
あほらしー

いやrebaseしろよ

経過報告として1日1回はpushするが、
上流と比べて古い状態になったらrebaseして、
機能が完成したらrebaseしてpushすれば良い
要らない途中経過を結合して1コミットにするとかはお好みで

そもそも最近のエディタはローカルリポジトリにコミットしなくてもローカルなヒストリー機能備えてるだろ

>>487
それは関係ない

>>488
でもそう言う目的でgit最高、分散リポジトリ最高って勘違いしてる人多いと思うんだけどな

試行錯誤なんて勝手にすればいいじゃねーか
そもそも試行錯誤する段階で就職すんなって話だよ

>>490
意味が分からない

>>490
お前の仕事は試行錯誤がまったく要らない単純労働だけなのか。そりゃ分からなくても仕方ないな。

他人がハマるところは自分もハマるものだ。
いろんなソフトがバージョン上がると先祖返りエラーするのは試行錯誤を引き継がないから。

プログラマでよく「自分で試してみろ」ってタイプの人いるけど
あてずっぽうで自分のローカル環境でうまくいっただけの事を実装しちゃうのはまずいよね

自分で試してもいない馬鹿よりはマシだけどね。

そのローカルをベーシックにしろよ

ngrokでお前のローカル環境が本番サーバーになるんや

[和訳] Dropboxアカウントのせいで胃潰瘍になった
https://qiita.com/ktnyt/items/a4729e11b465c8f65478

Gitが分からないエンジニアだけで作ったチームなのか
Dropboxにソースコードだけでなくデータベースも全部突っ込んだ奴の話

>>498
ネットワーク負荷が重かったってのは良く分かった。でもセキュリティ面からするとdropboxだろうがawsだろうが変わらないと思うけど。

ソースが完全な形で残ってるだけまだマシな案件じゃないだろうか

セキュリティに関してはドロップボックスが悪いというよりもパスワード管理の問題じゃないかな
これは確かにAWSでも一緒
人が辞めた時にパスワードをどうするかはけっこう面倒臭い問題

パスワードは共有しないという当たり前のことをやるだけじゃね？

おじーちゃんなんでクラウドなんて信じてないです。
余ってる世代遅れのPCで社内サーバ立ててちゃんとバックアップ取ったほうが頭ハゲないですね。
クラウドしてる人はハゲ率高すぎです。ハードが見えないと不安になるからだと思います。

>>502
GitHub Enterpriseはオンプレミスサーバー対応してますからおすすめですよ

>>501
アカウント１つあたりいくらかかると思ってるんだ

クソ馬鹿相手ならmercurial使った方がマシなんだよなぁ。。

fossilだろjk

>>502
githubよりお前の会社のが信用ならんだろ

>>502
そのハードの電気代、冷房に掛かる費用、ハードの保守費用は考えないのか

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

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

後頭部あたりが相当薄くなってますね。

こういうクラウドだのAIだの革新だの言って丸投げしてるアホほど、
トラブル起きるとすぐ会社から逃げていなくなるよな。

>>510
そういうレッテル貼りはよくないね

逃げ出した革新君の尻拭いするのはいつも結局、
低層から上層まで経験のあるじーさんエンジニア。

政府がAI名目であっちこっち予算つけてたけど成果でたやつあるの？
みなさん税金で天下りしてボーナス、退職金貰ってトンズラでしょう。

AIで1番売れたのはドラクエ4だと思う

>>510
トラブル発生したらおまえらのせいになるだけだよ
なぜ逃げなきゃならないのか

>>514
AIの歴史の中でクリフトはずっと語り継がれるんだろうか

ボスにザキしか打ち込まんAIなどゴミ

つまりボスのような非日常に対してAIは何も対策を取れないという事

ガンガンいこうぜ
ライアンのこうげき
じゅもんせつやく
ライアンのこうげき
めいれいさせろ
ライアンのこうげき

おおゆうしゃよしんでしまうとはなさけない

ここ、じーさんばっかりやん

むしろ、　>>515　←みたいな下に丸投げして、
失敗したら責任押し付けて切るしかできない無能SEばっかだよな、日本は。

日本以外のどこならできるんだ？
移住しろよ

そんなに日本が嫌なら祖国に帰れよ

ネトウヨはさっさと半島に帰れよな

>>522はネトウヨだったのか
早く本国に帰ってくれたまえ
大歓迎だ

ネトウヨはほんと馬鹿だな

>>522のようなネトウヨはほんと馬鹿

優秀なプログラマなら世界で活躍すりゃいいのに何故か日本に文句を言う

ネトウヨは英語できないから

プルリク来るのは良いけどさー
どこまで修正の仕方を教えてやらないといかんのか
全部俺がやるのと変わらないじゃねーか
さっさとコード出せよ。ダメなところ全部指摘するからさ

おまえが全部コード書けよ

>>531
クソだから後俺が全部修正するわってコメント投げて、ブランチ引っ張ってきてpushしたらええわ。
煽り抜きでそっちのが手っ取り早いことのが多い。

仕事はさみしがり屋
たくさん抱えてる人の所へ集まる

それに英語で大量にコメント書かれても
読んでレス返すだけでも時間かかるっつーの
その間にコード書きたいわ

こっちが一時間かけて大量の英語読んで英語で答え書くと
相手は一時間後にまた大量の英語送りつけてくるからなｗ

ポルトガル語やロシア語でないだけマシなんだなぁ

// I dont speak English
ってコメント各クラスと関数の頭に書いとけ

>>536
大量の日本語を送りつければしばらく返ってこまい

githubの問題じゃなくてお前らのコミュ力の問題やんw

>>534
断れない気弱なクズを殺すまで積み上がるんだよなあ・・・

commitとpushってどう使い分けるの？

毎回commitとpush両方してる
たぶん使い方間違ってる気がしてる・・・

３commits１push法か９commits１push法。
localだけでcommitピストンを3回か9回やって、1pushでoriginまでイク。

ローカルとリモートへの操作の違いがよく分かってないのか？

「ブラック企業社員」のお助けアプリが誕生 開発したのは22歳金髪大学生、開発のきっかけとは？
https://news.yahoo.co.jp/articles/b9d5e3b84e4aa78fab64d3eb8e0c02f72911287e
レシート買い取りアプリONEの17歳起業家、サービス一時停止から｢怒涛の3カ月｣で気づいたこと
https://www.businessinsider.jp/post-175983
ビジネス版マッチングアプリ「yenta(イェンタ)」全国展開 開始！
https://prtimes.jp/main/html/rd/p/000000023.000021544.html
ギフティング「TANP」運営がGCPほかから5億円調達
1日1200件の「リアルギフト」送付も可能に、U25起業家の新たな挑戦
https://thebridge.jp/2019/08/gift-ec-tanp-raised-500m-yen-from-gcp
人はこうすれば“ハマる”、源流はゲーマー視点の「幸せ」
https://project.nikkeibp.co.jp/behealth/atcl/feature/00005/012100006/
アプリ開発での起業は難しくない！成功するために覚えておくべきこと
https://www.biz.ne.jp/subject/blog/2004433/
【稼ぎ方が知りたい！】アプリの開発の収入って実際どれくらい？
https://itpropartners.com/blog/1657/
ネット関連事業で起業した成功例8選！ネットで成功するには○○が重要！？
https://www.official.or.jp/internet-entrepreneurship-success/

フリーランス向け報酬即日払いサービス『先払い』が、オンライン資金調達プラットフォーム『資金調達freee』β版に掲載開始
https://prtimes.jp/main/html/rd/p/000000037.000047439.html
フリーランスやパラレルワーカー同士のマッチングプラットフォーム「conema」が、
案件依頼・仲間募集を中心とした掲示板機能（β版）をリリース！
https://prtimes.jp/main/html/rd/p/000000004.000059389.html
フリーランス薬剤師専門エージェントサービス「きょうりょく薬剤師」、リリース開始。薬剤師の新しい働き方を提唱。
https://prtimes.jp/main/html/rd/p/000000002.000058526.html
中卒、新聞配達員から月収4億の不動産王へ。姫路の不動産王の投資哲学
https://hbol.jp/184178
【アプリ開発で起業】必要な心得とマネタイズ方法のすべて
https://www.dreamgate.gr.jp/contents/column/application-development
副業を認める企業に対して「より魅力的に感じる」人は６割以上。
一方、副業を認めない企業に対する魅力度は６割超が「低下した」と回答
https://prtimes.jp/main/html/rd/p/000000016.000040832.html
みんなが知らない「サラリーマンの生存戦略」副業年収1億円！motoさん伝授
https://diamond.jp/articles/-/247070

ノロケツイートがバズって起業！　カップル・夫婦向けサービス「ふたり会議」が反響を呼ぶワケ
https://www.itmedia.co.jp/business/articles/2008/23/news012.html
コロナで細る“起業”を手助け。クラウド会計freee、スマホアプリで設立書類を作成できるサービス
https://www.businessinsider.jp/post-219220
岐阜大に「起業部」誕生　行動力ある人材を育成
https://www.chunichi.co.jp/article/113792
日本発 “世界最強グローバルEC”を率いる起業家・原田真帆人の挑戦
https://news.yahoo.co.jp/articles/31fc76262ccd7f6646a08d76446f3ba78c6d05bb
起業家から事業家へと自らを進化させなければ、さらにスケールすることはできない
https://diamond.jp/articles/-/245386
爆速で成長する2社の成長の秘訣とは？オンラインイベント 『爆速で成長するスタートアップの始め方』を開催
https://prtimes.jp/main/html/rd/p/000000032.000041941.html
医師兼起業家の草分け　医療事故隠蔽事件が転機に
https://style.nikkei.com/article/DGXMZO62603280T10C20A8000000/
NHKを辞めてユーチューバ―に。起業は「縛られない自由な生き方」なのか
https://www.itmedia.co.jp/business/articles/2008/15/news013.html
会社のDNAとも言えるミッション、ビジョン、バリューをどのように策定すればよいのか？
https://diamond.jp/articles/-/247750

あ、ガイジの琴線に触れちゃったか…

俺ちょっとやりすぎちゃうんだよねｗｗごめんごめんｗ