ｿｰｽｺｰﾄﾞﾎｽﾃｨﾝｸﾞ総合【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/02/20(木) 14:09:05.23

マジレスすると >>262 でも良いけど

どっちかというと本来の使い方で言えば
まず >>261 のところから自分の OS 用の git をダウンロード
それから自分のリポジトリ造りたいディレクトリ上で
git clone https://hogehoge.github.com/fugfuga.git

**デフォルトの名無しさん** · 2020/02/20(木) 15:43:16.71

>>262
できたさんくす

というかパッケージを管理するアカウントが別れてて
正式版とベータテストでわかれてた

**デフォルトの名無しさん** · 2020/03/03(火) 09:40:22.98

コーディングのド素人で今まで一度もこういうものに触れた事のないのだけれども
とあるゲームのMODの翻訳の編集のためにGitHubに参加させてもらってる状況です
もちろんGitHubの使い方なんてほとんどさっぱりで、ギリギリなんとか
リポリトジ、プッシュ、コミット、プルリクエスト、マージ、という流れで複数人が編集を共有しているのだというのはなんとなく把握できたレベル

で質問したいのですが
相手方のファイルが久々に更新されたので早速ファイルを翻訳しリポリトジを更新していざプルリクエストを送ってみた所
自分が触っていないファイルもそのコミットにひとまとめに更新された事になってしまい、リクエストの更新個所も膨大な数になってしまいました
こういう場合、相手(マスター？)にはどう映っているんでしょう？
やっぱりそのフォルダに入ってた一切合切もプルリクエストに含まれてしまってるんだろうか
それとも、中身が同一なファイルは自動的に除外されたりはしないんでしょうか。それだったら助かるのだけど…

**デフォルトの名無しさん** · 2020/03/03(火) 09:42:59.96

あ、訂正
プルリクエストはまだ送ってない。送ろうとした直前の確認画面までで止めました

例えばもう一回クローンやり直しとかすれば、相手側のブランチ？を汚したりせずに済むとかそんな事あります？

**デフォルトの名無しさん** · 2020/03/03(火) 09:44:43.61

ちなみに、両者のファイルの(翻訳した箇所以外の)内容はどれも同一である事は比較ソフトで確認しました

**デフォルトの名無しさん** · 2020/03/03(火) 13:51:42.17

ホントにまったく変更されてないのであれば更新箇所として表示されないので
実際には
・改行コードが変わった
・文字コードが変わった
・空白が増えたor減った
といった違いがあるはず。

こういうのがあるとそのままマージできないし
該当ファイルの変更作業をしている別の人の邪魔になるしで
嫌がられる。

pullreqを実際に出す前に原因調べて直すべき

調べても分かんないなら自分のリポジトリのURLをここに張ればたぶんすぐ判明するぞ

**デフォルトの名無しさん** · 2020/03/03(火) 15:21:46.58

・改行コードが変わった
・文字コードが変わった
・空白が増えたor減った
どれもぶん殴られるパターン

**デフォルトの名無しさん** · 2020/03/03(火) 16:10:37.59

＞更新箇所として表示されないので
ですよね。
自分も以前までは自分トコに上書きしても、自分が弄った部分だけがコミット？に上がってたので
今回も気にせずその今まで通りやったつもりだったんスよ。で今回はいつもと違って
突然ぶわっとすごい数の一覧が挙がったので、さすがにド素人の自分でもおかしいとは気づきました
なのでクローンを落としてそれと自分のとを比較ソフトで相違を確認したりもしました
自分が触ったトコ以外は寸分違わぬ状態だったのを確認しとります

例えば、自分がリクエスト上げたタイミングがまさにあっち側が作業中だった。って事も有り得ますよね？
ちょっとまだブランチの仕組みが今一把握できていない…ぱられるわーるど的な？ｗ

**デフォルトの名無しさん** · 2020/03/03(火) 16:12:17.35

あと、アレです
日本語翻訳以外にも、ロシア語だの中国語だのイタリーだのドイツ語だの、複数の言語が飛び交ってるんですよ
色んな方から翻訳文のプルリクエストが飛んでるみたい。自分はその隙間を縫ってコソっと送るカンジでやってるんですけど

**デフォルトの名無しさん** · 2020/03/03(火) 16:40:24.45

｢比較ソフトで比較｣ってのがまずダメでは?
その手のソフトが余計なお節介で改行コードとか文字コードとか空白の違いを無視してるのかもしれん。

git diff
で比較すべき

**デフォルトの名無しさん** · 2020/03/03(火) 17:08:40.61

>>272
「Win Merge」ってヤツなんだけど、どうでしょう
https://winmerge.org/?lang=ja

といっても、基本的にコードを弄ったりしてるのではなく、ただテキストを加筆してるだけなので多分大丈夫だとは…
とやきもきしてたら勢い余ってプルリクエスト送信してしまいました…(ﾃﾍﾍﾟﾛ)
どうも即座に反映してくれたみたいなので、大丈夫だったっぽい？
Github上での一覧のコメント見るに、自分が弄ったファイルだけが反映されてる様なので結果的に良かった

いや、素人がこういうのに手出しちゃダメっすね…

**デフォルトの名無しさん** · 2020/03/03(火) 17:28:37.35

むしろwinmergeが悪さして破壊してるんじゃね

**デフォルトの名無しさん** · 2020/03/04(水) 11:26:42.25

WinMergeはそんな悪さしないけどなあ
VSで改行コード混在してるけど統一していいか？とか聞かれなかった？

**デフォルトの名無しさん** · 2020/03/04(水) 12:47:20.02

autoclfじゃねぇのか

**デフォルトの名無しさん** · 2020/03/04(水) 23:08:18.78

WinMergeは改行ズレを自動的に補正してくれる優秀な子だよ

**デフォルトの名無しさん** · 2020/03/06(金) 10:24:47.58

>末尾の空白が消える

**デフォルトの名無しさん** · 2020/03/19(木) 14:35:07.73

GitHub for mobile の正式版をリリース
https://github.blog/jp/2020-03-19-github-for-mobile-is-now-available/

**デフォルトの名無しさん** · 2020/03/26(木) 05:25:41.46

GitHubにIssueのvote機能ないかね？
いつの間にか、親指立ててあったりしても気づかんのよね。
票が多ければそれを優先対応したいんだが

**デフォルトの名無しさん** · 2020/04/15(水) 02:09:17.32

GitHubきたな
https://github.blog/2020-04-14-github-is-now-free-for-teams/

**デフォルトの名無しさん** · 2020/04/15(水) 02:46:01.60

ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

**デフォルトの名無しさん** · 2020/04/15(水) 06:03:02.83

500GBまでならfreeでも使えるってイイね

**デフォルトの名無しさん** · 2020/04/15(水) 10:22:23.10

>>283
MBじゃなくて？

**デフォルトの名無しさん** · 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

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

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

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