Git 19

2022/11/06(日) 16:40:27.51

ソースコード管理を行う分散型バージョン管理システム、Gitについて語ろう。

Git - Fast Version Control System
http://git-scm.com/

◆関連サイト
Pro Git - Table of Contents
http://git-scm.com/book/ja
Git入門
http://www8.atwiki.jp/git_jp/

◆前スレ
Git 17
https://mevius.5ch.net/test/read.cgi/tech/1599016710/
Git 18
http://mevius.5ch.net/test/read.cgi/tech/1650651945/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/06/24(土) 09:40:16.93

>>608
今は上級者はrust使うだろ

2023/06/24(土) 13:05:33.61

俺は単に冷静に状況を把握してるつもりなんだけどね。
色々整合性も取れてしまったし、多分そこそこ合ってる。

ソースコードの品質は、判断出来るなら自分で見るのが一番納得するだろう。
ここで水掛け論する意味はないし、議論出来る相手がいるとも思ってない。

Linusが奇妙なほどCVSに対して攻撃的な事については、
実は今現在の俺はLinusのCVS体験をGitで追体験してるだけだとも分かった。
なるほどボロクソにしか言わないのも納得ではある。
ただLinusもアプリに対する人間的な本質部分を修正してないので、
歴史が繰り返し、俺も強制的に追体験させられてしまってる。
この点、巻き込まれた被害者としては、あんたもそこまで言えるほど修正出来てねえよな、とは思う。
(まあLinusはGitをCVSの代替として作ったわけではないので、知らんがな、だろうけど)

あと何か、Git界隈で傍から見て謎な件あったっけ？

2023/06/24(土) 13:06:05.33

>>611
表面的には『関係ない』。ここがミソだ。
実際、ソースコードが糞であっても、アプリなんざ動けばいいのは事実。

ただ一般的にはメンテナンス性を上げる為に品質を保ち、結果的にアップデートが早くなる。
或いは、グチャグチャすぎてアップデート出来なくなるのを防ぐ。

俺の場合は、少し踏み込んだらバグに当たってしまったので、
少なくとも今のGitは俺が安心して使える品質ではないこと、
コードの品質を見る限り短期的には、戦略見る限り長期的にも、改善しないことは分かった。
結果、俺の使い方だと、Gitを使って得られる時間より、Gitを使って失う時間の方が多く、
俺はGitは出来るだけ触らない方針で行くと決めた。

ただ、これまで散々使い倒してきてて、全くバグに遭遇したことがないのなら、
少なくともその使い方では問題ないのだろうから、使い続ければいいと思うよ。

いずれにしても単純に、「Gitを使って得られる時間」と
「Gitを使って失う時間」を比較して決めればいいだけだ。ただのツールなんだし。
(そして初心者の内からGitに精を出し始めると、
本来コードと格闘すべき時間がGit関連に配分され、肝心のコード記述能力が上達しなくなる。
これは初心者は本当に気を付けた方がいい。
そして既にそうなってるのがこのスレやGit周りの連中だ。
だからあんな糞コードでも糞だと認識出来ないわけでね)

2023/06/24(土) 13:14:59.19

>>613
ツールの方はどうなったのか現況くらい報告してもいいんでは

2023/06/24(土) 13:55:42.57

「水掛け論だから俺の好きなように水かけさせろ」

2023/06/24(土) 14:08:47.40

>>616
それはお前もな。

実際、お前自身が確認する以外でお前が納得する方法はないだろ。
ならそれで終わりにするしかない。
対案はないが反対するだけの人種ですか？

2023/06/24(土) 14:16:38.34

>>587
ありがとう。最後のorigin省略するなっていうのは、originを描き損ねるとローカルリポジトリの該当ブランチからマージされてしまうことになるからということだよね？

checkoutは必要ないとのことだけど、
現在masterブランチにcheckoutしている場合、
git pull origin A
だと、ワーキングツリーには変化なし。
もちろんmasterブランチの中身(ソースコードなど)にも変化なし …であってる？

2023/06/24(土) 14:18:00.22

長文君は同じ主張を繰り返してないで自分の開発に戻れ
「必要とされているバージョン管理システムをオレが作って見せてやる」
って言ってたお前はどこにいった？そこで好きなだけ「綺麗」なコード書いてればいいじゃないか
ここはお前の嫌いなgit信者の巣窟なので寄り付くな

2023/06/24(土) 14:21:04.91

>>618
状況にもよるが origin 省略して git pull A ってやると A がブランチ名じゃなくてリポジトリ名と解釈されて A なんてリポジトリ知らねってなるからだよ

2023/06/24(土) 14:26:32.80

>>618
naster ブランチをチェックアウト中に git pull origin A ってやると
1) origin の A を取ってきて、ローカルの origin/A にマージ
2) その後にローカルの origin/A をローカルの master にマージ (working tree も更新)
という動作になる

2023/06/24(土) 16:44:15.37

>>619
ゆとりだね。相変わらずお前らは「ぼくはぜったいだいせいぎ！！！」と信じて疑わない。
俺は反撃してるだけ。反撃されたくなければそもそも攻撃しなければいいだけ。

そしてここがGit信者の巣窟だと知ってるからこそ、
それが問題な場合には俺なりにアドバイスをする事はあるよ。
結果的に大体においてGit信者とは異なる意見になるが、
どちらが正しいかは当人に判断して貰うしかない。まあいつもの5chだ。
逆にコマンドの使い方なんて信者に聞くのがベストだし、実際俺もそれに口挟んでないでしょ。

2023/06/24(土) 17:00:34.99

>>617
だからあんた、その長文を他人に理解してもらおうと思って書いてないわけだろ？

2023/06/24(土) 17:27:14.85

>>622
WitBucketはもう止めたんか？

2023/06/24(土) 17:53:52.56

頑なにゴミ箱に触れないあたりがいい答え合わせになってるわな

2023/06/24(土) 18:09:33.70

質問が続きそうなので予め書いておくと
master をチェックアウトしている状態で git pull origin A とするのは推奨されない（少なくとも初心者のやることではない）
ローカルに
- master
- A
- origin/master
- origin/A
という４つのブランチがあって、master がチェックアウトされている状態で git pull origin A とすると
- master ← 更新される
- A ← 更新されない
- origin/master ← 更新されない
- origin/A ← 更新される
というチグハグな状態になる
git pull は常に引数つけずに使うものと思っておくべき（初心者のうちは）

2023/06/24(土) 19:14:45.47

>>623
それだと意味が曖昧なので厳密にすると、
俺が何を言ってるかの「理解」は出来るように書いてるよ。勿論「同意」はしなくていい。
俺はGit信者だけからの偏った見方に反対意見を付けてるだけだから。

逆にお前こそ、「理解」というこの状況に於いて意味が曖昧な単語を使って意図的に混乱させてるよね。
その辺がゆとりの問題だよ。

2023/06/24(土) 19:19:57.81

>>626
そもそもpullは使うべきではなくfetch とmergeを別々に実行するほうがいい。

特に初心者はpull禁止にすべきだと思うけど、解説とかでpullから解説しているのはなぜかね？

2023/06/24(土) 19:22:04.78

>>627
でバケツだかゴミ箱だかはどうなったんだ？
誰にも理解できねーぞ！

2023/06/24(土) 19:42:42.59

>>628
さすがに禁止はないとかと
git switch master
git fetch origin master
git merge origin/master
みたいに毎回打ってるの？
普通は
git switch master
git pull
でいいだろう？これが一番事故が少ないしタイプも楽なはず

2023/06/24(土) 19:50:47.60

つまり>>616ってことだろ

2023/06/24(土) 21:22:08.93

>>630
俺はリモートの状態がどうなってるかわからないままpullするのが怖いんで
先にfetchするのが癖になってしまった。

2023/06/24(土) 22:21:06.02

>>632
リモート次第だね。信頼できなくて無視する選択肢があればそうするのが良い
一方で共通の中央サーバがリモートの場合は信頼するしかない。そこが間違っていても巻き戻しはできないので、一旦取り込んで修正するしかないし

2023/06/24(土) 22:28:26.37

>>628
> そもそもpullは使うべきではなくfetch とmergeを別々に実行するほうがいい。
まだそんな事言ってるの？
何を根拠にして言ってるのか知らんけど
それ言ったの素人でしょ？

2023/06/24(土) 22:30:03.91

>>632
--ff-onlyをつければいいだけ

2023/06/25(日) 00:23:34.87

>>622
「ぼくがぜったいせいぎだ」と言ってんのはお前だろ
こっちはそれほど反撃するならエビデンス出せやと言ってるだけやで

> 俺なりにアドバイスすることはあるよ。
gitを触るのヤーメターの人間にアドバイスできることはないのでお願いだからやめてもらっていいですか
初心者が困るので

2023/06/25(日) 03:28:04.58

『』が付いたらだいたいミソだよね

2023/06/25(日) 04:33:20.93

例えば、rbenv と、そのツールのruby-build では、

rbenvのインストールは、
git init
git remote add -f -t master origin https://github.com/rbenv/rbenv.git
git checkout -b master origin/master

更新は、
git pull --tags origin master

ruby-buildのインストールは、
git clone https://github.com/rbenv/ruby-build.git "${rbenv_root}/plugins/ruby-build"

更新は、
git pull origin master

2023/06/25(日) 07:35:45.46

>>638
何を主張したいのか分からないけど、それ開発者向けでなくて純粋な利用者向けの記述に見えるが、そこは理解してる？
単なる利用者なら、全部落とすより master だけ選択的に拾ってくればちょっとだけ速いよみたいなやり方

開発者なら
git clone <URL> で開始して
git switch master; git pull で更新すれば良いよ
というかそんな小さなプロジェクトは利用者でも master だけ選択的に落とす意味はなさそう

2023/06/25(日) 07:41:22.18

もしかしたら速度でなくて、ディスク容量とかを気にしてるのかもしれないけど、どっちにしろ、そんなの気にするほどのサイズのプロジェクトか？って思う

2023/06/25(日) 09:03:42.06

>>636
> それほど反撃するなら
どこのこと？というかマジでお前らちゃんと分かるように書けよ。勝手に以下だとエスパーするが、

Gitのソースコードが素人以下のゴミな事は見れば分かるし、それ以上のエビデンスはないだろ。
判断する能力がないのはお前の問題だ。

ああちなみにこれは、
> 素人が求めているソースコード管理は (576)
とか勘違いしているお前らに、「Gitのソースコードも素人以下のゴミなんですが」と突っ込んでるだけ。

2023/06/25(日) 11:00:27.19

「オレには分かるが他の誰にも分からない」ｗｗｗ

2023/06/25(日) 12:24:39.51

>>641
相変わらず日本語の通じない奴だな(通じないからこのスレに居座ってるんだろうな)
エビデンス出せって言ってるんだから、具体的にソースコードの何処がダメでどう改善すればよいかを「わかりやすく」説明するべきなんだよ

お前の言ってるのは子供みたいに「ソースの品質悪くて僕チンこのソース理解できない！ギャオオン！」だけだ

2023/06/25(日) 12:26:36.60

長文くんは何しに帰って来はんたん？
お仕事の合間なら、アレを完成させて自分の言っている事の正しさをここでなく世間一般に問えばいいのに。

2023/06/25(日) 12:40:16.20

これ書くと俺も触ることになるからあんまり書きたくないけど、ソースコードがゴミと思うなら修正してPRするなりフォークして修正したものを公開するか、その作ってるとかいう管理ツールを完成させてGitの「ゴミさ」を証明すればいいだけ。
よほどのバカでなければ、いくらこのスレで喚いたところでGitがソースコード管理ツールのデファクトスタンダードであるという事実は変わらないということくらい理解できるはず。
にもかかわらずこのスレに粘着してグダグダとGitやこのスレの住民の悪口書き続けてるだけ (何もできない子供と変わりない)
この行動だけ見るならただの構ってちゃんでしかないから触らないのが一番だと思う

2023/06/25(日) 13:12:00.59

>>642
いや、見る奴が見れば分かるよ。
どのみち俺がいくら言っても信用しないのだから、君が信頼出来る人に見て貰えばいい。
「素人以下」ってのは煽りじゃなくて、実際に素人でもやらないようなことをやっててバグッてるから言ってる。
だから素人でも、ある程度きちんと書いてる人なら、ああ、これはだめだわ、って、すぐ気づける。

>>644
Gitが目的になるとこうなるよ、という注意喚起かな。

実際、Git開発してる奴も、このスレの誰も、Gitのコードが「素人以下」なのに気づけないわけだろ。
本末転倒に気づいたら、いい機会だから勉強しなおせばいいし、
お前らが愛して止まないGitのコードの問題を、お前らが率先して修正すればいいだけ。
それを誰もしようとしないのは、お前らもう既にコード書く気もなくなってるよね。
それで、何を大切に履歴管理するつもりなの？

いずれにしても、実際にコードを確認すれば済む話。
その能力もないのに「Gitのコードは素晴らしい」と信じこむんだから完全にキマッてる信者だよ。
繰り返すが、「素人以下」は煽りじゃない。
素人でいいから、お前らが信頼出来る、きちんとCを書いてる人に見てもらえば、すぐ確認取れるよ。
そのくらい酷い。
ただな、その程度すら確認出来ないのに偉そうにしてるお前らは、相当問題あると思うよ。

2023/06/25(日) 13:19:41.05

Gitを修正しないのは、Gitが素晴らしいからだけど？
お前はGitを修正しないの？
しないよね。素晴らしいと思ってるから。

2023/06/25(日) 13:26:17.55

反応するアホも全員まとめてNG

2023/06/25(日) 13:28:25.53

>>646
gitのコードが素晴らしいなんて誰も言ってないんが頭大丈夫か？日本語通じてる？

2023/06/25(日) 13:29:55.68

嬉ション垂れ流しながらレス乞食するだけだから相手しちゃダメ

2023/06/25(日) 13:40:19.99

「どのソース」の「どの部分」が「素人以下」で「ゴミ」なのか具体的に指摘も出来てないやつがいくら喚いてもね
まともに問題提起も出来ずに「問題だ問題だ」と騒いでるだけじゃん（文章だけは長いけど）
問題点が具体的でない状態で「率先して修正」もなにも無いわけ
お前が「素人以下のゴミ」と指摘できるくらいの「きちんとCを書いてる人」なんだろうからさっさとPR書くなりIssue出ｂｷなり好きに修瑞ｳしなよ

2023/06/25(日) 13:46:29.17

普通の人は自分のコードを書くのに忙しくてgit のコードを理由に使わないという選択はしない

2023/06/25(日) 14:02:41.64

>>652
(誰宛か分からんが)俺宛なら、614の通り同意する。
俺は俺が使いたい機能でバグに命中し、状況見る限り今後とも無理だと判断しただけ。
Git信者は「何であれGitに対してネガティブな発言は許さない！お前はこのスレに書き込むな！」という、言論封鎖共産体制支持者だから、発狂してるだけ。

2023/06/25(日) 15:06:59.31

あんたがバグに遭遇したというなら他の人も参考になるからその内容を共有してくれるのは歓迎するが？

2023/06/25(日) 15:09:57.30

批判するならそれだけの根拠と対策具体的に分かりやすく言えって言ってるだけなのに、「僕ちんの発言封殺されてる！ふんぎゃあー！」とか、ほんとにガキみたいな奴だな

2023/06/25(日) 15:32:13.94

プロトタイプひとつ完成させられないやつが、git のコードの品質語ってる時点で爆笑ものｗｗｗｗｗｗｗ
ねえ、ねえ、はずかしくないの？
それとも完成したからもどってきたの？
何で君のつくったツール誰もつかってないの？

2023/06/25(日) 21:03:54.64

>>654
都合のいい情報しか見えないお前ら信者には情報共有能力なんて無い
この状況がその証拠

2023/06/25(日) 22:18:15.12

・俺はgitのバグのせいで使うのやめた
・でもお前らは都合のいい情報しか聞く気がないから詳細は教えてやらん

こういうことか

2023/06/25(日) 22:41:33.10

>>658
バケツだかゴミ箱の話は都合が悪いので見えなかったことにするという意味じゃないかな？

2023/06/25(日) 23:01:47.85

>>658
ちゃうで。
既に公式に公開/共有はされてて、知らないなら、君が目に入れてないだけ。
俺に絶賛粘着中の連中も実は全部詳細を知ってるし、
俺の代わりに>>654に回答することも出来るはずだが、(一応待ってみた)
実は貢献度が俺以下のゴミだとバレるのが都合が悪いのか、無いことにしてるだけ。

多分君はこのしょうもないやりとりに参戦しない方がいい。君にとっては意味がない。
まあこのスレのGit信者の民度なんてこんなもんですよ、都合が悪い情報は隠蔽ってね。

2023/06/25(日) 23:07:30.47

Gitのコード品質が気に入らないならフォークして互換性を保ったまま改修したら多くの人に喜ばれるんじゃないかな
単なるコード整理のプルリクは取り込まれにくいだろうし

2023/06/25(日) 23:13:41.79

>>660読んでも>>658のどこが違うのかさっぱりわからんが。

バグチケットなんかしょっちゅう出てると思うがgitを使うことを断念するくらいのバグってなんなのか
単純に興味があるし、それを頑なに隠す理由というのもよくわからん。
git信者じゃないんだったらバーンと書いちゃえよ。

2023/06/25(日) 23:19:31.50

すでに公式に共有されてるならURL貼ればいいのにね
俺らにとって都合が悪いと思ってるなら尚更
虚言癖もここまでくるとほんとヤバいな

2023/06/25(日) 23:55:41.44

>>662
Git信者の隠蔽体質を証明する為にも、俺は貼らないことにする。
URLを知ってる奴が多数ここにいるのは明白なので、情報共有する気があればそいつらが貼ればいいだけ。
そうならないのなら、このスレはその程度って証明になるだけ。

> gitを使うことを断念するくらいのバグってなんなのか
使いたい機能がバグってたから使えないってだけの話だよ。

2023/06/26(月) 00:22:40.56

長文くん長文やめちゃったの？
流石に自分のウソ突き通すの辛くなったか…この嘘つきめ

2023/06/26(月) 01:20:45.72

最後にレスした方が勝ちゲーム
いつ終わんだ？

2023/06/26(月) 07:30:29.11

>>594
大分遅くなったけど、ありがとう

2023/06/26(月) 07:33:52.34

>>666
レスバは始めた時点で敗北者だからなあ……

2023/06/26(月) 20:47:11.43

>>612
言語に上級者もなにもないだろ
どんな言語でもISOの規定を見れば全部書いてあるし

2023/06/26(月) 23:27:49.31

日常の進捗履歴記録ツールWitBucket(仮称)検討中
https://mevius.5ch.net/test/read.cgi/tech/1668901194/

で，これどうなったの?
長文くんがこれに一切反応しなかったら逃げたって認定するね

2023/06/27(火) 05:44:42.45

>>652
> 普通の人
ちな、その「普通」はこのスレの『三流』の連中には当てはまらない
「○○すごい＝○○使ってる僕すごい」になるのは、自分では何も作ろうとしてない証拠だから
『本来なら普通は』自分の事に忙しく、ツールや他人の状況なんて(バグに命中しない限り)どうでもいいものだ

2023/06/27(火) 11:02:55.19

進捗履歴なんかGitHubでProject作ったあとにRoadmap表示して、進捗はmilestoneを追加し、関連付けた
issueにはやったこと書いて、milestoneの進捗を更新すればいいだけじゃね？webで完結できる。
　PWA対応になってるからアプリにしたいならChrome、Edge、safariのどれか使って勝手にすればいい。

2023/06/27(火) 12:22:09.28

>>671
長文君や
それ思いっきりブーメランで自分に刺さってないか「自分では何も作らない」
それとも作るって言ってたやつできたの？

2023/06/27(火) 12:52:46.00

長文くんはなんで隔離スレから出てきたの？

2023/06/27(火) 23:09:39.32

>>673
仮にそうだとしても、このスレの連中が何も作ろうともしていない事実は変わらない
他人のアラ探しに勤しんで自分のことは常に棚に上げてきたヒトモドキばかりなのも知ってるけど
管理する物もないのに、Git触って満足しててどうするよ？

2023/06/28(水) 00:06:07.05

あぼーんばかりだねこのスレ

2023/06/28(水) 00:21:55.51

>>675
gitスレでgit関連の話をしている人たちに
git使って管理しているソフト等の話をgitスレでしないのなら
何も作ろうとしていないということだ、とケチをつける長文君

2023/06/28(水) 03:07:01.90

>>675
linux kernel のコード書いてるけど？

2023/06/28(水) 07:04:44.26

>>677
前から思ってるが、どうにもお前ら文盲だよな。

お前らは勘違いが酷すぎるんだよ。
本来、自分が書いてないコードが稚拙であろうが知ったことではなく、発狂すること自体がおかしい。
そうなってしまうのは、お前らには「自分のコード」が存在せず、「Gitのコード＝ぼくのコード」になってるからだ。

> 素人の欲しがるようなソースコード管理ツール (567)
以前からそうだったが、これも勘違い甚だしい。
素人であれ、それはその人が何時間もコードと格闘した成果物であり、保存したければ保存すればいい。
コードと格闘する気もない奴が揶揄してるようでは話にならんよ。
しかもGitのコードが素人以下なのを認識出来ない程度の腕前(＝素人以下)の癖にね。

これらはお前らがコードを書くのを止めてる事に起因してる。
多少でもコードを書き続けてれば、こんな勘違いはしてないだろうよ。

それで本末転倒を多少でも改める気になって、しかし何を書くべきか分からないのなら、
「Gitのコード＝ぼくのコード」の妄想を現実にしてしまえというわけ。
これがお前ら的に最大級「ぼくすごいじる」を流せる方法だろう。
Gitのコードは現時点で素人以下のゴミだから、同様に素人以下のお前らが糞コードを挿入しても大した問題にはならない。
まるでレビューが機能してないから、お前らの糞コードでも問題なく通るはず。
(心配せずともお前らが遠慮したところでインド人が糞コード挿入しまくるだろうし)

俺はお前らが何をやってるかなんて興味ないし、ここでする話でもない。
ただ、コードを書いてるニオイがしないのに勘違いしまくってるお前らに、ちょっと突っ込んでるだけ。
そして初心者には、手段の目的化の罠に嵌るなよ、と言いたい。

2023/06/28(水) 08:35:33.63

>>679
gitスレでgit関連の話をしている人たちに
コードを書いてるニオイがしないからコードを書いてないに違いない
と言いがかりをつける鼻詰まりの長文君

gitは仕様もコードも糞だ、俺ならもっと良い管理ソフトをつくれると
宣ってスレを立てたけど、まったくコードを書かないまま被害妄想を
起こして逃げ出した長文君に、あのソフトどうなったと尋ねると
発狂したことにされてしまうらしい

2023/06/28(水) 09:17:40.93

>>679
それよりも、今あるGitのホスティングサービスだけで君の妄想した機能はすでに実装してあるって
過去何度も手順やサービスの具体名で書いてあったのに、なぜそれを毎回無視するの？

2023/06/28(水) 10:48:39.33

>>679
親前朗読定期

2023/06/28(水) 11:28:33.08

長文くんはアプリケーション作ったことないのになんでそんなに偉そうなの？

2023/06/28(水) 12:04:01.80

妄想の中の愚かな「お前ら」に向けて書いてるからさ。
実在する個々の読み手に向けて書いてるわけじゃないから各位スルーするように。
戻ってきた動機がさっぱりわからないんだけど、ちらほら見られる彼への反応が餌になっている可能性がある。

2023/06/28(水) 13:38:22.05

初心者の質問があると湧いて出るので、ウォッチしていて自分の味方になってくれそうな人探してるんじゃないかな
迷惑なはなし

2023/06/28(水) 23:12:12.37

>>681
ホスティングサービスが欲しい訳じゃないから

2023/06/29(木) 00:58:18.38

>>686
機能が欲しいんだろ。
ホスティングサービスかどうかとかどうでもいいだろ。

2023/06/29(木) 07:46:32.40

いまいちブランチの使い方がわからないんだけど
masterへコミット出来る人は限定して運用すべきなの？

2023/06/29(木) 10:59:31.85

>>688
可能ならそうしたほうが無難だと思うけど
絶対というワケでもない
セクションや機能追加などでブランチきって
出来たら統合して
不要になったら削除というふうに使ってる

2023/06/30(金) 14:01:02.61

>>688
masterへのコミット制限はかけといた方がいい。特に社外の人とかコントリビューターに与えたらダメ。
　PRでメンテナーの承認(レビュー)を受けたものが個人のブランチから現在活性中のdevelopブランチに
マージされ、製品が完成したらメンテナー自身がmasterにマージするようにしておけばmasterに変な
コードが流入するリスクも避けられる。
　ただし製品出荷前/接合テスト前でバージョン管理前だよってなら、その限りではないが。

あと一般利用者にはリポジトリの設定変更させないようにもしといた方がいい。

2023/06/30(金) 17:37:04.62

いちいちコードレビューなんてやってられないわ
よほどひまな職場なんだろうな

2023/06/30(金) 18:07:43.82

コードレビューをしないから
忙しくなってるんだよ

2023/06/30(金) 19:42:24.21

>>688
ブランチは並行して複数並べられるというメリットを活かして、release,main,developといった位置付け別と、さらに細かく実装機能別にブランチを作るのがいい。実装機能別は１機能１ブランチでもいいくらい。

2023/07/01(土) 00:13:57.08

コードレビューやってられないのは50%ぐらいレビューされる側の問題
分かりにくければ「お前のコミット分かりにくすぎるのでもっと分割してくれますか？」と伝えるべき

**デフォルトの名無しさん** (JP 0He7-ePcp) · 2023/07/01(土) 01:27:44.90

>>692
なんで？
いちいち他人に見てもらわなきゃかけないのか

2023/07/01(土) 02:37:41.90

>>695
お前、一人でプログラミングしてるの？
人間って一人でできることには限界があるんだぜ。

2023/07/01(土) 07:57:57.36

>>690
仕事したこと無さそうな頭でっかちww
実際には担当がガシガシ変更して、そのままリリースされてることなんてザラ。

プログラマなら誰でも名前くらいは聞いたことがあるソフトに従事してるけど、うちの所だけでも20人いるけど一人も全体を把握してる人はいないよ

2023/07/01(土) 08:18:09.45

俺もプログラマな誰でも名前くらいは聞いたことが有るソフトを作ってるよ。なんの自慢にもならないけど。

2023/07/01(土) 08:32:39.81

おまえら個人名はいらんので、会社名出してくれない？
その会社とつきあうか参考になりそうなんで

2023/07/01(土) 11:22:09.50

>>698
匿名掲示板ならいくらでも話を盛れるという好例

2023/07/01(土) 11:49:41.48

信じたくないなら信じなくてもいいけど、俺はすごいんだ

2023/07/01(土) 13:15:50.29

長文くんのつぎは自称自分スゴイマンかよ

2023/07/01(土) 15:18:55.67

可哀想にね
妄想と現実のギャップで苦しんでるんだよ

2023/07/02(日) 22:54:33.75

>>697
そんなことしたら、最悪ビルドも通らないソースを運用が始まった製品のmasterに直接コミットされる
可能性もあるでしょ？
　俺ならブランチでビルドエラーが出るどころかjestやlintも通らないようなものは、エラーがなくなる
までdevにすらマージさせないて修正させるよ。

2023/07/02(日) 23:10:04.39

チームの状況に合わせて臨機応変に運用を決めればいい

2023/07/02(日) 23:29:14.65

>>705
それはヤバいで。
仲良しで優秀な集団ならいいけど、以下のようなのがいてブチ壊していくから。

〈組織や生産性に対する一般的な妨害〉
○組織と会議
・何事をするにも「決められた手順」を踏んでしなければならないと主張せよ
・「演説」せよ。できるだけ、頻繁に延々と話せ
・議事録や決議の細かい言い回しをめぐって議論せよ。あらゆる決断に懸念を示せ
○管理職
・指示を誤解せよ。長ったらしい返信を送れ
・士気を下げるために、不相応な作業員を昇進させよ
・できる作業員は冷遇し、仕事に不条理な文句をつけよ
・重要な仕事は必ず会議を開け
・もっともらしい方法で、ペーパーワークを増やせ
・手続きに必要な承認者は、ひとりで十分でも3人の認可を徹底せよ
○従業員
・のろのろと働け
・できる限り自分の仕事を中断せよ
・何回も繰り返し尋ね、不要な質問で主任を困らせよ
・質問をうけたら、長ったらしい、理解し難い説明をせよ
・とぼけよ
・面倒なことに巻き込まれないように、できる限り不機嫌にふるまえ

2023/07/02(日) 23:38:58.18

職場の実体としてそうであるってのはまあ仕方がない面もあると思うけど
それを正道であると思って語っちゃうのはちょっとやばい
水は低きに流れていくんだからせめて恥ずかしがらんと

2023/07/03(月) 01:40:46.25

チームの人間が信用できないんだね
常にギスギスしてそうで可哀想

2023/07/03(月) 06:29:04.98

>>706
何かと思えばこれか。
toyokeizai.net/articles/-/682357
内容も歪んでるなあと思いきや、著者が河合薫で納得だ。
権限が与えられてるのに執行しなかったのなら、それもただの責任逃れでしかない。

まあそれはさておき、お前らニート過ぎ、精神論過ぎ。
新入社員からベテランまで職場には居るのだから、技術レベルが揃ってることなんてあり得ない。
お前らが空想してる職場なんて存在しない。(少なくとも日本には。海外はどうなんだろう？)
rejectすれば自動的に改善されるわけでもない。

そもそも職場の場合、相手の技量を理解した上で仕事を振ってる。
量が問題なら、最初から量を減らしてるし、
質が問題なら、事細かく、場合によっては付きっきりで指導してる。
rejectするのが仕事じゃないんだから、
将来的にrejectしなくても済むようにあらかじめ手を打つんだよ。
新入社員が無能だからって、何もやらせないと上達もしないだろ。
新入社員なんて無能だという大前提で、それでも可能なように手回しして振っていくんだよ。

OSSの場合はこれが出来ないからreject頼りになるのはある程度致し方ないが、それが理想でもない。
それは育成過程無視のただ乗りでしかないし、実際お前らの理想を実行してるGitは完全に糞コードだし。
あれマジでCの職場だとグーで殴られるレベルだぞ。
rejectだけに頼ってると、rejectされるかされないかだけが基準になってしまうのも問題なんだと思うぜ。
職場だと、「今回はもうこれでいいが、次からはここはこうしてくれ」とか言うからね。
(というより、そういう妥協が出来る部分を技術レベルが低い奴に振る)

2023/07/03(月) 07:10:29.97

> あれマジでCの職場だとグーで殴られるレベルだぞ。

じゃあなんでお前のほうが殴られたの？

2023/07/03(月) 08:31:58.63

伽藍とバザールの話蒸し返してるし
伽藍は伽藍でハードル高くして衰退していけば良いのよ

2023/07/03(月) 10:34:59.49

長文くんお帰り