タグ付けされた質問 「forking」

ここで最近報告されたように： Xamarinは、2D / 3Dゲーム開発フレームワークであるCocos2D-XNAを分岐させ、PCLプロジェクトに含めることができるクロスプラットフォームライブラリを作成しました。 ただし、分岐したプロジェクトの創設者は次のように述べています。 MITライセンスの目的は、公正使用を妨げないことです。あなたが言うように、ソフトウェアを自分のものとしてブランド変更し、それから「新しい方向に持って行く」ことを奨励しないでください。 違法ではありませんが、非倫理的です。 新しいプロジェクトのGitHub ページでは、それが典型的なGitHubのようにフォークであることさえ示していないようで、代わりに簡単に取り外し可能な履歴セクションを選択しています（下を参照）。 だから私の質問は： Xamarinのアクションとアクションの実行方法は倫理的でしたか？ あなたが独身の開発者または小さな資金のない開発者グループである場合、そのような状況を避けることは可能ですか？ これがwikiの質問になるか、現代のOSS倫理/哲学に基づいた客観的な答えがあることを望んでいます。

119 open-source  ethics  mit-license  philosophy  forking 

多くのGitHubアカウントには、他のアカウントから分岐されたリポジトリしかありません。さらに、これを行う人々は通常、フォークされたリポジトリに貢献しません。 切手や貝殻を収集する人のことを聞いたことがありますが、なぜリポジトリを収集したいのでしょうか？個人的には、リポジトリに変更を加えたい場合にのみ、リポジトリをフォークします。

110 github  repository  forking 

以前に他の人のリポジトリをGitHubでフォークしましたが、元のリポジトリに問題が残ることに気付き、フォークしたリポジトリで問題を提出できないことに気付きました。 現在、次のタスクがあります。私は、彼の個人アカウントのプリンシパルの1人によって開発が行われている中小企業で働いています。彼は友好的にプロジェクトを去りました。そのプロジェクトを彼の個人アカウントからGitHubの新しい「ロール」アカウントに移行したいと思います。 コード履歴を保存するためにレポジトリを自然にフォークしますが、新しい問題を提出できないレポジトリになりますが、これは非常に望ましくありません。 この元のリポジトリのコピーを新しいアカウントにコピーして、理想的にはコード履歴を保持しながら、この新しいアカウント内で新しい問題を提出する方法はありますか？

109 issue-tracking  github  forking 

チームとコミュニティで開発されるソフトウェアプロジェクトを開始しています。以前はgerritで販売されていましたが、今ではGithubのフォークおよびプルリクエストモデルは、より多くのツール、コミットを視覚化する方法、および使いやすさをほぼ提供しているようです。 両方について少なくとも少し経験がある人にとって、それぞれの長所と短所は何ですか？コミュニティ開発の可能性を残したいチームベースのプロジェクトにはどちらが良いでしょうか？

64 git  github  forking  gerrit 

GithubでTestNG javaテストフレームワーク（Apache 2ライセンス）をフォークして、必要に応じていくつかのマイナーなものを追加/変更できるようにします。 私の変更がすべてメインプロジェクトで承認されることや、他の人が私のフォークを使用することはまずありません。これは決してメインプロジェクトとの競争にはなりません。 ここで、命名の観点から、アーティファクト名（testng-mycompany）またはバージョン（6.8.mycompany）を変更して、mavenリポジトリーの公式バージョンと混同しないようにします。これは悪いエチケットと見なされますか？はいの場合、フォークを区別するための最良のアプローチは何ですか？

29 open-source  github  etiquette  forking 

時間です。 あなたは、あなたが愛しているオープンソースプロジェクトにあなたのビジョンを追加するために長く一生懸命働いてきました。 しかし、既存の開発者とはうまくいきません。 最後に、コードをフォークする必要があります。 これをどのように行い、既存のプロジェクトで可能な限り最高の条件を維持しますか？「ああ、そうですか、フォーク！」と言わないでください。 クロスポリネーションのメカニズムおよび分岐の理由が健全で、論理的で、許容できると仮定する以外に、どのような問題が発生しますか？ コンペ？リソースのサッピング？ユーザーの密猟？ これらがもはや問題と見なされなくなるほど十分に多様化するまで、この間違いなく困難で長いプロセスをどのように経ますか？ 決定の背後にある理由を議論するのではなく、コードの分岐が最良の全体的な解決策であるとすでに確信していると仮定してください。そして今、ポイントは可能な限り最善の方法で前進することです。 -アダム

27 open-source  forking 

Githubには、私が主に好きで使いたいプロジェクトがあります。私が望んでいる/必要なものに意味をなさない、異なる方法で/削除したいことがいくつかあります。また、いくつかのことも追加したいと思います。 私はそれを理解しているので、プロジェクトを分岐する必要があり、必要な変更を加えて、分岐に戻すことができます。そこから元のプロジェクトからの変更をフォークに時々取り込みたいので、最新のバグ修正/機能を入手します。 私はそれがどのように動作するはずだと思うかについて、オフベースですか？元のプロジェクトからの変更をどのように取り入れますか？

25 github  etiquette  forking 

2つのバージョンを持つゲームプロジェクトがあります。 ゲームのシンプルなバージョン、コア。 ゲームの高度なバージョン。 私は自分の公開リポジトリに最初のバージョンがあり、私だけがそれに取り組んでいます。2番目のバージョンについては、私の2人の友人と私がそれに取り組みます。重要な部分は、2つのバージョンをリポジトリに残すことです。 私はこれにブランチを使用するかもしれないと考えましたが、この質問とその答えを考慮すると、バージョン管理の観点からそうするのは良い習慣ではありません。私が知る限り、自分のリポジトリをフォークすることはできません。 ここで私のオプションは何ですか？リポジトリに両方のバージョンを保持するにはどうすればよいですか？

17 git  github  branching  forking 

私は現在プロジェクトに取り組んでおり、Githubのプライベートリポジトリにソースコードがあり、私たちはそれぞれ共同作業者です。 不明な点は、各作業を分離する方法です。 私たちがする必要があると思うことは： リポジトリをフォークする必要があります コードをプッシュする準備ができたら、プルリクエストをプロジェクトリーダーのレポジトリに送信します。レポジトリは、これを同時にコードレビューを行う機会として使用できます プライベートリポジトリに関しては、これはフォークを使用することになっているのでしょうか、それとも状況を複雑にしすぎていますか？

14 project-management  git  workflows  forking 

私はこのGPLプロジェクトを持っています、それは1年ほど行き詰まりました、私はアイデアが本当に好きです、そして誰かがそれを分岐させ、同じ名前を使用しましたが、コードを気にしません（結局GPLでした）しかし、私は名前が好きです。この種の状況のエチケットは何ですか？ このプロジェクトは自分自身に利益をもたらすでしょう。私は気に入っていますが、その名前は売り物ではありませんでした。 編集：著者に連絡して名前を理解して変更するかどうかはわかりますが、今はそのプロジェクトに取り組む時間がないので、私は人々の「名前トロール」になりたくないです（小さなコミュニティ）、私はそれを今回にします、私の質問はフォークのエチケットについてです。プロジェクトが明らかに放棄された場合、彼らはフォークして同じ名前を使用できますか、または新しい名前を取得する必要がありますか？

13 open-source  etiquette  forking 

分岐コードを回転させる適切なベストプラクティスについて質問があります。 Creative Commons Attribution-NonCommercial-ShareAlike 3.0の下でライセンスされたコードベースを取得し、私のニーズに合わせて大幅な変更を加えました。私のバージョンは他の人に利益をもたらし、再配布したいと思っています。 再配布に関してどのような自由があるのか​​、またはどのような許容範囲があるのか​​はわかりません。プロジェクトの名前を変更できますか？新しいv.1を開始するか、元のバージョン番号から続行する必要がありますか？元の著者に適切な帰属を与えると考えられるものは何ですか？リリースする前に著者に相談し、許可を求める必要があります（ただし、彼は既に認識しています）。

13 open-source  forking  creative-commons 

2節のBSDライセンスでリリースされたプロジェクトをフォークすることに興味があります。 Copyright（c）2010 {著作権者}無断転載を禁じます。 以下の条件が満たされている場合に限り、変更の有無にかかわらず、ソースおよびバイナリ形式での再配布および使用が許可されます。 （1）ソースコードの再配布では、上記の著作権表示、この条件のリスト、および最後の免責事項を保持する必要があります。バイナリ形式で再配布する場合は、上記の著作権表示、この条件のリスト、および次の免責事項を、配布物とともに提供されるドキュメントやその他の資料に複製する必要があります。 （2）{著作権者}の名前またはその寄稿者の名前は、特定の事前の書面による許可なしに、このソフトウェアから派生した製品を推奨または宣伝するために使用することはできません。 免責事項 このソフトウェアは、著作権者および寄稿者によって「現状のまま」提供され、商品性および特定の目的に対する適合性の黙示の保証を含むがこれに限定されない、明示または黙示の保証は否認されます。いかなる場合も、著作権者または寄稿者は、直接的、間接的、偶発的、特別、例示的、または派生的な損害（代替商品またはサービスの購入、使用、データ、または利益の損失を含むが、これらに限定されない）に対して責任を負わないものとします。またはビジネスの中断）責任の理論にかかわらず、契約、厳格責任、または不法行為（過失またはその他の場合を含む）にかかわらず、このソフトウェアの使用のいかなる方法においても、その問題の助言があったとしても これまでにプロジェクトをforkしたことはありませんが、このプロジェクトは、私が必要とするものと非常に似ています。ただし、どこまで到達できるかは不明なので、最新のものをリポジトリから取得して作業を開始する予定です。たぶん、最終的には、私が望んでいる場所に到達し、リリースできるようになるでしょう。これは正しいアプローチですか？ 正確には、これはプロジェクトの分岐にどのように影響しますか？どのコンポーネントまたはセクションを誰が所有しているかを追跡するにはどうすればよいですか（私が著作権を所有している、元の作成者がコードベースを踏み始めたら、著作権を所有している）。このプロジェクトをフォークできますか？リリースする前に何をする必要がありますか。また、いつこのBSDライセンスの作品から派生したソフトウェアをリリースすることにしたのですか？

9 open-source  licensing  bsd-license  forking 

これは（他の人のオープンソースプロジェクトをフォークするためのネチケットとは何ですか？）の直接の複製ですが、そこに自分の答えが見つからず、コメントできません（まだ十分な評判がないため）。 これが私のシナリオです。 私はGitHubプロジェクト（https://github.com/fengyuanchen/cropper）の公開フォークを持っています。オリジンにいくつかの修正を加えました（低メモリデバイスでのキャンバスレンダリングの制限の回避など）が、ソフトウェアに必要な次のような機能も追加しました。 viewMode: 4：画像が回転すると、画像全体が常にコンテナ内に表示されるように拡大縮小されます。また、cropBoxは、キャンバスだけでなく、常に画像内に制約されます。 getCroppedCanvas タイリング：切り抜かれた画像をキャンバスにタイリング（たとえば、マトリックススタイルを複製）する機能。 ただし、元の作成者は、元のプラグインをできるだけ単純にしたいと考えているため、この新しい機能にマージしたくありません。 私は交渉と交渉を試みましたが、ちょうど無視されています。 それで、私はこの公開フォークを維持し続けるという事実に自分を辞任しました。理想的ではありませんが、他の機能が本当に必要です。だから私たちはあります。 元のライセンスはMITライセンスであり、次のように宣言されています。 The MIT License (MIT) Copyright (c) 2014-2016 Fengyuan Chen and contributors Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without …

8 open-source  forking 

これがGithubの典型的なワークフローです... いくつかのプロジェクトのように->それをフォークし-> git clone https://github.com/you/someprojectます。 プロジェクトを開きます。あなたが見るものに似ていますが、いくつか変更を加えます。 feature-branch（git checkout -b some-feature）でのみ機能するように注意して、Githubフォークにupstreamプッシュした後、メンテナーにプルリクエストを出すことにしましたfeature-branch。 メンテナは、何らかの理由でプルを拒否します。 たとえば、上記のシナリオに一致する、失敗したプルリクエストは次のとおりです。.. 今一般的にメンテナ場合、HADがマージプル...ワークフローがシンプルになります...私のローカルマシン上で、私は何でも上の任意のローカルの変更コミットするだろうfeature-branch、私は一度にあったし... git fetch --all、git checkout master、git pull upstream --ff-only。次に、必要に応じて、その上で変更を再生します... だが... 私のフォークへの変更を無理なく続けていきたいと決心した場合はどうなりますかupstream？それでも、発生した変更を追跡してマージできるようにしたいですか？通常、私はあなたが維持することができますどのように..機能ブランチを削除して、自分の道に行くとmaster、マージされた上流ことすることができ、まだから「永久に切り離さ」されながら、あなたのフォークの機能を維持し、分岐upstreamのをHEAD？

8 open-source  git  workflows  forking  etiquette