探検
Github使えないエンジニアwwww
■ このスレッドは過去ログ倉庫に格納されています
1仕様書無しさん
2020/10/08(木) 22:43:54.13 わたしです(´・ω・`)
359仕様書無しさん
2020/11/22(日) 00:18:41.22 コンフリクト起こさないように無理くりやるって完全にアンチパターンだし、
バージョン管理ツール使う意味ねーわ。
バージョン管理ツール使う意味ねーわ。
360仕様書無しさん
2020/11/22(日) 00:30:02.65 コーンフレークやな
361仕様書無しさん
2020/11/22(日) 00:56:10.40 >>358
しつこいも何も答えてないからね
つまりお前はソースコードを見ないで担当者決めるんだろ?
どこを修正するのかわからないのに、どうやって担当者決めるんだ?
まさか1つのファイルだけで修正が終わるとでも思ってるのか?
複数の人が同じファイルを修正するときどうするんだよ?
それを早く言ってくれよ
しつこいも何も答えてないからね
つまりお前はソースコードを見ないで担当者決めるんだろ?
どこを修正するのかわからないのに、どうやって担当者決めるんだ?
まさか1つのファイルだけで修正が終わるとでも思ってるのか?
複数の人が同じファイルを修正するときどうするんだよ?
それを早く言ってくれよ
362仕様書無しさん
2020/11/22(日) 01:53:16.16 早く済ませたいならコーンフレークちゃうか
363仕様書無しさん
2020/11/22(日) 05:07:27.00 チョコクリスピーやろ
364仕様書無しさん
2020/11/22(日) 06:47:03.08 オールブランやな
365仕様書無しさん
2020/11/22(日) 09:17:20.44 担当者なんてredmineみて各自勝手にチケットとっていくだけだろ?
修正なんて大抵は1ファイル数行だ
機能追加ならもうちょい規模が大きいがそれは凍結するだろう
複数の人が無秩序に同じファイルを修正するケースが思いつかない
VB.NETみたいに1ファイルに1万行あるようなケースならともかく
普通の言語なら数十行だろう
どれだけ大規模なら衝突しちゃうんだい?
修正なんて大抵は1ファイル数行だ
機能追加ならもうちょい規模が大きいがそれは凍結するだろう
複数の人が無秩序に同じファイルを修正するケースが思いつかない
VB.NETみたいに1ファイルに1万行あるようなケースならともかく
普通の言語なら数十行だろう
どれだけ大規模なら衝突しちゃうんだい?
366仕様書無しさん
2020/11/22(日) 09:38:45.34 なんも関係してない複数プロジェクトのソースマージは結構神経を使うからなあ、どうだろう・・・。
367仕様書無しさん
2020/11/22(日) 09:49:00.30 同じ場所を複数人で修正するパターンって
要するに共通で使うようなフレームワークに相当する部分が未完成ってことでしょ?
要するに共通で使うようなフレームワークに相当する部分が未完成ってことでしょ?
368仕様書無しさん
2020/11/22(日) 10:05:26.06 1ファイル1万行の糞コードならどんなVCSを使っても無駄だ
369仕様書無しさん
2020/11/22(日) 10:06:35.23 低能がうじゃうじゃいるスレだな
370仕様書無しさん
2020/11/22(日) 10:26:04.90 >>365
> どれだけ大規模なら衝突しちゃうんだい?
大規模かどうかは関係ない。同じような箇所を修正すれば衝突する
お前、チケット見た段階でソースコードの同じ箇所を修正しないって
どうやってわかるんだ?ありえない話をお前はしてるよな
> どれだけ大規模なら衝突しちゃうんだい?
大規模かどうかは関係ない。同じような箇所を修正すれば衝突する
お前、チケット見た段階でソースコードの同じ箇所を修正しないって
どうやってわかるんだ?ありえない話をお前はしてるよな
371仕様書無しさん
2020/11/22(日) 10:30:29.24 >>367
ソースコードが単一責任の原則を守れてないとか色々ある
最初から完璧に設計されていて、小さくモジュール化されていて
変更が入るたびに、その内容に応じて設計もちゃんと再構成していれば
コンフリクトが起きる可能性は低くなる
つまりこれはソースコード完璧ならコンフリクトは発生しないと言ってるのと
同じことなので、完璧なソースコードなんて現実にはありえないってことで論破できる
ソースコードが単一責任の原則を守れてないとか色々ある
最初から完璧に設計されていて、小さくモジュール化されていて
変更が入るたびに、その内容に応じて設計もちゃんと再構成していれば
コンフリクトが起きる可能性は低くなる
つまりこれはソースコード完璧ならコンフリクトは発生しないと言ってるのと
同じことなので、完璧なソースコードなんて現実にはありえないってことで論破できる
373仕様書無しさん
2020/11/22(日) 12:06:21.32 チーム開発してると手の遅いやつが文句言い出すけど
定期的に手元のソースを最新にしてからそういうことを言ってほしい
定期的に手元のソースを最新にしてからそういうことを言ってほしい
374仕様書無しさん
2020/11/22(日) 13:55:56.33 おまえたちって本当に末端のゴミPGなんだな・・・呆れたよ・・・
四半期の会計期間ごとに大規模システムの改修計画の予算がおりて
別々のチームが同じソースの改修を同時進行で進めるケースとかに参画したことがないんだな
道端の犬のクソにたかるウジ虫を見ている気分になる
四半期の会計期間ごとに大規模システムの改修計画の予算がおりて
別々のチームが同じソースの改修を同時進行で進めるケースとかに参画したことがないんだな
道端の犬のクソにたかるウジ虫を見ている気分になる
375仕様書無しさん
2020/11/22(日) 14:42:59.77 あいつSESかよ
技術者じゃないじゃん
技術者じゃないじゃん
376仕様書無しさん
2020/11/22(日) 14:52:58.06 采配がヘタなだけじゃん。
そんなのをSVNやギットのせいにすんなや。
そんなのをSVNやギットのせいにすんなや。
377仕様書無しさん
2020/11/22(日) 14:55:16.50 何かを修正する時に、ソースコード単位で采配なんてできないって話だぞ
378仕様書無しさん
2020/11/22(日) 15:13:13.73 数千人規模だと逆にソース管理失敗って聞いたことないよね
380仕様書無しさん
2020/11/22(日) 15:58:19.83 上から采配が落ちてこないんなら、それは上がサボってるだけのことで、
まあ下手以前に論外だな。
まあ下手以前に論外だな。
381仕様書無しさん
2020/11/22(日) 16:32:19.38 これバージョン管理ツールであって平行開発の為のツールじゃないよね
382仕様書無しさん
2020/11/22(日) 16:35:23.76 並行開発しないチーム開発なんてありえんだろ。なんでこんなに愚かなの?
383仕様書無しさん
2020/11/22(日) 17:06:31.86 ファイルごとに担当者決めるなんて非現実的だってまだ理解できないのかよ
384仕様書無しさん
2020/11/22(日) 18:36:39.97 並行開発しないチーム開発なんてありえないのに適したツールがない
385仕様書無しさん
2020/11/22(日) 19:08:31.80 分散の場合は同期とるのが余計に面倒に思えるんだがどうやってるん?
git入門とかでググっても老人PGが疑問に思う一番重要なところが説明されてない。
git屋はエスパーPGばかりで以心伝心なん?
それともlinusみたいにおまえのコードはマージしてやんねぇとかケンカばかりしてるん?
git入門とかでググっても老人PGが疑問に思う一番重要なところが説明されてない。
git屋はエスパーPGばかりで以心伝心なん?
それともlinusみたいにおまえのコードはマージしてやんねぇとかケンカばかりしてるん?
386仕様書無しさん
2020/11/22(日) 19:31:04.09 >>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時にコンフリクト解消する回数が少なくなる
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時にコンフリクト解消する回数が少なくなる
387仕様書無しさん
2020/11/22(日) 21:12:06.81 ブランチ開発してるときに元の関数のインターフェース変わったりしたら
なんぼリベースしようがマージしようが解消できんと思うのだが
なんぼリベースしようがマージしようが解消できんと思うのだが
388仕様書無しさん
2020/11/22(日) 21:36:50.88 やっぱコーンフレークやないか
389仕様書無しさん
2020/11/22(日) 21:45:36.11 >385
そう。
クソコード入れるより喧嘩する方が正しい。
そう。
クソコード入れるより喧嘩する方が正しい。
390仕様書無しさん
2020/11/22(日) 22:10:47.99 > gitは小さな変更だけを含むfeatureブランチのチームでレビューしてからマージを繰り返すスタイルがよく使われる
これが知りたかったんだよね。
git、git言うからどれだけ効率がいい開発手法なのかと思ったら全くの逆で、非効率で泥臭い方法だったか。
内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで、
分散管理のせいでマージ、レビューするまで分からないとかデメリットがでかすぎる。
OSSの開発が遅くバグが放置される理由、forkしまくる理由はすべてgitのせいだな。
これが知りたかったんだよね。
git、git言うからどれだけ効率がいい開発手法なのかと思ったら全くの逆で、非効率で泥臭い方法だったか。
内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで、
分散管理のせいでマージ、レビューするまで分からないとかデメリットがでかすぎる。
OSSの開発が遅くバグが放置される理由、forkしまくる理由はすべてgitのせいだな。
391仕様書無しさん
2020/11/22(日) 22:25:29.68 gitは糞ってこき下ろすだけの
代案無しの野党みたいな奴しか居ねえな
代案無しの野党みたいな奴しか居ねえな
392仕様書無しさん
2020/11/22(日) 22:48:29.29 gitのブランチのマージは怖い
393仕様書無しさん
2020/11/22(日) 22:53:39.66 >>390
>内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで
それがすぐできるならまあどんなバージョン管理しても問題ないだろ。
多分お前はできてないだろうが。
まあ確かにfeatureを細かく切るってのは運用保守の段階なら良いが大幅な改変が必要な時には
無駄が多い。
>内部設計上の矛盾、実装上の相違なんてのはすぐさま対応、修正すべきで
それがすぐできるならまあどんなバージョン管理しても問題ないだろ。
多分お前はできてないだろうが。
まあ確かにfeatureを細かく切るってのは運用保守の段階なら良いが大幅な改変が必要な時には
無駄が多い。
394仕様書無しさん
2020/11/22(日) 23:01:15.70 >>391
いいえ、単にgit知らなくてググってもちゃんとした説明ないから質問しただけですよ。
古い集中管理型ならコーンフレークの遅延はなく、単体テストしてコミットしたのにちゃぶ台返しされるリスクも少ないでしょう?
だから分散管理で問題になるこの同期の遅延リスクをgitではどうやってるのという疑問でしたが、
泥臭くケンカしながら解決するということで疑問は解決しました。
というか代案も何も答えは明白ですよ。シンプルな設計、トップダウンでツリー状に機能が綺麗に分かれるような仕様要件なら分散管理は効率よく機能し、複雑な仕様設計ならgitかっけー的な運用したらプロジェクトはデスマーチ必至。そういうときはgitでも集中管理的な運用をする必要があるということですな。おそらくgitスレがIP表示なのはgitの運用方法でケンカした結果でしょう。
いいえ、単にgit知らなくてググってもちゃんとした説明ないから質問しただけですよ。
古い集中管理型ならコーンフレークの遅延はなく、単体テストしてコミットしたのにちゃぶ台返しされるリスクも少ないでしょう?
だから分散管理で問題になるこの同期の遅延リスクをgitではどうやってるのという疑問でしたが、
泥臭くケンカしながら解決するということで疑問は解決しました。
というか代案も何も答えは明白ですよ。シンプルな設計、トップダウンでツリー状に機能が綺麗に分かれるような仕様要件なら分散管理は効率よく機能し、複雑な仕様設計ならgitかっけー的な運用したらプロジェクトはデスマーチ必至。そういうときはgitでも集中管理的な運用をする必要があるということですな。おそらくgitスレがIP表示なのはgitの運用方法でケンカした結果でしょう。
395仕様書無しさん
2020/11/22(日) 23:52:34.36 SVNは一つのブランチで闇鍋して
コミットしようとして初めてコンフリクトになるか
ロックという偽りの安心感を与える道具に頼るかだ
GitFlowもどきをSVNでやる事は普通ない
コミットしようとして初めてコンフリクトになるか
ロックという偽りの安心感を与える道具に頼るかだ
GitFlowもどきをSVNでやる事は普通ない
396仕様書無しさん
2020/11/23(月) 01:42:29.61 ボクが考えるgitの運用方法が一番正しいんだみたいな
ある程度複雑性や規模をもった要件に対しては分散管理は非効率でしかなく、
結局Linuxの例を出すまでもなく、OSS陣営の多くの開発がMSより10年遅れてると言われるのも頷ける。
今ではMSもgitに手を出すからブラウザ開発に失敗したり、Windows10はAppleのように互換性切り捨てだらけになってしまった。
縛りのない開放感なんて所詮、責任の放棄でしかないんだよ。
馬鹿な大臣がハンコを無くそうとしてるのと同じ。
ある程度複雑性や規模をもった要件に対しては分散管理は非効率でしかなく、
結局Linuxの例を出すまでもなく、OSS陣営の多くの開発がMSより10年遅れてると言われるのも頷ける。
今ではMSもgitに手を出すからブラウザ開発に失敗したり、Windows10はAppleのように互換性切り捨てだらけになってしまった。
縛りのない開放感なんて所詮、責任の放棄でしかないんだよ。
馬鹿な大臣がハンコを無くそうとしてるのと同じ。
397仕様書無しさん
2020/11/23(月) 02:07:26.56398仕様書無しさん
2020/11/23(月) 03:10:03.19 >>397
>>最後はoutlook
最後は電話
重要なメールをしたら必ず電話
この基本も知らない奴らが「その件なら1ヶ月も前にチケットにコメント書いてますけど」とか「slackに流してるのに、まだ対応してないとかふざけるな」とか平気で言う
「pullして無いのそっちですよね」
>>最後はoutlook
最後は電話
重要なメールをしたら必ず電話
この基本も知らない奴らが「その件なら1ヶ月も前にチケットにコメント書いてますけど」とか「slackに流してるのに、まだ対応してないとかふざけるな」とか平気で言う
「pullして無いのそっちですよね」
399仕様書無しさん
2020/11/23(月) 08:37:55.78 メールこそ正義
証跡をあとから編集できるslackや何言ってたかわからない電話のやりとりなど業務連絡のうちにはいらない
証跡をあとから編集できるslackや何言ってたかわからない電話のやりとりなど業務連絡のうちにはいらない
400仕様書無しさん
2020/11/23(月) 08:41:58.23 まあおれだったら、素直に会社に行くんだけどね。
401仕様書無しさん
2020/11/23(月) 08:56:45.56 SVN使っても変わらないは流石に老害の暴論
402仕様書無しさん
2020/11/23(月) 09:07:01.44 だからまあ、前にも言ったけど、こういうのは、
ちゃんと管理責任者を決めて、そいつにやらせなきゃダメだよ。
そいつはsvnでもギットでも日付フォルダでも好きにやればいい。
で、tortoiseなんて末端作業員のマシンに入れさせちゃダメ。
リポジトリURLは、会社のトップシークレットだと思わなきゃ。
ちゃんと管理責任者を決めて、そいつにやらせなきゃダメだよ。
そいつはsvnでもギットでも日付フォルダでも好きにやればいい。
で、tortoiseなんて末端作業員のマシンに入れさせちゃダメ。
リポジトリURLは、会社のトップシークレットだと思わなきゃ。
403仕様書無しさん
2020/11/23(月) 09:17:17.70 同じくDVCSのMercurialはrebase機能あるけど
拡張機能が必要
できれば使ってほしくないみたいな感じ?
gitは最初からrebase可能
何をしようとしているか分かっているんだから
邪魔をするな!と言うリーナスの思想が現れている
force pushをfeatureブランチ限定にしても、
rebaseをすると、それをする前のfeatureブランチの履歴が失われると言うデメリットはある
拡張機能が必要
できれば使ってほしくないみたいな感じ?
gitは最初からrebase可能
何をしようとしているか分かっているんだから
邪魔をするな!と言うリーナスの思想が現れている
force pushをfeatureブランチ限定にしても、
rebaseをすると、それをする前のfeatureブランチの履歴が失われると言うデメリットはある
404仕様書無しさん
2020/11/23(月) 09:44:23.34405仕様書無しさん
2020/11/23(月) 09:47:55.60 >>397
おまえなんも知らんのだな・・・メール頼みは怖いぞ
商社をクビになった社員が顧客情報を持ち出して
商社のテンプレートで振込先変更の連絡を入れてきて
売上金をだまし取られた詐欺事件が横行している
おまえなんも知らんのだな・・・メール頼みは怖いぞ
商社をクビになった社員が顧客情報を持ち出して
商社のテンプレートで振込先変更の連絡を入れてきて
売上金をだまし取られた詐欺事件が横行している
406仕様書無しさん
2020/11/23(月) 11:37:36.80 内部の人間の問題はセキュリティだけじゃ何ともならんよ
出したときにID,パスワード,アドレスを全部消すか変更しとけよ
それでも別のアドレスで接触も可能
そんなもん人間の問題だし、捕まったなら追跡できたわけで完全な抜け穴だったわけでもない
抜かれても追えない、気が付かない方がよっぽど怖い
出したときにID,パスワード,アドレスを全部消すか変更しとけよ
それでも別のアドレスで接触も可能
そんなもん人間の問題だし、捕まったなら追跡できたわけで完全な抜け穴だったわけでもない
抜かれても追えない、気が付かない方がよっぽど怖い
407仕様書無しさん
2020/11/23(月) 12:05:54.08408仕様書無しさん
2020/11/23(月) 13:00:35.46 別にgitが管理してくれるわけじゃない
409仕様書無しさん
2020/11/23(月) 15:42:50.44 なるほど。だからgit使えるだけでマウンティング取る開発経験のない若いPGがgit使うと
デスマーチ、開発放棄になるのも当然だな
デスマーチ、開発放棄になるのも当然だな
410仕様書無しさん
2020/11/23(月) 21:20:47.49 てかマージがうまくできないならpushすんな
ってのができるだけでもgitの価値あるだろ。
その辺、中央管理だといちいち普通の作業でも同期とるっていうのがクソ厄介。
ある程度コミットが整ったらpushっていう分散管理のが明らかにまともだわ。
ってのができるだけでもgitの価値あるだろ。
その辺、中央管理だといちいち普通の作業でも同期とるっていうのがクソ厄介。
ある程度コミットが整ったらpushっていう分散管理のが明らかにまともだわ。
411仕様書無しさん
2020/11/23(月) 21:26:45.02 SVNにはstashもない
stash相当の事は自分でパッチファイル作ってやる必要がある
めんどくさい
stash相当の事は自分でパッチファイル作ってやる必要がある
めんどくさい
412仕様書無しさん
2020/11/23(月) 21:48:50.28413仕様書無しさん
2020/11/23(月) 21:53:10.09 GitHubありがとう!
わからないとこ検索したら凄い人見つけて真似して解決した
ありがとうGitHub!
わからないとこ検索したら凄い人見つけて真似して解決した
ありがとうGitHub!
414仕様書無しさん
2020/11/23(月) 22:01:17.67 ソースとってきて修正して戻す
っていうスパンが長すぎたら結局どうにもならんでしょ
迷惑かけない程度に手を速く動かせよ
っていうスパンが長すぎたら結局どうにもならんでしょ
迷惑かけない程度に手を速く動かせよ
415仕様書無しさん
2020/11/23(月) 22:07:08.79416仕様書無しさん
2020/11/23(月) 23:23:56.95 >>415
本気で言ってる意味が理解出来ない。gitだと行単位でコンフリクト起こしても自動で解決してくれるとでも言いたいのか??
本気で言ってる意味が理解出来ない。gitだと行単位でコンフリクト起こしても自動で解決してくれるとでも言いたいのか??
417仕様書無しさん
2020/11/23(月) 23:31:11.07 バージョン管理システムに幻想を抱きすぎ
418仕様書無しさん
2020/11/23(月) 23:32:36.58 >>416
そのコミットは捨てといて他のところをいじるってのができるだろ。
コンフリクトがどれくらい致命的かわからんのだから一般にそのコミットを入れないで他をいじるってのが、
中央管理だとやりづらいってことだ。
一人で一点だけ見てればそういうことはないんだろうが。
そのコミットは捨てといて他のところをいじるってのができるだろ。
コンフリクトがどれくらい致命的かわからんのだから一般にそのコミットを入れないで他をいじるってのが、
中央管理だとやりづらいってことだ。
一人で一点だけ見てればそういうことはないんだろうが。
419仕様書無しさん
2020/11/23(月) 23:54:47.57 コーンフロストなのかコーンフレークなのかどっちや
420仕様書無しさん
2020/11/24(火) 00:18:56.24 コーンフロスティやろ
421仕様書無しさん
2020/11/24(火) 00:36:57.89 gitなんて大した技術がいるものでも無かろうに
未だに触ってないのはよっぽど頭の固いやつだけだ
未だに触ってないのはよっぽど頭の固いやつだけだ
422仕様書無しさん
2020/11/24(火) 01:11:49.88 ドキュメントのバージョン管理ツールください
末端にはマイナーバージョン3つくらい違うやつしかこない
末端にはマイナーバージョン3つくらい違うやつしかこない
424仕様書無しさん
2020/11/24(火) 05:35:50.23 つ えんぴつ
つ ノート
つ ノート
426仕様書無しさん
2020/11/24(火) 13:45:06.93 最新バージョンを編集してくれと言われたから、コミットハッシュはどれですかと聞いたのに、
とにかく最新バージョンをいじれの一点張りの馬鹿がいたりする。
自分らの使ってるものなのに何もわからんって輩が巷には多い。
とにかく最新バージョンをいじれの一点張りの馬鹿がいたりする。
自分らの使ってるものなのに何もわからんって輩が巷には多い。
427仕様書無しさん
2020/11/24(火) 14:06:15.13 最新バージョンをいじればいいんじゃないか
特定に何の情報が足りなかったんだ
特定に何の情報が足りなかったんだ
431仕様書無しさん
2020/11/24(火) 17:31:04.05 俺も最新バージョンで良いと思うが、最初に言質をとっておかないと
「あとでそんなこと言った記憶はない」って暴れだして面倒だろ
「あとでそんなこと言った記憶はない」って暴れだして面倒だろ
432仕様書無しさん
2020/11/24(火) 17:39:15.38 社内でめんどくさすぎる
433仕様書無しさん
2020/11/24(火) 17:39:37.42 天才 「できましたー」
バカ 「最新、最新のやつ編集しといて」
天才 「branchが最新だったので編集しましたー」
バカ 「はあ?masterの最新のつもりで言ったんだよ!」
天才 「なら最初からそう言えよ( ゚д゚)、ペッ」
バカ 「最新、最新のやつ編集しといて」
天才 「branchが最新だったので編集しましたー」
バカ 「はあ?masterの最新のつもりで言ったんだよ!」
天才 「なら最初からそう言えよ( ゚д゚)、ペッ」
436仕様書無しさん
2020/11/24(火) 19:21:29.53 エスパー要素が必要になるよな
439仕様書無しさん
2020/11/24(火) 19:41:01.37 チェリーピックって何か響きがやらしい
https://i.imgur.com/6jvYwHM.jpg
https://i.imgur.com/6jvYwHM.jpg
441仕様書無しさん
2020/11/25(水) 02:59:49.80 masterじゃなくてmainですわよご主人様♪
442仕様書無しさん
2020/11/25(水) 07:55:55.19 え?
ヤバイヤツキタ・・・?
ヤバイヤツキタ・・・?
444仕様書無しさん
2020/11/25(水) 17:06:33.69 だいたい同じコミットハッシュなんか複数のブランチに存在する
コミットハッシュを聞いても最新バージョンにはならない
コミットハッシュを聞いても最新バージョンにはならない
445仕様書無しさん
2020/11/26(木) 12:52:49.88 なぜSQLiteはソースコード管理にGitを使わないのか?
https://www.sqlite.org/whynotgit.html
https://www.sqlite.org/whynotgit.html
446仕様書無しさん
2020/11/26(木) 12:58:31.66 おまえが使える技を全員が使えるなら使ってる
おまえしか使わないものを全員は使わない
おまえしか使わないものを全員は使わない
447仕様書無しさん
2020/11/26(木) 14:32:18.88 >>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.
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.
451仕様書無しさん
2020/11/26(木) 18:32:41.86 > to understand the perspectives presented below.
肝心の理由もここにかいてくださいな…
肝心の理由もここにかいてくださいな…
452仕様書無しさん
2020/11/26(木) 19:10:47.04 フォッシルかギットか?
って話なのでSVNとかCVSとかVSSは問題外
って話なのでSVNとかCVSとかVSSは問題外
454仕様書無しさん
2020/11/26(木) 20:53:41.48 >>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ってちょっと...って皆が薄々思ってる事が書かれてるな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
455仕様書無しさん
2020/11/26(木) 20:56:27.49 gitの一番のメリットはやる気が出ること
コメント欄に「〇〇を修正」って書く習慣が出来るだけでけっこう違う
コメント欄に「〇〇を修正」って書く習慣が出来るだけでけっこう違う
456仕様書無しさん
2020/11/26(木) 21:12:12.33 git以外でも一緒じゃねーか
457仕様書無しさん
2020/11/26(木) 21:17:44.34 gitのっていうから誤解があったな
バージョン管理ツールのメリットな
バージョン管理ツールのメリットな
458仕様書無しさん
2020/11/26(木) 21:18:44.17 Mercurialはなんでgitに負けたの?
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 一律現金給付も消費減税もなし 高市内閣の経済対策に割れる世論 [蚤の市★]
- 高市早苗総理「農水大臣が大好きなおこめ券」 野党が“おこめ券”追及 [Hitzeschleier★]
- 日銀「歴史的」利上げ迫る 35年ぶりの年間上げ幅、0.5%の壁を突破 [蚤の市★] [蚤の市★]
- 国分太一、地上波復帰は困難でもキャンプ趣味を活かしYouTubeで復帰するシナリオも「参戦すればキャンプYouTuberの人気の構図が一変」 [Ailuropoda melanoleuca★]
- 【MLB】ドジャース、最優秀救援3度&通算253セーブの守護神・ディアスを獲得! スコット低迷、佐々木朗希は先発復帰で [冬月記者★]
- 津波警報の発表中にグーグル検索、AIが「すべて解除」と誤情報 [蚤の市★]
- もしもスクリプトがAIで返信するようになれば
- 高市早苗さん、今度は韓国にも喧嘩を売ってしまう。 ほんまこいつwwww [271912485]
- 【高市悲報】日本人のTikTokアカウントが続々収益化剥奪中!!乞食どもざまああああああああwwwwwww [394917828]
- 千晴もう寝ろ
- プリキュア「夢を諦めないで!努力すれば夢はいつか叶う!」⇦これ
- トランプ大統領、レーダー照射問題で沈黙貫く。高市政権は米側に「早く中国を叩く声明を出して!」と泣きつくも無視される [271912485]
