ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】

**デフォルトの名無しさん** · 2018/07/17(火) 19:44:50.42

ソースコードホスティングサービスについて情報交換したり語り合ったりするスレ

ソースコードホスティングサービスの例
GitHub GitLab Bitbucket SourceForge Launchpad など

OSSホスティングサービスの比較 - Wikipedia
http://ja.wikipedia.org/wiki/OSS%E3%83%9B%E3%82%B9%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%81%AE%E6%AF%94%E8%BC%83

Comparison of open-source software hosting facilities - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Comparison_of_open-source_software_hosting_facilities

前スレ
OSSホスティング総合【SourceForge,GitHub,etc..】
https://mevius.5ch.net/test/read.cgi/tech/1384821518/

**デフォルトの名無しさん** · 2020/04/15(水) 14:38:36.26

>>281 日本語訳

GitHubのコア機能を無料で利用できるようになりました
https://github.blog/jp/2020-04-15-github-is-now-free-for-teams/

**デフォルトの名無しさん** · 2020/04/15(水) 16:32:17.35

マジか！とうとうコボラデータが使えるように！

**デフォルトの名無しさん** · 2020/04/15(水) 16:59:23.71

ProプランはTeamプランに変わった？

**デフォルトの名無しさん** · 2020/04/15(水) 17:40:14.43

変わったというかそのへんの体系が全部見直された

**デフォルトの名無しさん** · 2020/04/15(水) 17:58:40.56

一人で使うプライベートリポジトリでWiki使えるようにしてほしかった

**デフォルトの名無しさん** · 2020/04/15(水) 17:59:48.88

プライベートならどっかに書いとけよ

**デフォルトの名無しさん** · 2020/04/15(水) 20:56:02.82

Proは無くなったわけじゃないけど一覧からは消えたのか
Freeとの差別化が難しいからかな

**デフォルトの名無しさん** · 2020/04/16(木) 02:26:41.91

>>284
MBでした…

**デフォルトの名無しさん** · 2020/04/16(木) 11:11:19.96

>>289
使えるやろ

**デフォルトの名無しさん** · 2020/04/22(水) 08:38:04.96

18 GitLab features are moving to open source
We're open sourcing rich functionality across Plan, Create, Verify, Package, Release, Configure, and Defend.
https://about.gitlab.com/blog/2020/03/30/new-features-to-core/

**デフォルトの名無しさん** · 2020/05/03(日) 21:17:29.85

githubで送ったプルリクが取り込まれたんですけど、
その後に不具合がありました
この場合って新規でプルリクを作成して送ればいいんでしょうか？
それとも最初に送ったプルリクのスレッドにプルリクを送るのでしょうか？

**デフォルトの名無しさん** · 2020/05/03(日) 23:21:59.66

>>295
そのプロジェクトの方針に従うのが一番。いきなりプルリクエストってのはNGなとこもあるし。
プルリクエストがもうmergeされたなんなら、ひとまずissueたてて、リグレッション起こしたそのプルリクエストへのリンクを貼っとくってのが無難。

**デフォルトの名無しさん** · 2020/05/04(月) 02:07:07.23

> いきなりプルリクエストってのはNGなとこもあるし。
ほんとにあるの？
アホな日本のプロジェクトならありそうだがｗ

プルリクは送っていい。駄目なら駄目って指摘があるやろ？
くだらないIssue立てて怒るやつはいても、プルリクを送って怒るやつはいない。
それよりかIssue管理する手間のほうが面倒
一番時間がかからないのはどれか？無駄な手続きで手間増やすよりも手間が少ない方を選べ

**デフォルトの名無しさん** · 2020/05/04(月) 02:09:02.33

>>295
そもそもマージされてクローズされたものに追加でプルリク送れんやろ？

さっさと新しくプルリクだせ。
コード（とテスト）に問題なければ、すぐマージして終わりやろ

**デフォルトの名無しさん** · 2020/05/04(月) 02:12:29.19

>>297
え…普通にあるやろ。まず方針をディスカッションしてからってのはごくごく一般的。
publicなAPIに変更がある場合なんかは特にね。リリースノートを自動作成する際にissueをもとにしてるプロジェクトもあるし。

**デフォルトの名無しさん** · 2020/05/04(月) 02:24:57.53

>>297
https://github.com/dotnet/runtime/blob/master/CONTRIBUTING.md#dos-and-donts

>DON'T add API additions without filing an issue and discussing with us first. See API Review Process.

まあ不具合を把握しているのであれば、修正に取り組む前にとりあえずissueたてて共有すべきだとは思うけどね。

**デフォルトの名無しさん** · 2020/05/04(月) 02:46:34.20

オープンソースなのにいきなりプルリクNGはガイジ
機能を理解できてない

いきなり何らかのリクエストされても、それをマージするまでにクッションを置いて、考慮する為の「リクエスト」なのに、それすらだダメならソース公開するのやめて身内で細々と開発すりゃいいｗ

**デフォルトの名無しさん** · 2020/05/04(月) 02:53:33.57

>>300
それのどこにいきなりプルリク禁止って書いてあるんですか？ｗ

英語読めないなら翻訳してあげましょうか？ｗ

>問題を提出して最初に私たちと話し合うことなくAPIの追加を追加しないでください。 APIレビュープロセスを参照してください。

**デフォルトの名無しさん** · 2020/05/04(月) 02:55:04.97

>>302
いや英語読めてないのお前やんw

**デフォルトの名無しさん** · 2020/05/04(月) 02:55:50.20

>>301
issueでディスカッションしてから実装ってのは一般的だよ

**デフォルトの名無しさん** · 2020/05/04(月) 02:56:42.00

>>302
これは恥ずかしい

**デフォルトの名無しさん** · 2020/05/04(月) 03:00:56.79

こっちもそうだね。現実が見えない人なのかしら。
https://github.com.cnpmjs.org/dotnet/wpf/blob/master/Documentation/contributing.md

>Please open issues for changes that affect the IL or might require additional validation, and work with the project maintainers to determine whether a PR would be appropriate.

**デフォルトの名無しさん** · 2020/05/04(月) 03:01:05.65

>>304
一般的とは？
10個ぐらい見つけてこれる？

**デフォルトの名無しさん** · 2020/05/04(月) 03:01:58.87

またdotnet（笑）
そういうものしか見つけられないんだろうね
dotnetとか普通のオープンソースとは違うやろ

**デフォルトの名無しさん** · 2020/05/04(月) 03:04:10.14

教えて君か…一人でここで吠えてるといいよ
現実は変わらないけどね

**デフォルトの名無しさん** · 2020/05/04(月) 03:04:51.25

>>308
普通のオープンソースとは？

**デフォルトの名無しさん** · 2020/05/04(月) 03:08:18.03

>>297
>ほんとにあるの？
あったやろw

**デフォルトの名無しさん** · 2020/05/04(月) 06:39:00.60

ちゃんと上長に電話で許可取ってからプルリクしろよ

**デフォルトの名無しさん** · 2020/05/04(月) 07:00:08.78

ハンコ下さい

**デフォルトの名無しさん** · 2020/05/04(月) 12:24:50.51

電話じゃだめ
書類にはんこじゃないと

**デフォルトの名無しさん** · 2020/05/04(月) 12:30:45.25

>>303
API追加についてはレビュー必須って書いてあるだけだぞ。
バグフィックスならいきなりpullreqでもOKだろう。

例に挙げるならバグフィックスでもissue必須なプロジェクトを挙げなくてはいかんな。

**デフォルトの名無しさん** · 2020/05/04(月) 12:32:47.20

>>306
こっちもIL追加についてはレビュー必須って書いてあるだけじゃん。
バグフィックスについてはいきなりpullreqでOKなプロジェクトの例になってるな。

**デフォルトの名無しさん** · 2020/05/04(月) 13:43:15.82

>>316
ILが何かわかってないことがバレバレ

**デフォルトの名無しさん** · 2020/05/04(月) 13:52:26.06

>>315
ソースまであげたのに読まずに批判とは恥ずかしい。
コントリビューションのフローは1がissue、プルリクは7な。issueをスキップできるのはtrivialな変更の場合で、具体例としてはtypoね。

https://github.com/dotnet/runtime/blob/master/CONTRIBUTING.md#suggested-workflow

**デフォルトの名無しさん** · 2020/05/04(月) 14:21:53.30

バグ見つけたんならとりあえずissue上げておかないと、修正したりテストやってる間に他の人がそのバグを踏む可能性があるからね。
まずはバグを報告させるってのはOSSに限らず別に珍しくはないと思うんだが…
長く使われているライブラリやフレームワークだと、バグであったとしてもそのバグがあることが前提で動いているコードが世の中に溢れている、なんてことはよくあるから単純に直せばいいって訳でもない。

**デフォルトの名無しさん** · 2020/05/04(月) 14:26:46.93

>>316
「please file issues to make bugs "known"」ってあるけど、どこに「
バグフィックスについてはいきなりpullreqでOK」と書いてあるんですか？

**デフォルトの名無しさん** · 2020/05/04(月) 14:35:27.86

>>318
typoは例として挙げられてるだけで
バグフィックスだって off by one みたいな trivial な奴ならいきなり pullreq でも OK だろう。
テストコードもつけとく必要はあるだろうけどね。

**デフォルトの名無しさん** · 2020/05/04(月) 14:38:16.94

>>321
ランタイムのバグ修正は本当にtrivialなものかどうか見分けるのが大変だから、フローに書いてあるとおりまずはissueが筋。
テストコード書く前にissue上げとけよ。自分一人の趣味プロジェクトなら別にいいんだけどね。

**デフォルトの名無しさん** · 2020/05/04(月) 14:40:33.84

>>321
え、off by oneならIL変わるやろｗｗｗ
どのリリースに含めるべきかどうかも検討しなくちゃいけないんで、まずはissueね。

**デフォルトの名無しさん** · 2020/05/04(月) 14:46:36.93

バグ見つけたのに報告せず自分で抱え込んじゃうやつとか、まじで害悪やろ。こんなバグ見つけたから修正するねーってissue上げることの何が難しいんだろう。フローにもわざわざ丁寧にissue書けって明示してあるんだし。

**デフォルトの名無しさん** · 2020/05/04(月) 14:51:05.39

バグ修正ならなおさらメンテ中のどのバージョンで修正するかって方針も決めなきゃいけないしね。最新の4.X系だけでいいのか、1.X～4.Xまで全部修正するのか、みたいな。それによってどのコードをベースにして修正方針を立てるのかが変わってくる。

**デフォルトの名無しさん** · 2020/05/04(月) 14:59:15.66

>>323
元URL読んでなくてCLRランタイム側のIL解釈の実装が変わる場合と勘違いしてた。
正直ｽﾏﾝｶｯﾀ
WPFのリポジトリだからそもそもそんなことありえないし
ここはコードの整形程度の話であっても生成されるILが変わるならダメって文脈なんだな。
これは厳しい。

まあでもこれは利用者の数がやたらと多い dot net の Microsoft 公式リポジトリだから厳しいって話であって
github のプロジェクトのなかではむしろ例外的だと思うよ。
ふつうの規模のプロジェクトだと issue と PR で二重に同じ話が出てくると手間が増えて嫌がると思うよ。

**デフォルトの名無しさん** · 2020/05/04(月) 15:13:17.00

>>319
だからなんなのかわからん

お前が言ってることへの対応なら、
とりあえずissueでも、とりあえずprでも、どっちでもいいだろ

**デフォルトの名無しさん** · 2020/05/04(月) 15:13:57.17

>>320
> バグフィックスについてはいきなりpullreqでOK」と書いてあるんですか？

アホ・・・書いてないなら禁止だ
天才・・・書いてないならOKだ

**デフォルトの名無しさん** · 2020/05/04(月) 15:15:26.69

>>326
普通の規模のプロジェクトであっても、バグを見つけたらまずは報告してほしいと思うけどね
>>325も言うように、メンテナー以外は修正方針について熟知しているわけではないから、とりあえずissueを立てて、そのへんのめんどうな議論は任せちゃった方が楽だよ。方針が決まってから動き出せばいい。

**デフォルトの名無しさん** · 2020/05/04(月) 15:17:10.49

>>327
一度ランタイム系のリポジトリにいきなりPRしてみるといいよ

**デフォルトの名無しさん** · 2020/05/04(月) 15:18:02.51

>>328
「please file issues to make bugs "known"」ね。

**デフォルトの名無しさん** · 2020/05/04(月) 15:18:45.54

>>324
> こんなバグ見つけたから修正するねーってissue上げることの何が難しいんだろう。

お前バカだろ？
PR書けない、俺には修正できない。俺は修正しない。だからIssueを出すのであって
簡単にPRだせるのにIssue作ってどうする？
余計な手間を増やしてるだけ

> バグ修正ならなおさらメンテ中のどのバージョンで修正するかって方針も決めなきゃいけないしね。
お前はPRは何も会話せず、マージするものだと思ってんのか？
PRなんて修正コード付きIssueにすぎねーよ

問題報告しか出来ない・・・Issue
問題報告とすでに修正済みだぜ・・・PR

これだけだろ

**デフォルトの名無しさん** · 2020/05/04(月) 15:20:05.49

>>330
> 一度ランタイム系のリポジトリにいきなりPRしてみるといいよ
ランタイム系のリポジトリというのことは
いきなりPRが禁止されてないリポジトリも含みますよねｗ

いきなりPRが禁止されてないなら、いきなりPRして
何の問題もないんですが？それともなにか問題でもあるんですか？

**デフォルトの名無しさん** · 2020/05/04(月) 15:21:29.76

>>329
> 普通の規模のプロジェクトであっても、バグを見つけたらまずは報告してほしいと思うけどね

誰がバグ対応するんだよ。報告されたところでバグはなおらん
なおせるならさっさとお前がしろ

それが普通

**デフォルトの名無しさん** · 2020/05/04(月) 15:23:45.89

考える頭がないやつは、マニュアル通りにしか行動できないんだよね

あ、はい、先にIssueですね。
先にPRは絶対しません。
なーにーがーあろーとも

場合によってIssueを作るかPR作るかを考える頭がない
マニュアルが決めてられないと何も行動できないんです！

**デフォルトの名無しさん** · 2020/05/04(月) 15:24:21.61

キチガイに触るなよ

**デフォルトの名無しさん** · 2020/05/04(月) 16:22:12.04

質問したものですけど
英語書くのきついので無視しても大丈夫ですかね？
自分のリポジトリでもないし

**デフォルトの名無しさん** · 2020/05/04(月) 16:42:25.33

>>337
良心が痛むなら、issueで不具合の内容と再現手順を報告すればいい。Google翻訳とコードスニペットで伝わるし、なんなら日本語を併記してもOK。

**デフォルトの名無しさん** · 2020/05/04(月) 18:35:10.36

修正方法がわかってるならさっさと修正すればいいだろ
相手に余計な手間をかけさせるな

**デフォルトの名無しさん** · 2020/05/04(月) 18:50:39.80

プロジェクトの方針によるやろそんなもん

**デフォルトの名無しさん** · 2020/05/04(月) 20:06:23.54

伸びてると思ったら暇で相手して欲しい馬鹿が暴れてたか

**デフォルトの名無しさん** · 2020/05/04(月) 23:17:43.95

しょうもないバグ修正にわざわざissue立ててからPR立てるやつマジなんなん？ウザいんだけど
さっさとPR立ててくれ

**デフォルトの名無しさん** · 2020/05/04(月) 23:28:51.84

>>340
プロジェクトで手順が決まってるならそれに従うのは当たり前だろ
そのためにissue templateとかの機能があるんだから
その場合は考える余地はない

そういうのがない場合はさっさと直しちまえよ
直すのが大変なときだけissueを作ればいい
つまり場合に応じて適切なものを選べばいいんだよ
自分の頭で考えろ。目的を達成する一番の近道は何かを

こういうやつが勝手にオレオレマナーを作り出すんだろうかねｗ
自称深く考えたつもりの人間が、最悪のケースのために複雑なルールを作り
単純なケースまでも手間がかかるようにする。本人はちゃんと考えた俺偉いとか思ってるんだろうな

**デフォルトの名無しさん** · 2020/05/04(月) 23:52:43.98

>>329
> 普通の規模のプロジェクトであっても、バグを見つけたらまずは報告してほしいと思うけどね

これは英語の得意な奴orコード書くのがすごく好きというわけでもない人間の意見だと思う。

言葉で説明するよりも(たとえ理想の解じゃないにしても)パッチの形で問題の説明する方が得意な人間はいる。
受けとる側も言葉だけよりもパッチがあった方が問題の理解に役立つケースも多い。

あとコード読み書き書くのがすごく好きだと、コード読んでまずパッチを書いてみちゃうってのもある。

パッチはそのままの形で採用されなくてもいいんだよ。問題点の理解に役立てばそれでいい。

> >>325も言うように、メンテナー以外は修正方針について熟知しているわけではないから、とりあえずissueを立てて、そのへんのめんどうな議論は任せちゃった方が楽だよ。方針が決まってから動き出せばいい。

仕事でコード書いてるなら確かにそうなる。
パッチ書く労力が無駄だからね。
でもコード書くのが大好きで趣味でパッチ書いてるならそうでもないんだなあ。

dot net みたいな超巨大プロジェクトになると開発プロセスを厳密にした方がいいってのも勿論わかるが。

**デフォルトの名無しさん** · 2020/05/04(月) 23:58:45.96

Issue投げられても「お前の言ってることはわかる。だが俺は忙しい。」ってなるだけだからな

**デフォルトの名無しさん** · 2020/05/05(火) 00:55:49.79

昔のメールやネットニュースで開発してたころなら
パッチ送る前にバグ報告してパッチの作成の了解取る前に
送るなという主張か

**デフォルトの名無しさん** · 2020/05/05(火) 01:39:08.42

不具合の報告と修正を分けることは、
報告者と修正者が同じである必要性をなくすことでもあるし、
工程を切り分けて対応を容易にするためでもある

まずIssueを立て、以下を記す

1.再現環境
2.再現コード
3.実際の挙動
4.期待する挙動

その挙動が再現できて、
それが不具合だと判断されて、
期待する挙動が妥当なら修正に取り掛かれる

このように、
Issueでは問題に対して焦点を当てる
PullRequestでは実装に対して焦点を当てる

**デフォルトの名無しさん** · 2020/05/05(火) 06:33:59.62

たにぐちまこと

Git+GitHub入門 #01：リポジトリーの作成とコミット
https://www.youtube.com/watch?v=_PyuylNk64o&;list=PLh6V6_7fbbo_M3CqTeJvuXB08--fibyBu

YouTube に、分かりやすい動画がある

**デフォルトの名無しさん** · 2020/05/05(火) 09:50:24.61

Githubにもマナー講師がマナーを説くようになるのか

**デフォルトの名無しさん** · 2020/05/05(火) 10:54:20.67

>>347

まずPull Requiestを立て、以下を記す

1.再現環境
2.再現コード
3.実際の挙動
4.期待する挙動
5.そうなるように修正

何度も言うが相手に手間を掛けさせるな

LGTMとだけ書いてマージするほうが何倍も楽なんだよ

**デフォルトの名無しさん** · 2020/05/05(火) 11:03:57.42

結局先にIssue立てろと言ってるやつは
自分がめんどくさいことをしたくないだけなんだよな

自分が修正したものが捨てられたらどうしよう
自分の作業が無駄になるかもしれないから俺は何もしたくない
報告だけしてあとは相手にやらせよう

**デフォルトの名無しさん** · 2020/05/05(火) 11:09:32.97

issue出してくれるだけでもありがたいよ
何か不具合あっても報告してくれなくて黙って使うのやめる人が殆どだから

**デフォルトの名無しさん** · 2020/05/05(火) 11:10:56.12

そりゃ修正する能力がない人は
Issue作るしかないだろ

そういう話ではなく能力があるなら
さっさと修正してPR出せという話
手間かけなくていい問題に、わざわざ相手に手間を掛けさせるな

**デフォルトの名無しさん** · 2020/05/05(火) 11:36:17.94

GitHubのマナーというより、広く使われている方法っていう程度のことじゃない？

それぞれ自分の思う「こうするべき、こうあるべき」形っていうのはあるだろうけど、開発の体制や規模とかによっても変わってくるし
プロジェクトオーナーの好みとかもあるから、それに従うのが良いんじゃないかな？

例えば開発メンバーが決まっているプロジェクトだったら、Issue立てて課題を認識・共有してから担当決めて担当者がPR出すみたいな流れが一般的だと思うけど、誰でも参加可能なプロジェクトなんかだと、Issueを廃してPRだけでやってるところもあるよね
https://github.com/soimort/you-get/

誰でも参加可能だと単なる質問とかのIssue乱発で収集つかなくなりやすいので、それを防ぐ目的でPRベースでやってるのはちょくちょく目にする

**デフォルトの名無しさん** · 2020/05/05(火) 11:45:46.25

Issueはコードなしで作れるからね
めんどくさいからさっさとコード書けと
それをどうするかはこっちで考える

**デフォルトの名無しさん** · 2020/05/07(木) 08:28:21.18

GitHubがクラウド開発環境「Codespaces」、ディスカッション機能「GitHub Discussions」などを発表
https://www.atmarkit.co.jp/ait/articles/2005/07/news041.html

**デフォルトの名無しさん** · 2020/05/07(木) 10:05:07.28

>>351-352
プルリク出してこないfork厨も割とうざい

**デフォルトの名無しさん** · 2020/05/07(木) 10:07:15.77

>>357
forkだけして何もしないやつが10人中5人ぐらいいるんだけど
こいつらなんなんだろう？

**デフォルトの名無しさん** · 2020/05/07(木) 10:11:28.52

誤forkかもしれない
どういう人がスター付けてるか見ようとして間違ってForkのとこ押してしまうことがよくある

**デフォルトの名無しさん** · 2020/05/07(木) 17:24:51.93

プルリク送ったけどマージもクローズもしてくれないから
フォークを外したいが外したらプルリクが消えないか心配

**デフォルトの名無しさん** · 2020/05/07(木) 17:36:40.28

ローカルに保存しとけよｗ

**デフォルトの名無しさん** · 2020/05/07(木) 20:41:33.75

なんだ？プルリク出す気ないやつはフォークするなってライセンスにでもしてんのか？

**デフォルトの名無しさん** · 2020/05/08(金) 08:44:21.48

返答しても反応ないIssueってどうしてる？
俺はしばらく放置して誰の役にも立たないと思ったら閉じるつもりではいるが

**デフォルトの名無しさん** · 2020/05/08(金) 10:03:36.93

自分で治せるものならforkして治して自分のforkへ誘導すれば？

**デフォルトの名無しさん** · 2020/05/08(金) 10:10:32.10

>>364
ああ、違う違う。バグ報告じゃなくて質問
俺のリポジトリに来た質問という名のIssue

**デフォルトの名無しさん** · 2020/05/08(金) 10:19:44.78

返事無かったらcloseで良いんじゃない？

**デフォルトの名無しさん** · 2020/05/08(金) 10:31:57.32

>>366
まあいずれそうするつもりだけどね。
他にも似たような質問するやつがいるかも知れないし
全てクローズすると賑わってる感がなくなるからあえて残してるｗ
ホントなにしに質問に来たんだか

**デフォルトの名無しさん** · 2020/05/15(金) 11:12:19.50

GitHub Actionsって
BitbucketのPipelinesと同じ？Bitbucketからの移植って簡単？

**デフォルトの名無しさん** · 2020/05/16(土) 04:25:01.73

giteaのwikiで、
_Sidebarってページ作るとサイドバーになって、
_Footerってページ作るとフッターになるってのはわかったけど、
一度保存しちゃうと編集できない。
どうにかならんもんでしょうか。

**デフォルトの名無しさん** · 2020/05/23(土) 06:05:31.24

ああもう、こんな時間にGitHubトラブル起こすなや！

**デフォルトの名無しさん** · 2020/05/23(土) 07:55:46.20

なおらねぇなｗ

**デフォルトの名無しさん** · 2020/05/28(木) 15:02:20.20

Giteaってどう？

**デフォルトの名無しさん** · 2020/06/01(月) 00:43:52.10

>>372
さくっと立ち上げられるのでお手軽で、個人や小さめのチームでリポジトリを管理するには便利。
GitBucket と違ってワンバイナリなので、バージョンアップも気軽にできるし。

**デフォルトの名無しさん** · 2020/06/01(月) 01:11:13.59

>>373
Gitbucketも更新する時はgitbucket.warを置き換えるだけでは？

**デフォルトの名無しさん** · 2020/06/01(月) 04:51:54.11

>>374
でもJavaがいるしな

**デフォルトの名無しさん** · 2020/06/06(土) 12:38:12.61

Issueで説明求められたが1000行もないプログラムなんだから読めよと言いたいのが来て対応困ってる
OSSでコメントも十分付けてあるし何サボってんだと

**デフォルトの名無しさん** · 2020/06/06(土) 12:40:06.16

言えばいいじゃん何困ってんの？

**デフォルトの名無しさん** · 2020/06/06(土) 14:16:57.44

英語ができないんだろ

**デフォルトの名無しさん** · 2020/06/06(土) 15:10:46.80

そんなこと言うならおまえ日本語のレス禁止な。
30日間、英語で全レスしろ。
これ命令な。

ほら書け。
↓

**デフォルトの名無しさん** · 2020/06/06(土) 15:12:11.69

必死すぎやろｗ

**デフォルトの名無しさん** · 2020/06/06(土) 15:14:49.88

でも英語で書かないと誰も見てくれないし、Githubって辛いよなあ。

**デフォルトの名無しさん** · 2020/06/06(土) 15:15:03.69

gitlab.comはwindowsとmacのrunnerを提供してないのか？
自前で用意すんの面倒だな

**デフォルトの名無しさん** · 2020/06/06(土) 18:43:27.35

コメント読んで！で、close 🤔

**デフォルトの名無しさん** · 2020/06/06(土) 20:10:22.21

真面目にissueはサポート掲示板じゃないから
バグ報告じゃなければクローズでいいと思う

**デフォルトの名無しさん** · 2020/06/10(水) 13:58:27.29

GitHub CLI、政治汚染されてる…

ｿｰｽｺｰﾄﾞ ﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】

ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【GitHub,GitLab,Bitbucket等】