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

だから私は他の誰かのリポジトリをフォークし、いくつかの変更を行い、プルリクエストを送信し、私の変更がそれを製品に加えました。すばらしいです！ しかし...フォークされたリポジトリをどうすればよいですか？リポジトリを保持する理由はありますか、それとも削除してください。私は追加の貢献をするつもりはありませんが、気が変わったらいつでもそれを再分岐できると思います。 バックアップを保持することはあまり気にしません。リンクの切断、コミットメッセージの消失などが心配です。

314 github 

バージョン管理としてGitとGithubを使用する分散チームの場合、画像もgitリポジトリに保存する必要がありますか？ ほとんどの場合、画像は変更されません。それらを含むフォルダーは、画像が追加されるとサイズが大きくなります。懸念事項は、大きな画像の組み合わせ、またはそれらの多くだけで、画像フォルダが時間とともに大きくなる可能性があることです。 これはベストプラクティスと見なされますか？分散チームが簡単にアクセスできるプロジェクトで必要なバイナリファイルを共有するために、他にどのような方法がありますか？

201 version-control  git  github 

プルリクエストを行うすべての深刻なGithubリポジトリが、コミットを1つのコミットにまとめるように要求するのはなぜですか？ gitログがあると思ったので、すべての履歴を調べて、どこでどのような変更が発生したかを正確に確認できますが、それを潰すと履歴から引き出され、すべてが1つのコミットにまとめられます。ポイントは？ これは「早期にコミットし、頻繁にコミットする」というマントラにも反するようです。

200 git  github  branching  pull-requests  etiquette 

現在、共有リポジトリにPHPアプリケーションのマスターブランチが1つあります。当社のソフトウェアの加入者であるクライアントは500人を超えており、そのほとんどが異なる目的のために、それぞれ個別のブランチにカスタマイズされています。カスタマイズは、異なるテキストフィールド名、まったく新しい機能またはモジュール、またはデータベース内の新しいテーブル/列にすることができます。 私たちが直面する課題は、これらの数百のカスタマイズされたブランチを維持し、クライアントに配布する際に、時々新しい機能を提供し、マスターブランチを更新し、更新するためにマスターブランチの変更をカスタムブランチにプッシュすることですそれらを最新バージョンに。 残念ながら、これによりカスタムコードで多くの競合が発生することが多く、すべての競合を解決するためにすべてのブランチを何時間も費やしています。これは非常に非効率的であり、これらの競合を解決する際に間違いは珍しくありません。 クライアントブランチをマスターブランチに合わせて最新の状態に保ち、マージ中の労力を軽減するより効率的な方法を探しています。

140 version-control  git  github  versioning  branching 

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

110 github  repository  forking 

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

109 issue-tracking  github  forking 

会社のすべてのGitリポジトリをGitHubに移動しました。次に、プロジェクトに従業員を追加します。ほとんどの従業員はすでに個人的なGitHubアカウントを持っているので、仕事用の GitHubアカウントを作成するように依頼する必要があるのか​​と思っています。私がこれを行うことを考えている理由は、コードベースへの不正アクセスの可能性を減らすためです。なぜなら、彼らの個人アカウントはサイトでの個人活動を通じて十分に公表され、標的型攻撃の可能性が高まるからです。さらに、個人アカウントが危険にさらされたとしても、ハイジャック犯が会社コード全体にアクセスできるということにはなりません。これは従業員のために2つのアカウントを維持する負担をもたらすので、それが正しいアプローチであるかどうか、そしてそれが理にかなっているかどうか疑問に思っています。 更新 すべての有用な洞察力をありがとう。質問/回答の主観的な性質のため、またいくつかの異なる回答から最高のポイントを取得したため、回答を受け入れられたものとして設定しません。 この方法で進むことにしました。実際の理由から、仕事関連のGitHub電子メール通知を仕事用電子メールアカウントに送信する必要があることを従業員に思い出させます。したがって、作業用のGitHubアカウントを作成する方が理にかなっています。個人のGitHubアカウントを使用して仕事用の電子メールアカウントに接続する場合は、それで問題ありません。とにかく、従業員は書面でGitHubの使用に関連するいくつかの条件に同意する必要があります。これらはアカウントのセキュリティに関連しています：他のアカウントで使用されていない安全なランダムパスワードジェネレーターを使用して安全なパスワードを選択する、所有または管理されていないコンピューターを介してGitHubにアクセスしない、など。仕事のアカウントが彼らにとってより意味があるかどうかを自分で決めます。

91 github 

GitHubがMacとWindowsの両方にGUIアプリを提供しているとすると、コマンドラインからgitを使用することを学ぶことの利点は何ですか？ 現在、Macアプリを使用してリポジトリを更新していますが、これまでのところ私のニーズを満たしているようです。何を見逃しているのでしょうか？

84 git  github 

GitHubで人気のあるプロジェクトを最近見ていると、developブランチがないことがわかりました。実際、GitHub Flowガイドでも言及されていません。私の理解から、master常に完全に安定し、生産を反映する必要があります。開発者が機能ブランチに取り組んでいてmaster、それらが完了したらそれらをマージする場合、機能/修正がマージされmaster、masterブランチが実際に本番よりも新しい期間があることを意味します。 チームが機能/修正ブランチを作成developし、そこにマージして、次のバージョンが完全にリリースの準備ができたら、developマージされmasterてタグが作成されるのはより理にかなっていますか？人々がに直接マージされmaster、masterブランチのコードベースが大幅に変更されたために修正が困難になるバグが本番環境で報告されていると想像してください。その後、開発者はユーザーに次のリリースまで問題を解決するまで待つように指示するだけです。 編集：この質問は「分岐するかしないか」とは異なります。特に、developブランチの使用から遠ざかる人々と、それを取り巻く理由を扱っています。これは、長い間ベストプラクティスとして宣伝されていたためです。

82 git  github 

私の履歴書はもはや関係ありません。技術的な能力の適切な説明を含めることはできなくなりました。GitHubリポジトリ、Stack Exchangeプロファイル、およびUdacityとCourseraで受講しているさまざまなコースを見ると、自分が何ができるかをよりよく理解できます。問題は、私ができることの正確な説明が必要な場合に、それらを探す場所であることを雇用者に伝える方法がわからないことです。 リクルーターが私に連絡するたびに、私は先ほど述べたすべてのリソースにそっとそれらを押し付けます。また、公開されているGoogleドキュメントへのリンクを提供します。それでも、彼らはより説明的な履歴書を求めて戻ってきます。 誰かが私を雇いたいのなら、いくつかのリンクをクリックして閲覧するだけで多くのトラブルを自分で救うことができるということを、もっと露骨に明らかにすることができますか？

80 interview  github  resume 

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

64 git  github  forking  gerrit 

MITプロジェクトをフォークし、大幅に変更して名前を変更する場合、メインライセンスファイルのMITライセンスの上にある著作権表示をどのように処理しますか。元の著者と私の会社、または元の著者のみをリストしますか？原作者の帰属に関する法的選択肢は何ですか？私もMITでソフトウェアのライセンスを取得し、オープンソースのままにしておきます。

62 open-source  git  github  mit-license 

Gitには複数のプロジェクトがあり、それらを最終的に他の人に紹介したいと思っています。ただし、現在は私だけで、GitとGitHubを非常に単純に使用しています。ブランチはなく、基本的にコミットをローカルファイルのバックアップとして使用しています。時々、以前のバージョンのファイルを参照して参照することもありますが、この時点までロールバックする必要はありませんが、将来必要になる場合はオプションを高く評価します。 唯一の開発者として、現在利用できるGitまたはGitHubの機能は何ですか？私のワークフローはどのようなものですか？ また、今後プロジェクトに他の人を追加することを見越して、始める必要がある特定のプラクティスはありますか？

60 git  github  solo-development 

GitはGPLv2の下でライセンスされているので、私の理解では、GitHubはGitと対話します。GitHubコードベース全体をGPL互換ライセンスでオープンソース化すべきではありませんか？

58 licensing  git  gpl  github 

オープンソースコミュニティの多くの人々は、採用時に候補者のGithubプロファイルを強く検討すると言います。 私はGithubで積極的に活動しており、私自身のプロジェクトと他のプロジェクトへの貢献がいくつかあります。しかし、自分が雇用主であるかのように自分のプロファイルを見ると、クローンを作成したが貢献したことのないプロジェクトなど、多くのノイズが見えます。誇りに思っているプロジェクトやパッチは目立ちません。 人々のGithubプロファイルを評価する場合、どのように行いますか？そして、開発者として、何か別のことをする必要がありますか-例えば、私が積極的に取り組んでいないクローンリポジトリを削除しますか？

54 open-source  github