Github使えないエンジニアwwww

■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
垢版 |
2020/10/08(木) 22:43:54.13
わたしです(´・ω・｀)
2020/11/07(土) 15:40:44.09
>>225
普段使っている中でそんな大量のオプション使う必要あるか？
2020/11/07(土) 16:03:45.66
オプションなんて必要になった時点で調べればよい
どんなオプションがあるかだけなんとなく頭に入れておけばいい
2020/11/07(土) 17:05:45.45
今時の開発環境はgit対応してるだろ
日常で使う数少ないコマンドさえ覚えられないならGUIで操作するところから入ればいいのに
2020/11/07(土) 17:20:16.63
コマンドだるいならsourcetree使いなさい
2020/11/07(土) 17:35:50.87
歳のせいにするな、自分が無能なだけだろ
俺は40代だが普通にgitもGitHubも使ってる
GitHubの俺のリポジトリで一番スターが多いのは200オーバーな
2020/11/07(土) 19:10:56.21
評価してやるからURL貼ってみろ
2020/11/08(日) 11:05:35.42
>>227
gitでヒィヒィ言ってるのに言語が理解できるとは思えない
2020/11/08(日) 12:42:38.96
言語は必須
Gitは便利ツール
236仕様書無しさん
垢版 |
2020/11/09(月) 14:12:22.32
GitHub社みたいなショボい会社に会社の生命線を預けるのが意味不明
自社でGitHubっぽいサービス作れば良くね？
2020/11/09(月) 14:14:11.37
GitHubはMicrosoftに買収されますた
2020/11/09(月) 14:28:19.07
>>236
マイクロソフトがしょぼいってw
2020/11/09(月) 17:01:56.39
CIで時間がかかっていってGitHub Actionsに乗り換えてるんだけど
今更だがGitHub Actionsすごすぎね？

オープンソースなら無料なのに並列数20で制限なしとか
やっぱクラウド自社で運営してるMicrosoftは違うな
買収されてからかなり良くなってる
2020/11/09(月) 18:00:57.65
Azure DevOpsのパイプラインがよくできてたからノウハウがGitHubに生かされてるね
2020/11/09(月) 20:25:43.01
他のCIサービスだと、無料で大量のテストをやるのは気が引けるんだが
金持ちマイクロソフトなら遠慮しないですむ
2020/11/13(金) 23:03:57.08
どうせgithub使うんだから結局commit早くたってclone/push/pull/fetchでネットワークアクセスして遅いだろ。
まあgithubと言う名前だけどsvn-serverとしてそのまま動くからなぁ。結局、みんな分散分散言っといて中央リポジトリがシンプルで大好きなんだよな（笑）
2020/11/14(土) 08:00:00.83
分散も中央も両方できるからgitを使うんですよ。
gitは中央を捨てたわけじゃありません。両対応なんです。
それだけでもsvnより優れてるってわかるでしょう？
2020/11/14(土) 08:48:43.93
svnよりgitの方が多機能なのは誰でも知ってるし否定もしないしgithubは便利。ただgithubしか知らないのは微妙
2020/11/14(土) 11:03:52.47
svnで十分派の皆さんはとりあえずこの辺に目を通して、svnとgitの考え方の違いを知ってから文句言っていただきたい

https://qiita.com/kaityo256/items/81e7951a1ca2706955a4
2020/11/14(土) 11:57:54.54
自分のコミットでプロジェクトが滅茶苦茶になるかも
それを集中攻撃で責められるかもと思うと
恐くてコミットできません
2020/11/14(土) 11:59:40.90
gitを使えばプログラムの競合が起こらないと信じ込んでいた
新人でもない中堅ＰＧがいっぱいいた
2020/11/14(土) 12:58:07.48
>>247
そうか。だがそれはgitの問題ではないし、gitが優れていることに違いはないよな
2020/11/14(土) 15:31:57.22
gitのせいじゃないとか優れてるとか劣ってるとか
そういうのはいい

問題があるのを認識してないのが問題なんじゃ
250仕様書無しさん
垢版 |
2020/11/14(土) 18:03:44.43
そんな会社辞めて転職しろ
2020/11/14(土) 18:06:38.63
>>249
人の問題か、技術（git, github）の問題をかをはっきりさせてるだけ
2020/11/14(土) 18:24:34.54
すぐ人の問題に帰着しようとする脳が腐った論法は富士通のにおいがする
2020/11/14(土) 18:36:27.00
>>252
何があったか知らないけれど
社会のせい会社のせいにするのがキミだ
2020/11/14(土) 20:36:40.04
人の問題は人の問題で、そういう問題があるっていうのは事実でいいんだよ
うちの社員は馬鹿ばっかりだから、うちの会社では導入できません。というのも
導入できない立派な理由

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

問題をすり替えると、問題の解決策が変わってしまう。
うちの社員が馬鹿という問題だって理解していれば、
その馬鹿に勉強させるか、クビにして入れ替えるっていうのが解決策となる
問題をすり替えてしまうと、本当に解決しなければいけない問題が見えなくなってしまう
2020/11/14(土) 21:45:31.43
>>252
君は楽観的すぎる
Fだけじゃないんだよ
2020/11/14(土) 21:56:06.65
>>245
内容が微妙だった。mergeとか絶対にどっちでも変わらないし。
2020/11/14(土) 22:03:52.34
svn脳といえば、
・ブランチを作成するのに躊躇する
・マージしてからテストする
・古いコードでの上書きが頻繁に発生する
2020/11/14(土) 22:46:43.00
>>245
今ですらsvnとgitを併用してるやつの記事なんて信用できるのか？
2020/11/14(土) 22:47:13.37
git脳がsvnｗを使った場合というケースが抜けてる
2020/11/14(土) 23:26:32.62
>>258
今の話なの？
261仕様書無しさん
垢版 |
2020/11/15(日) 00:20:49.00
SVN脳だとresetやrebaseがまず理解できない
2020/11/15(日) 05:51:22.35
svn+ローカルリポジトリ=git
と考えればsvn使いにもイメージしやすいと思うがなぁ
2020/11/15(日) 06:25:32.04
リポジトリが複数あるって気持ち悪くてダメだわ
やはり中央に一つであるべき
2020/11/15(日) 10:29:39.81
ソース管理の粒度ってどれぐらいでやってる？
・少しでも更新したら（ビルドができなくても）コミット
・ビルドエラーは関係なく、自分の中で区切りのよいところでコミット
・ビルドエラーが出ないところでコミット
・最小限の修正が終わるごとにコミット
・ある程度の修正群の１つのまとまりごとにコミット
・修正プロジェクトが完了するごとにコミット
・製品リリースごとにコミット

コミット（push）するタイミングってどうしてる？
2020/11/15(日) 11:46:41.95
粒度
2020/11/15(日) 12:00:46.81
>>263
分散管理ツールでも普通は中央レポを運用で指定してるもんだろ。大した問題じゃない。
てかいちいち中央と同期とるシステムのがめんどくセーわ
2020/11/15(日) 12:02:46.45
>>254
それは使えない方が馬鹿なんじゃなくて、教える方が馬鹿なだけ。
gitのコマンド全て教える必要なんてないし最低限必要なことはgitでなくても結局必要になる。
2020/11/15(日) 12:16:59.99
>>264
お前コミットメッセージ適当だろｗ

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

意味がある単位に分けろ。
分離できるならなるべく分離しろ。
そして1コミット単位でリリース可能なようにしろ
2020/11/15(日) 12:19:58.66
だいたいコミットとpushのタイミングは別だ
pushとマージのタイミングも別だ

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

そして作業ブランチが完成してテストもOKになったらマージするだろ
そうすりゃmasterブランチにそれら複数のコミットが取り込まれる
2020/11/15(日) 12:53:21.68
サーバのソースをリアルタイム修正してる（CTRL+Sで保存される先が本番サーバ）なんだけど
おまえらは違うの？
2020/11/15(日) 13:01:37.66
別ブランチが長く運用されてマスターと統合不可になってるのが嫌
2020/11/15(日) 13:23:02.89
管理ソフトが余計な管理増やしてる
2020/11/15(日) 20:34:16.02
>>264
ちなみに管理する側からすると毎日コミットしてって言ってる(gitならpush)。下手な進捗報告されるより一番手っ取り早くて確実。
274仕様書無しさん
垢版 |
2020/11/15(日) 21:13:56.18
>>270
そんなことして壊したらどうするんだ！
2020/11/15(日) 22:48:54.89
>>274
その緊張感がいいんじゃないか
自然とテストも増えるよ
修正して即テストが習慣になるし、ユーザーがいつどんな操作するかを考えながらコーディングするようになった
いいことばかり
2020/11/16(月) 03:20:35.20
> 修正して即テストが習慣になるし、

テスト実行するだけじゃダメだろｗ
バグってたら直せよ、時間をかけて
2020/11/16(月) 12:43:15.52
>>271
定期的にmasterからマージすりゃいいんじゃね？
2020/11/16(月) 13:51:29.67
>>271
svnだとrebaseができない（面倒くさすぎて事実上不可能）から
ブランチとマスターが剥離していっちゃうんだよね
2020/11/16(月) 14:45:25.62
乖離って言おうぜ
2020/11/16(月) 14:51:35.86
Ｇｉｔはローカルがすぐこわれて使いづらい
2020/11/16(月) 15:03:30.82
>>280
俺は壊れた事ないなぁ
何したら壊れたの？
2020/11/16(月) 15:35:01.64
ほかのブランチ見たらこわれた
チェックアウトしたらこわれた
ファイルセーブしたらこわれた
こわれまくり
2020/11/16(月) 15:36:35.50
自分で改行コード勝手に変換しといて管理外でファイルが変わってるから扱えないとかエラー吐きやがる
人間なら首絞めて殺してるところだ
2020/11/16(月) 16:02:07.51
何もしてないのに壊れた
2020/11/16(月) 16:06:02.03
svnは何をしてもなかなか壊れなかった

イケてるエンジニアを装いたい人間の不誠実な態度が
Ｇｉｔの進歩を遅らせてきたにちがいない
2020/11/16(月) 16:43:44.61
壊れないかどうかじゃなくて、
開発しやすいかどうかだ。重要な点は。

svnは開発が苦痛で仕方なかった。
ソースコードを書く時に間違えないことが前提になってる
「これでいいかなー、エンター・・・あー、あれ忘れてたー！」
という苦痛がsvnには常につきまとってた
2020/11/16(月) 17:28:59.60
svnはまるでCTRL+Sのように頼れるやつだった
gitはフォルダ丸ごとコピーと同じノリ
2020/11/16(月) 17:57:16.39
gitはフォルダ丸ごとコピーと同じノリとは
どういうことをしてるの？
2020/11/16(月) 18:12:58.10
仕組みを理解する頭がなく、
ふんわり感覚で理解したつもりになってます、
という告白だろ
2020/11/16(月) 20:11:57.07
>>236
マイクロソフトがしょぼい会社？？？
2020/11/16(月) 20:54:04.30
>>278
コンフリクトして無い限りsvnでも1コマンドだと思うんだけどな。rebaseの方が楽な気はするけど
2020/11/16(月) 21:00:28.63
>>280
分かる。操作ミスなんだろうけど、調べるのも面倒だしローカルgitが絶対に健全なのかどうかを(チームメンバと同一状態かいなかを)確認する手段が無いから結局cloneしちゃう。
2020/11/16(月) 21:02:14.97
コーンフレークやないか
294仕様書無しさん
垢版 |
2020/11/16(月) 21:39:45.00
>>292
git checkout master
git reset --hard origin/master
すれば楽になれるのに
2020/11/16(月) 21:46:14.76
>>291
> コンフリクトして無い限りsvnでも1コマンドだと思うんだけどな。rebaseの方が楽な気はするけど

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

細かくメンテナンスしてればコンフリクトは発生しないけど
svnじゃそれは事実上無理
2020/11/16(月) 23:32:58.37
>>295
trunkへのコミットを自分のブランチにマージするだけじゃない？ソフトが自動で差分見てマージしてくれてコンフリクト起こった所だけ専用のdiffソフトが出てマージの仕方を選ぶだけ。気持ち悪くなったらtrunkから再度ブランチ切って自分のコミットを古いブランチから選択してマージしても良いし、複数コミットまとめても良いし。gitだとコンフリクトしてももっと楽？
2020/11/16(月) 23:36:36.51
>>294
経験的にそんなぐらいじゃ治らんな。自分の操作が相当適当って事かも知れないけど。
2020/11/17(火) 00:08:17.74
>>296
どっちからどっちにマージしようが
自分の変更と相手（master）の変更で同じ箇所をいじってればコンフリクトになるんだよ
コンフリクトの数が少なければ修正は楽
だからこまめに修正しないといけないが、それはこまめにtrunkをマージしてればいいってわけじゃない
そんな変更が多数入ったブランチなんてレビューできねーだろ

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

最新のコードからの修正という形にしないとレビューが困難になる
2020/11/17(火) 00:11:06.47
>>206
> 気持ち悪くなったらtrunkから再度ブランチ切って自分のコミットを古いブランチから選択してマージしても良いし、
それがrebase。簡単なやつなら1コマンドですぐ終わる。

> 複数コミットまとめても良いし。
それもrebase。作業中にコミットをまとめておくことで
「trunkから再度ブランチ切って自分のコミットを・・・」の自分のコミットを
少なくできるから楽になる
2020/11/17(火) 00:48:41.72
>>297
それってcloneするのとほぼ同義だぞ
やったことないでしょ？
2020/11/17(火) 03:58:05.93
それコーンフロストやないか
302仕様書無しさん
垢版 |
2020/11/17(火) 07:59:52.76
>>297
git fetchした？
2020/11/17(火) 08:03:19.59
みんな当たり前のようにコンソールコマンドベースで話してるが
ＧＵＩ使ってないのか
2020/11/17(火) 08:41:25.94
GUIの利点は一覧性が高いことだから、過去のcommitの確認の時とかには使ってる
2020/11/17(火) 10:03:53.19
普段はvscodeやtortiseGit
特にIDE連携は便利でいいね
2020/11/17(火) 14:44:15.25
>>303
GUI使ってるけどみんな使ってるGUIアプリが違うからコマンドで説明した方が多くの人に通じるだろ
コマンドが共通言語みたいなもんよ
2020/11/17(火) 20:12:49.04
>>299
納得した。それは間違いなく一手間減る。svnだとGUI側で過去コミットログ引っ張って来て連続自動コミットするしか方法が無い。
2020/11/17(火) 20:16:06.47
svnでもgitでも操作方法はたくさん資料があるんだけど
運用方法はないんだよね
309仕様書無しさん
垢版 |
2020/11/17(火) 20:25:29.78
git-flow
2020/11/17(火) 20:28:13.52
ムチムチ
2020/11/17(火) 20:42:12.46
https://medium.com/@patrickporto/4-branching-workflows-for-git-30d0aaee7bf

お好きなものをどうぞ
2020/11/17(火) 21:00:11.68
>>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必要なのか。
2020/11/17(火) 22:19:57.83
svnを使ってた頃は、svnの使い方が全くわからなかった
間違ったとき修正が大変でこんなんでどうコミットしていけば良いんだよと思ってた
開発がすごくやりづらかった

svnの使い方がわかってないだけかと思っていたが
gitになってからやりたいことができるようになったので
svnというツールが悪かったんだなぁと気づいた
2020/11/17(火) 22:28:57.74
巻き戻しの大変さに違いがあるもんか
315仕様書無しさん
垢版 |
2020/11/19(木) 06:46:40.76
やっぱり、こういうのは、ちゃんと管理者にやらせなきゃダメだな。
専任の管理者を決めて、コミットだのプッシュだのマージだのは
すべてそいつにやらせるべし。
技術者には一切触らせちゃいけない。

そういう管理こそ、新人にでもやらせればいいんだ。
316仕様書無しさん
垢版 |
2020/11/19(木) 07:29:18.47
マージ担当（笑）がいる会社って都市伝説じゃないの？
2020/11/19(木) 08:33:06.54
コミットを専任の担当者が？
マジで？
2020/11/19(木) 10:16:16.83
コメット担当者ってwww
2020/11/19(木) 10:29:43.14
俺はコメント担当者だった
2020/11/19(木) 10:31:57.09
コメットさん
2020/11/19(木) 11:04:34.45
60代がわいてでたぞー
2020/11/19(木) 11:04:40.58
こんにちはGitHub普及担当の皆さん
2020/11/19(木) 11:06:56.58
パワーをメテオに！！
2020/11/19(木) 11:10:50.51
キングベヒーモスさん
2020/11/19(木) 12:27:57.37
>>316
あるよ
インテグレーションチームて呼んでた
マージして動作確認するチーム
2020/11/19(木) 13:15:00.86
>>316
ソース管理担当者はいたよ
マージだけじゃなくてコミット含めて全部その人を通さないと出来ない

あと何でも仕様を知ってる仕様担当者、コーディングで困った人助ける担当者、新しい派遣の席を作る椅子担当者もいた
派遣をエレベーターの下から上に案内するだけの奴もいたけどあれはただの多重派遣か
2020/11/19(木) 13:47:13.39
マージする担当者を置くのは意味分かるけどコミットの担当者は理解不能だな
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況