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

私は最近、Githubでプロジェクトをフォークし、いくつかの変更を加え、それらをフォークされたリポジトリにプッシュし、元の開発者に変更をプルするように依頼しました。（これがGithubでの貢献の好ましい方法だと思います。）プロジェクトはGPLv3の下でライセンスされています。 私は、コードに加えた変更の著者および著作権者です。また、元の著者が設定したライセンスに準拠している限り、変更されたコード（つまり、元のコードと変更をフォークにプッシュして行った変更の組み合わせ）を公開することもできます。 今、GPLで次の要件に遭遇しました。 作品には、あなたがそれを変更したことを示す顕著な通知と、関連する日付を記載する必要があります。 変更をGithubにプッシュすることを法的に許可される前に、実際のコーディング以外の作業が必要なようです。この作業には何が伴いますか？上記の要件を遵守するにはどうすればよいですか？（変更されたソースファイルに追加の著作権表示を追加しますか？Contributorsファイルを作成して追加しますか？またはコミットが所有権を十分に示しているという事実はありますか？）

13 licensing  gpl  github 

今日、GitHubでできる限り多くの時間を費やして（実際に仕事をしているチームの唯一の人でも）、実際の企業アプリケーションにどのようになるかを実際に感じています。 私が持っている1つの質問は、バージョンを制御することです。プロジェクトを始めたとしましょう。次に、チームメンバーはいくつかのブランチを作成し、そこで開発しました。本番の準備ができたら、すべてのブランチをmasterブランチにマージしました。最後に、versionでライブを開始し1.0ます。 現在、そのバージョン1.0は公開されており、そのバージョンのソフトウェアに関していくつかの問題が報告されています。1.1プロジェクトを急いで導入した問題を修正するために、バージョンの開発を開始したいと思います。 さて、質問はこれです： ここでバージョニングをどのように制御する必要がありますか？ 新しいブランチを作成し、そこにソフトウェアv1.0のバージョン1.0を保持し、いくつかのブランチで開発する（またはしない）場合、それらをマージしmaster、バージョンを公開する必要があり1.1ますか？ そのような状況に慣習はありますか？

13 project-management  git  github  svn 

私は初めてGitHubにアップロードしていますが、ライセンスに関するあらゆる疑問に直面しています。トピックがネットで明らかになったことを知りませんでした！しかし、それが複雑であっても、私の状況は非常に典型的であるため、Githubを使用しているほとんどの人はこのことをすでに知っていると思います。 Maven（パッケージとビルドJavaマネージャー）のPOMでサードパーティのライブラリを参照しているアプリを公開してアップロードし、それらを明らかにコードで呼び出したいだけです。それらのいくつかはGPL、他のApache、他の複数のライセンスです... あなたは通常、これらすべてを心配する必要がありますか？バイナリやサードパーティのライブラリを配布したり、修正したり、商業的に使用したりすることはありません...「明示的に言及する必要がありますか？」どのファイルに？自分のライブラリにGPLライセンスを使用する必要がありますか？ インターネット上の情報が文字通りどのようになっているのか不思議に思うのは、Spring、JUnitなどの使用を参照している通知を持っている人を見たことがないということです...

13 licensing  gpl  github 

BitbucketからGitHubに移行していますが、私たちが苦労しているのは、次のようにBitbucketで非常にスムーズに機能するピアコードレビューです。 著者がプルリクエストを開きました（GitHub：同じ） 著者は同僚をレビュアーとして追加しました（GitHub：?? 複数の譲受人とここで苦労しています） レビュアー： 緑のチェックマークが付いたPRを承認しました（GitHub：??） コメントを追加（GitHub：同じ） 軽量タスクを作成しました（GitHub：- [ ]PRの説明で構文が使用されている場合に似ていますが、タスクでは機能しないことが残念です） 一目で確認できるPRのリストがあり、レビューされていてマージしても問題なく、さらに注意が必要なものがあります（GitHub：??） 可能な限りサードパーティのコードレビューツールを避け、何らかの回避策を備えたバニラGitHubを使い続けたいと思います。

12 code-reviews  github  pull-requests 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 私は自分のWebサイト用の不快なコンテンツチェッカーを開発し、それをGitHubで公開したいと考えています。ただし、ソースコードには多くの攻撃的、人種差別的、または不快なコンテンツが含まれています。 ソースは完全に文書化されていますが、GitHubでそのような作品を公開するのが許容できるのか、それとも文字列の配列を読者の想像力に任せるのかについて、あなたの意見が欲しかったのです！

12 github  ethics 

私はオープンソースの世界は初めてです。私が取り組んでいるプロジェクトはGithubにあります。（参照用）私が取り組んでいるプロジェクトは、Plex Media Serverのプラグインです。プラグインをPlexに送信して、それらが「アプリストア」に含まれるようにする予定です。今私の質問に。 私が最初に始めたとき、私は私が望むもののいくつかをしたがあまり良くない古い半放棄されたプラグインを見つけました。私はそのレポに貢献することから始めました。現在の所有者は忙しすぎてそれを台無しにできないと言ったので、私はすぐにレポに対する完全な権利を持つ共同作業者になりました。しかし、コードをさらに掘り下げ始めたとき、それが無駄であることに気付きました。既存のコードベースはひどいものであり、それを修正する効率的な方法はありませんでした。ゼロから始めただけです。新しいプラグインで使用したコードは、最初にコミットしたコードのみでした。 これで、プロジェクトをリリースする準備ができました。しかし、私はこれをどのように行えばよいのかわかりません。次のようにオプションが表示されます。 新しいレポを作成し、既存のものを忘れてください。以前のレポやその貢献者についても言及すべきかどうかはわかりません。そのコード/リソースを使用せず、まったく新しいコードベースを作成しました。プラグインは古いプラグインと同じことをいくつか行いますが、まったく新しい方法でより効率的な方法で行います。 既存のレポをフォークし、既存のコードを削除して、新しいコードをコミットします。私はGitが初めてなので、これが可能かどうかはわかりません。 既存のレポジトリに変更をコミットし、現在の貢献者がどのように言っているかを確認します。 3つの選択肢のうち、最初の方に強く傾倒しています。だが！私はオープンソースが初めてなので、適切なエチケットに従って仕事をしていることを確認したいと思います。私の最初のプロジェクトが目の前で爆発し、災害になりたくありません。オプション2の音は悪くありませんが、それを行うべきかどうかはわかりません。履歴と差分がどのように機能するかわかりません。せいぜい500〜1000行程度のコードです。したがって、それは巨大なコードベースではありません。 あなたが提供できる入力をありがとう！

12 open-source  github  workflows  etiquette 

（GitHubなどのサービスを使用して）オープンソースプロジェクトを管理する場合、次のように対応します。 誰かが新しい機能を追加したり、問題に対処するためのパッチを親切に提出してくれました。次のいずれかの状況が発生します。 ソースコードが1つまたは複数の命名規則などを満たしていません。 ソースコードは特定の方法で改善できると思います。おそらく、はるかに単純なソースで同じ効果を達成できるか、または別の有用な機能が必要になるでしょう。 Q1。提出されたソースを変更することは受け入れられますか？（これはGitHubで可能ですか？） Q2。そのような提出はすべて、提出ガイドラインに従って拒否されるべきですか？ Q3。Q2が「はい」の場合、実装が不十分な、本当にすてきなアイデアはどうでしょうか。先に進んで自分で作成しても構いませんか？ 私は貢献を奨励したいのですが、同時に特定の基準を維持することが重要です。

12 open-source  github 

私は、金融/保険業界の大企業（従業員3万人）で働いています。「IT」は主な焦点ではありませんが、正直に言って、これらは情報主導型の産業であり、技術的優位性のある企業はより早く前進しているようです。 私の会社には多くのソフトウェア開発チームがいます。言語やフレームワークはもちろん、バージョン管理機能を備えたマップ上にあります。何も使用しない（知っている）、PVCSを使用するもの、VSSを使用するもの、SVNを使用するものがあります。 gitを企業に持ち込みたい。具体的には、GitHub（プライベートリポジトリ）を持ち込みます。これについて話すのにふさわしい人は知っていますが、正直言って、このような抜本的な動きは、あいまいなセキュリティの懸念や競合他社がそれを使用していないという事実のために、大企業の環境で通常撃ち落とされます参照としてjQuery、Ruby on Rails、Facebookなどのみを引用してください）。 私の質問はこれです。大企業がPVCS / VSS / SVNからGitHub（プライベートリポジトリ）などのホストされたgitソリューションにゆっくりと慎重に切り替える必要がある理由の最も説得力のある理由は何ですか。もちろん、私の計画の一部には、必須ではない開発プロジェクトのPOCが含まれます。

12 version-control  git  github  enterprise-architecture 

私はGitHubをかなり長い間使用しており、通常は機能ブランチをプッシュしてから、自分でマージしたプルリクエストを開始していました。ブランチをマージした場所を追跡するのに役立つことがわかりました。 しかし最近、Gitの仕組みについてますます読んでおり、マージコミットを使用してブランチをマージするときに参照できることに気付きました。 マスターに機能ブランチをマージするときだから、私は何をすべき： 実行し、マージコミットマスターにして、それが上流押しORローカルブランチを押して、プルリクエストを開始しますか？ 2人のチームのプルリクエストの紹介を読みました-自分のリクエストをマージしますか？そしていただきましたプロジェクトの2人との作業の流れと公式レポや私のフォーク上の枝から万一Iオープンプル要求？しかし、彼らは誰も私が探しているものに答えていないようです。

12 git  github  merging  pull-requests 

背景：私は最近会社で一連のプロジェクトを継承しており、それらの処理方法に関するいくつかの基本的な問題を整理しようとしています。つまり、以前の開発者（もはや会社にいない）は、いかなる形式のソース管理も使用せず、ほとんどドキュメントを作成せず、実際には適切な開発プロセスもありませんでした。 そのため、私は3つのサーバーに相当するプロジェクト（開発、ステージング、プロダクション）を手に入れました。これらは、主にWebサイト、アプリケーション、および使用するサードパーティアプリケーションとAPI用に構築されたツールから成り立っています。私が最初に考えたのは、変更と修正が行われる前にこれらすべてをGitに取り込むことでしたが、それを行う最善の方法を見つけるのは困難です。 これまでの多くの開発は、運用サーバーで直接行われたため、各サーバーのコードベースに格差が生じました。すべての違いがどこにあるのかすぐにはわかりません-開発/ステージングに引き継がれないバグ修正と、ステージング/プロダクションに移行していない開発の新機能が見られます。 質問：これらを整理してGitに移動する最良の方法は何でしょうか？コードの違いに対応するためにレポジトリ/ブランチをどのように構成しますか？ 実稼働サーバーコードのクローンから開発を継続し、開発/ステージングコードベースを履歴参照として保持することを検討しました。とにかく開発/ステージングコードについて何も知らないことを考えると、これは潜在的に最初のポイントになるでしょうか？各Webサイト、ツール、スクリプトセットなどの本番サーバーのリポジトリを作成し、既存の開発/ステージングコードのブランチを作成するだけで、新しい開発は本番サーバーのコードベースから分岐します。これは理にかなっていますか？

11 web-development  git  development-process  github  project-structure 

私は学生のためにコーディングの問題を書く講師です。私がやりたいのは、生徒が完了すべき機能のプレースホルダーを含む定型コードを生徒に与えることです。これを複製するために、学生にプライベートgithubリポジトリへのアクセスを許可します。 ただし、サンプルソリューションを備えたバージョンのコードベースも必要です。明らかに、生徒にソリューションへのアクセス権を与えたくありません（課題が終了するまで）。 私はブランチについて考えましたが、私の知る限り、1つのブランチをプライベートに保つことはできません。 プロジェクトを別のプライベートリポジトリにフォークすることもできますが、プロジェクトをsnycに（ソリューションを含むファイルは別として）保持する方法はわかりません。 この状況のワークフローはありますか？

11 git  github 

GitHubで少なくとも3つのリポジトリを含むプロジェクトを開始しました。 リポジトリの1つは、一般的なドキュメントとサンプルのダンプであり、他の2つのリポジトリには、プロジェクトのバックボーンを形成する2つのプログラムの実装が含まれています。 このような構成を処理するためにGitHub組織を使用する必要がありますか？または、完全に無関係な他の12個のリポジトリとともに、すべてを自分のアカウントにすべてダンプする必要がありますか？

11 git  github  organization  repository 

私はジュニアチームメンバー（生協）にgitを紹介しています。 追加、コミット、プッシュ、プルの基本的な操作に慣れています。 次に、プルリクエストとブランチにそれらを紹介したいと思います。 ブランチでプルリクエストを実行し始めた場合、進行中の作業にも同じことをする必要がありますか？ プルリクエストをマージするのは私です。ブランチで作業するのが最も理にかなっているかどうかはわかりませんでした（通常、私は知っている良い習慣ですが、2人の開発者が1人のジュニアといるこの特定の状況に興味があります）そしてもしそうなら、私は自分のブランチをマスターにマージするだけだということを意味します。とにかく自分の仕事/ブランチのプルリクエストを行うこともできますか？通常、これらの変更には基本的なgithub機能分岐ワークフローを使用します：https : //www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow 私が唯一の開発者である場合、自分のリポジトリでプルリクエストを使用する目的はありますか？便利ですが、それほど具体的ではありません。 プロジェクトに2人での作業の流れはいただきました！また、より一般的なようです そして 公式リポジトリまたは私のフォークのブランチからプルリクエストを開く必要がありますか？フォークについてのようです。

11 git  github  gitflow  pull-requests 

私は適切なブランチの命名について私のリードとの不一致（もちろん、コーディアル）の真っ最中です。これは、バグ修正と小さな機能ブランチに適用され、長時間実行される機能ブランチには適用されません。長期間実行される機能ブランチの場合、人間が読める名前の方が優れていることに同意します。2つの視点があります。 私の： チームとチケット番号に従ってブランチに名前を付けた方が良いです。チケットシステムでそれらを見つけやすくなり、入力が短くなります。また、チケットに関する履歴情報を検索するときに、GITで関連するブランチを簡単に検索できます。 例： team-name/12345 team-name/53719 彼： 機能/機能に従ってブランチに名前を付けます。オートコンプリートが簡単になり、個々の数字より覚えやすくなります。 例： team-name/fix-that-sql-bug team-name/expand-http-parser 私が提供した1つの妥協点は次のとおりです。 team-name/12345-fix-that-sql-bug しかし、GITのオートコンプリートに干渉するため、彼はこれを好みません。 これが主に意見に基づいている場合は、これがどのようにSOに適しているかについてのガイダンスを遠慮なく教えてください。

10 git  naming  github  workflows  branching 

github READMEにどのような情報が表示されると思いますか？ すべてをREADMEに入れますか？すなわち 前書き 取り付け バージョン ユーザーガイド 実装 テスト中 関連資料 または、README（紹介、インストール、バージョン）に特定のものを入れて、他の情報をGithub wikiに配置するのが最適でしょうか。

10 documentation  github