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

私はプログラミングにかなり不慣れであり、私は多くの個人的なプロジェクトに取り組んできました。私が持っているプロジェクトの種類は、Reddit Image Downloaderと、GMがロールプレイングゲームで使用するためのツールです。 選択したデータ分析分野のプロジェクト用にGitHubアカウントの構築を開始したいのですが、GitHubアカウントでプロジェクトを整理する方法がわかりません。主にさまざまな分析スクリプトを含む「プロフェッショナル」なGitHubを作成し、私の小さなプロジェクトのために個別の「個人用」アカウントを作成する必要がありますか？または、私はこれを考えすぎているのですか、1つのアカウントを維持するだけですか？

28 github 

何年もの間、私はオンラインで共有されたものにライセンスを付けて、他の人がそれらを再利用できるかどうか、そしてそれらを再利用できるかどうかを簡単に判断できるようにしました。GitHubがユーザーにリポジトリにLICENSEファイルを含めるように優しく「プッシュ」し始める前は、コード（特にGitHubで公開されているコード）でこれを行う最善の方法を知りませんでした！–しかし、それ以来、LICENSEファイルをうまく利用しようと試みました。 私は現在、いくつかのライセンスについて言及する必要がある（サードパーティのコードとライブラリ、および非コードファイルのために）他の人々と小さなプロジェクトに取り組んでいる状況にあります。私のパートナーはこの問題をかなり「ずさんな」方法で進めていますが、「コードをそのままオンラインに置くだけで、誰も気にしないだろう」と提案されました。問題は、GitHubでいくつかの（異なる）ライセンスについて言及する方法がわからないことです。 GitHubでいくつかの異なるソリューションを見てきました。そのため、このわずかに異なる質問に対する答えが信頼できるものかどうかを判断するのは困難です。私が知りたいのは、次のうちどれが最も一般的であるか、または他の追加の方法がある場合です。 単一のLICENSEファイルを作成し、そこにすべての異なるライセンスの説明を入れます。（質問：それらは特定の順序で配置する必要がありますか？より良い概要のために、含まれるすべてのライセンスの名前を記載してファイルから始めますか？） 作成したライセンスごとに1つのライセンスファイルを使用し、それらに名前を付けLICENSE.md、LICENSE.LibNameA.md、LICENSE.AssetsB.mdなどのリンクの答えで提案されているように。（質問：命名はプロジェクト名に基づきますか？ライセンス名ではありませんか？自己投稿素材に複数のライセンスを使用した場合、それらをすべて「メイン」で言及しLICENSE.mdますか？そうでない場合、代わりに何をしますか？） 2つのLICENSEファイルを作成します。1つは「メイン」コンテンツのライセンスをリストします。つまり、自分で作成したすべてのコード/アセット。1つはすべてのサードパーティの資料用です。（上記の質問：使用する特定の命名スキームと、サードパーティの資料をリストする順序はありますか？） 最後に、License APIに関するさまざまなGitHubの説明とプロジェクトを正しく理解していれば、レポのライセンスを決定するときに「メイン」のLICENSEファイルのみが考慮されます（どのライセンスが選択されるかはわかりませんが）いくつか言及された場合）。

28 licensing  github 

そのフォーマットが何であるか、それを作成するための体系的/コマンドライン要件があるかどうかなど、私にはわかりません 基本的に、仕様を知る必要がある場合、およびREADMEファイルを生成するための技術的な手順がある場合。

27 github 

私は比較的人気のあるgithubリポジトリを維持しています。 プルリクエストがマージに適している場合、通常、マージする前に作成者に単一のコミットにリベースするように依頼します（特に複数の小さな編集がある場合）。 これは良いGitプラクティスですか？これは許容できる/標準のGitHubエチケットですか？ いくつかの利点： コミットログにきれいなコミット履歴があります 自分でコミットを変更する必要はありません 作業の一部を委任します 考えられる欠点： これが良いエチケットかどうかわかりません これが良いGitプラクティスかどうかわかりません 私は通常、すでにいくつかの他の変更を求めています-これはもう1つであり、貢献者を落胆させたくありません。

25 github  etiquette 

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

25 github  etiquette  forking 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 今まで、Git / Githubの基本的な概念のほとんどを理解していましたが、全体像を理解するのはまだ困難です。 これらは私がこれまでに何とか作業を始めたものです。 コミットをプッシュする ブランチで作業する Githubを継続的な統合システムであるTravis CIと統合する Travis CIを介して、マスターへのコミットごとに自動的にビルドし、リリースをGithubのリリースとしてZIPとしてリリースします。 しかし、私はこれまでにプロジェクトのアルファ版またはベータ版にしか取り組んでいなかったため、実際にバージョン付きリリースを見たことはありません。 したがって、バージョン管理、個別のバージョンの維持、バージョンの修正プログラムなどについて詳しく知りたいと思います。 次のことが起こるようにするにはどうすればよいですか： 私のプロジェクトの異なるバージョン、たとえばバージョン1.1.0と2.0.0を持っている バージョンの修正プログラムをプッシュしたり、バージョンを1.1.1や2.0.1に変更したりすることができます。 継続的統合システムがコミット時にそのバージョンを自動的にビルドし、成功した場合は、その特定のバージョンのリリースを公開します。 私は次のオプションの間で疑っています： バージョンごとにタグを使用する必要がありますか？もしそうなら、継続的インテグレーションシステムはどのようにしてリリースを自動的にビルドできますか？ バージョンごとにブランチを作成する必要がありますか？もしそうなら、それはたくさんのブランチを作成しませんか（1.1や2.0ブランチのように、もちろんホットフィックスはそのブランチに行きます） バージョン番号はどのように指定しますか？バージョン番号を指定する構成ファイルを用意しても大丈夫ですか、それとももっと賢い方法がありますか？この場合、それが重要であれば、Javaプロジェクトになります。

24 version-control  git  github  continuous-integration 

RubyとPHPコードを含むリポジトリがあります。 Githubによると、私のレポはPHP 74.8％、Ruby 25.2％です 私はこれがどのようになり得るか理解していません。プロジェクトの2つの言語を比較すると： # Count how many files: # Ruby ls | grep ".*\.rb" | wc -l # returns 10 #PHP ls | grep ".*\.php" | wc -l # returns 1 # Count how many lines, words, chars: # Ruby cat *.rb | wc # returns 229, 812, …

24 github 

パブリックリポジトリを備えたオープンソースプロジェクトは、安全に報告されているがまだ公開されていないセキュリティ脆弱性に対処するプルリクエスト（PR）を最適に処理する必要がありますか？ 私は数百人の貢献者によるオープンソースプロジェクトに関与しています。定期的に予定されている月次リリースの一環として、セキュリティ通知と脆弱性を年に数回公開しています。パッチを適用したバージョンを公開するまで、脆弱性に関する情報は公開しません。プロジェクト管理システム（JIRA）でセキュリティの問題を安全に管理できます。しかし、セキュリティの脆弱性がGitHubに提出されるときに修正するPRを隠すための良いプロセスがありません。私たちは、人々がリリースされる前にこれらの修正を見つけて、ゼロデイエクスプロイトを作成できることを心配しています。 メインリポジトリをフォークするプライベートリポジトリの使用を検討しましたが、現在のレビューとQAワークフローの多くはPRで行われます。ワークフローをセキュリティチームのみのプライベートリポジトリに移動した場合、修正が公開されている場合、tarballを生成してsourceforgeで公開するのにかかる時間までウィンドウが短くなり、大幅に改善されます。また、PRを公開ベータ版にマージすることを避ける必要があるかもしれません。 その方向に進む前に、オープンリポジトリを使用したオープンソースプロジェクトでリリース前のセキュリティバグ修正パッチを処理するためのベストプラクティスを教えてください。GitHubとは異なるプラットフォームを使用することで問題に対処できる場合は、GitLabへの移行を評価していることに言及する必要があります。

22 open-source  security  github  gitlab 

私たちはプロジェクトでGitHub Flowを使用し、ほとんどの場合、masterから新しい機能ブランチを開き、そこで作業を行い、PRを開き、コードを確認してmasterにマージします。 しかし、私の現在の仕事はで取り組んでいる別の問題に依存していfeature-branch-Aます。他のブランチからブランチを作成するのはコーシャーですか、それともGitHub Flowの精神に反するものですか？ 別の方法は、私のブランチをマスターに基づいて、feature-branch-A（頻繁に）変更をマージすることです。 GitHubフローではどのオプションが推奨されますか？

22 git  github  gitflow 

たとえば、次のヨーマン。BSDライセンスの下でライセンスされています。CLAフォーム（コントリビュータライセンス契約）は、プロジェクト固有のものではない、それは電子的に署名することができます。 この契約をサインアウトすると、どのような問題を防ぐことができますか？ 私がどれだけ大きな貢献をしたか、小さな貢献をしたかは重要ですか？ なぜパッチを受け入れるのに署名付きCLAを必要とするプロジェクトとそうでないプロジェクトがあるのですか？（例：node.js対rails）

22 open-source  licensing  github 

私はGitHubとVCS全般に不慣れです。私は何年もさまざまな言語でプログラミングを行ってきましたが、カスタムプロジェクトでは常に単独で作業していました（公開リリースはありません）。最近、作業中のプロジェクトでGitHubからダウンロードしたjQuery UIウィジェットの使用を開始しました。リポジトリは元の作成者によって維持されなくなりました。別のフォークには、元のプルリクエストの一部が組み込まれています。これは私がフォークしたものです。 いくつかのバグを発見し、それらの修正を考え出しました。私はこれらの修正に貢献したいと思いますが、私たち自身の使用のために、既存の機能のいくつかを破壊する他の多くの変更もしたいと思います。さらに、別のフォークのアイデアを取り入れたいと思います。 私はまだGITとGitHubを学んでおり、あらゆることを行うための最善の方法を見つけようとしています。さまざまな概念/タスク（ワークフロー、マージ、プルリクエスト、チェリーピッキング、リベース、ブランチ）について多くの読書（ここでは、SO、GitHubヘルプページ、Pro Git）を行いました。私の灰白質は泳いでいるので、読み始めたことを理解するために、始めなければなりません。 主な問題： 私は（どこかに）一度にブランチ上でプルリクエストを1つしか持つことができないと読んだと思います。つまり、バグごとに個別のブランチを作成し、それぞれに個別のプルリクエストを実行する必要があるということですか？ 空白の問題をクリーンアップしたいのですが、これを別のコミットで行うのが最善であると読んだことを覚えているようです。これをマスターまたは別のブランチで行う必要がありますか？些細なことに対してプルリクエストをしたくありませんが、ブランチする前に空白を変更すると、バグ修正のためのプルリクエストに影響しますか？一部のフォークは空白のクリーンアップを行い、事実上、diffをかなり役に立たなくしました。 私はすでにバグを修正しているにもかかわらず、バグを文書化する方法として、フォークに対して問題を作成することを考えていました。それは良い考えですか？問題、コミット、およびマスターへのマージをリンクするにはどうすればよいですか？アップストリームでプルリクエストを行うと、問題もアップストリームに表示されますか、それともドキュメントのリンクが失われますか？アップストリームリポジトリに対して問題を開くことができません（[問題]タブはありません）。 私が使用したい他のフォーク作成者のアイデアを他のフォーク作成者に与える最良の方法は何ですか？特に彼の変更はアップストリームの古いバージョンに対して適用され、他の変更とは互換性がないため、私は彼のコードを正確に使用することはできません。しかし、私はこのアイデアを使いたいですし、クレジットが支払われるべきところでクレジットを与えたいです。コミットメッセージで彼のレポ（またはプロファイルまたは特定のコミット）にリンクするだけですか？ メインファイルの上部にあるREADMEファイルとDocBlockの変更に関するエチケットは何ですか？変更を行い、名前を追加し、リポジトリとデモへのリンクを追加し、元のデモへのリンクを削除しても構いません（私のフォークは元のデモと互換性がないため）もちろん、元の著者名とライセンス情報は残しておきます。記録のために、それはMITライセンスの下でライセンスされています。 VCSを使用したことがないソロ開発者として、私はhistoryを書き換えることに慣れています。私は完璧主義者で、きちんと整理整頓することが好きです。歴史を記録するという考えは私を少し緊張させています。プレイ/学習するための新しいリポジトリを作成しましたが、jQuery UIウィジェットの修正を進めて、プロジェクトを進めることができるようになりたいと思っています。

21 open-source  github  workflows  etiquette 

私はGitHub for Windowsを介して Gitと対話していますが、これはリポジトリをGitHubにプッシュすることは決してないので面白いです。私はそれだけで取り組んでおり、私だけが使用することを意図しています。コミットが「非同期コミット」の下にリストされ、「履歴」の下に「コミットなし」と表示されていることに気付きました。「履歴」の下にリストされているコミットを除いてプッシュすることで何を達成できますか？

21 git  github 

この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私たちは現在Subversionを使用しているWeb開発者の小さなチームですが、まもなくgithubに切り替えます。 私はさまざまなタイプのgithubワークフローを検討していますが、各開発者向けのgithubのフォーク概念全体がこのような良いアイデアであるかどうかはわかりません。 フォークを使用する場合、各開発者は独自のリモートおよびローカルリポジトリを持つことになります。変更セットをプッシュするのが難しく複雑になりすぎるのではないかと心配しています。また、私の最大の懸念は、各開発者に2つのリモートを強制することです：オリジン（リモートフォーク）とアップストリーム（メインリポジトリからの変更を「同期」するために使用）。それが物事を行うためのそのような簡単な方法であるかどうかはわかりません。 これは、ここで説明されているワークフローに似ています：https : //github.com/usm-data-analysis/usm-data-analysis.github.com/wiki/Git-workflow フォークを使用しない場合は、作業中のタスクごとにブランチを作成する中央リポジトリを使用して同じリポジトリの開発ブランチにマージすることで、おそらくうまくいくでしょう。つまり、ブランチのマージを制限することができず、中央リポジトリに多くのブランチを置くのは少し面倒かもしれません。 両方のワークフローを試したチームからの提案はありますか？

21 git  github 

私は非常に頻繁にプロジェクトのいくつかの機能に取り組んでおり、コミットするのに十分である前に休憩を取る必要があります。しかし、私は毎日2台の異なるコンピューターを使用してコーディングしています（ラップトップと研究室のデスクトップ）。例：自宅で機能の作業をしているときに、停止してラボに移動します。 クラウドの同期（Dropboxなど）とGitHubリモートトラッキングを混在させたくありません。 作業を続行するために他のコンピューターにコードを引っ張る目的でのみ、以前にコードの未完成（および乱雑な）状態をコミット（およびプッシュ）しました。これは悪い習慣だと確信しています。 しかし、今日は、git stashグーグルで少し見つけました。それは私が必要なものに対する完璧な解決策のようです。 ただし、ドキュメントに、変更をプッシュした後にgithubに移動するかどうかは記載されていません。それに加えて、必要なモビリティを達成するためのより効率的な方法があるかどうかを知りたいです。 前もって感謝します！

20 git  github  gitflow 

私は、最近のiOSプロジェクトの一部として開発した1組のライブラリを、他のiOS開発者が自由に利用できるようにする計画で、GitHubアカウントを設定しています。 現在、ほとんどのコードのオフサイトバックアップはありません。そのため、当初、私はすべての個人プロジェクト、または少なくともすべてのiOSプロジェクトをGitHubがホストするプライベートリポジトリにアップロードすると考えていました。 。しかし、私は多くのプロジェクトを抱えており、その多くはかなり価値の低いものです（つまり、本を改造して学習体験のために書いたものです）。GitHubはプライベートリポジトリによって課金されるだけでなく、リポジトリを階層的に整理する方法もありません。 私が不足しているものがあり、階層でgitリポジトリを使用し、必要なときにそれらをチェックアウトしたり、現在SVNで行っている方法で作業したりできますか？ GitHub（またはBitBucketのような競合他社）には、プロジェクト構成の機能がいくつか欠けていますか？ それに失敗すると、この状況を処理する一般的に受け入れられている「Gitの方法」は何ですか（リリースを目的としていないプロジェクトを破棄し、オフラインで保存し、何らかの方法で一緒にバンドルするなど）。 私が知る限り、私のオプションは次のとおりです。 ライブラリをGitHubに配置し、他のすべてのプロジェクトで自分のSVNをホストし続け、オフサイトバックアップ（非難）に非VCSソリューションを使用し、 私がリリースする予定のライブラリとソフトウェアをGitHubに（それぞれパブリックおよびプライベートとして）入れ、あまり気にしないプロジェクトのために自分のSVNをホストし続け、XYZの実装方法に関する記憶を更新するために再訪する可能性が高い私の家が破裂した場合（二重の荒れ）、それらを消しても構わないと決めます。 [GitHubおよび/またはBitBucket]にすべてを配置し、必要なものを検索するか、[GitHubおよび/またはBitBucket]アカウントへのオフラインポインターセットを維持することで、途方もない数のリポジトリを持つことに対処する（トリプルブレチ）

20 version-control  git  github