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

これは少し奇妙に聞こえるかもしれませんが、何らかの方法でネットワーク接続された複数のマシンからGitで作業する良い方法について疑問に思っています。私には2つの選択肢があるように見えますが、両方の利点があります： 共有にはgit自体を使用します。各マシンには独自のリポジトリがあり、それらの間でフェッチする必要があります。 他のマシンがオフラインであっても、どちらのマシンでも作業できます。これ自体はかなり大きいと思います。 マシン間のネットワークで共有される1つのリポジトリを使用します。 コードは常に最新であるため、マシンを切り替えるたびにgit pullを実行する必要はありません。 このマシンでファイル共有を使用して作業を行っていたため、他の非ホスティングマシンからコードをプッシュするのを忘れたことを心配しないでください。 私の直感では、一般的に誰もが最初のオプションを選択します。しかし、私が見る欠点は、常に他のマシンからコードにアクセスできるとは限らないことであり、毎日の終わりにすべてのWIPブランチをgithubにプッシュしたくないことは確かです。また、コンピュータから直接取得できるように、常にコンピュータの電源を入れたままにする必要はありません。最後に、複数のブランチを最新の状態に保つためのすべてのgitコマンドが退屈になる可能性があるという小さな点があります。 この状況に3番目の対処法はありますか？このプロセスを簡単にするサードパーティのツールが利用できる場合がありますか？この状況に定期的に対処する場合、何を提案しますか？

15 git  workflows  dvcs 

現在、gitコードの管理にVSTSを使用している会社で働いています。マイクロソフトのブランチの「推奨」方法は、「スカッシュマージ」です。つまり、そのブランチのすべてのコミットが、すべての変更が組み込まれた1つの新しいコミットになります。 問題は、あるバックログアイテムのあるブランチでいくつかの変更を行った後、すぐに別のバックログアイテムの別のブランチで変更を行いたい場合、それらの変更は最初のブランチの変更セットに依存しますか？ そのバックログアイテムのブランチを作成し、最初のブランチをベースにすることができます。ここまでは順調ですね。ただし、2番目のブランチのプルリクエストを作成するときが来ると、最初のブランチは既にmasterにマージされており、スカッシュマージとして行われているため、gitは多くの競合にフラグを立てます。これは、gitが2番目のブランチの基になった元のコミットを表示せず、1つの大きなスカッシュマージを表示するだけであるため、マスターに2番目のブランチをマージするために、スカッシュマージのトップであり、多くの競合が発生します。 だから私の質問は、これを回避する方法はありますか（1つの機能ブランチを別の機能ブランチのベースにすることがないため、ワークフローが制限されます）、またはスカッシュマージはgitのマージアルゴリズムを破壊するだけですか？

15 git 

別のフレームワークなどを使用して、プロジェクトを完全に書き直す予定です。参照用の履歴を含む古いコードを保持しておくと便利です。リスク、混乱、驚きを避けるために、これを行う最善の方法は何ですか？ 私のアイデアは、新しいブランチを作成し、そこですべてを置き換え、そこで実行される基本的な「新しい」バージョンを取得し、最後の「古い」マスターにタグを付けてから、ブランチをマスターにマージすることです。これは理にかなっていますか？

14 git  github 

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

14 project-management  git  workflows  forking 

私のチームは現在、次のような非常に単純な分岐/展開プロセスを使用しています。 ┌────────┐ ┌────┐ ┌──────┐ Environments: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Builds: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Branches: │ …

14 version-control  git  development-process  deployment  development-environment 

ライブアプリケーションを実行している1台のサーバーで、約5人の開発者からなる小さなチームでgitを正しく使用する最も簡単な方法は何でしょうか？

14 version-control  git 

奇妙なタイトル、はい、しかし、私は私が思うにカバーするために少し地面を持っています。 プライベートリポジトリを持つgithubに組織アカウントがあります。githubのネイティブな問題/プルリクエスト機能を使用したいと思います（プルリクエストは、基本的にコードレビューと機能の議論に関する限り正確です）。私たちは、ツール見つかったハブをすることによってディファンクトプル要求に既存の問題を変換し、自動的にそれをあなたの現在のブランチを関連付けることができるというクールなのはほとんどの機能があります。 組織内の各開発者が組織のリポジトリをフォークして、機能の作業/バグ修正などを行うのがベストプラクティスかどうか疑問に思っています。これは非常に堅実なワークフローのように見えます（基本的にはgithubのすべてのオープンソースプロジェクトが行うことです）が、問題を追跡し、組織のリポジトリである1つのソースから要求をプルできることを確認したいと思います。 そこで、いくつか質問があります。 この場合、開発者ごとのフォークのアプローチは適切ですか？それは少しやり過ぎのようです。直接プッシュアクセスを持たず、すべてのコードをレビューする必要がある開発者を紹介しない限り、すべての開発者にフォークが必要かどうかはわかりません。その場合、それらの開発者だけにそのようなポリシーを制定したいと思います。それで、どちらが良いですか？すべての開発者が単一のリポジトリにあるのか、それともみんなの分岐点なのか ハブツール、特にプルリクエスト機能の経験はありますか？開発者ごとにフォークを行う（または特権の低い開発者向け）場合、ハブのプルリクエスト機能は、上流のマスターリポジトリ（組織のリポジトリ？）からのプルリクエストを処理しますか、それとも異なる動作をしますか？ 編集 私は問題、フォーク、プルリクエストでいくつかのテストを行い、それを見つけました。組織のリポジトリに問題を作成した場合、組織からリポジトリを自分のgithubアカウントにフォークし、いくつかの変更を行って、フォークのマスターブランチにマージします。実行しようとするhub -i <issue #>と、エラーが発生しますUser is not authorized to modify the issue。したがって、明らかにそのワークフローは機能しません。

14 version-control  git  teamwork  github  workflows 

私は.NET開発者であり、ソース管理ソフトウェアとしてTFS（チーム基盤サーバー）を何度も使用しています。TFSの優れた機能は次のとおりです。 Visual Studioとの良好な統合（だから私はほとんどすべてを視覚的に行う;コンソールコマンドはなし） 簡単なチェックアウト、チェックインプロセス 簡単なマージと競合解決 簡単な自動ビルド 分岐 ここで、Gitをオープンソースプロジェクトのバックボーン、リポジトリ、およびソース管理として使用したいと思います。私のプロジェクトは、C＃、JavaScript、またはMySQLを使用したPHP言語、またはストレージメカニズムとしてのSQL Serverデータベースです。 この目的でgithub.comのヘルプを使用し、そこでプロファイルを作成し、Git用のGUIをダウンロードしました。ここまではとても簡単でした。 しかし、私はこれ以上先を行くことにほとんど詰まっています。次のようないくつかの単純な（本当に単純な）操作を行いたいだけです。 Gitでプロジェクトを作成し、ラップトップのフォルダーにマッピングする ファイルとフォルダーのチェックアウト/チェックイン 競合の解決 それが今私がする必要があるすべてです。しかし、GUIはユーザーフレンドリーではないようです。GUIにはそのConnect To...ようなものがあり、プロジェクトのリストが表示されることを期待しています。1つを選択すると、TFSプロジェクトを探索するのと同じように、そのプロジェクトのファイルとフォルダーのリストが表示されますVisual Studioで。次に、ファイルを右クリックして、check-in...またはcheck-outそのようなものを選択できるようにします。 私は多くを期待していますか？TFSのようにGitを簡単に使用するにはどうすればよいですか？ここで何が欠けていますか？

14 version-control  git  github  team-foundation-server 

PHPフレームワークとフレームワークの上にCMSを作成しました。CMSはフレームワークに依存していますが、フレームワークはCMSファイル内の自己完結型フォルダーとして存在します。GitHubでそれらを個別のプロジェクトとして維持したいのですが、フレームワークを更新するたびにCMSプロジェクトを更新するのが面倒になりたくありません。理想的には、これらのファイルを物理的にコミットするのではなく、CMSに何らかの方法でフレームワークファイルをプルして事前定義のサブディレクトリに含めるようにしたいと思います。 これはGit / GitHubで可能ですか？もしそうなら、それを機能させるために何を知る必要がありますか？私は非常に基本的なレベルのGitを使用していることに留意してください。Eclipse用のGitプラグインを使用してリポジトリを作成し、コミットし、GitHubに接続できます。私は現在、プロジェクトでソロで作業しているので、これまでGitについてこれ以上学ぶ必要はありませんでしたが、将来的に他の人にGitを公開したいと思います。 また、依存関係のあるプロジェクトの理想的なワークフローは何でしょうか？そのテーマに関するヒントも大歓迎です。私の設定についてさらに情報が必要な場合は、コメントでお尋ねください。

14 php  git  github  dependencies 

サーバーコンポーネント、Webアプリコンポーネント、iOSコンポーネント、Androidコンポーネントなど、複数のコンポーネントを持つプロジェクトがあるとします。これらのコンポーネントはすべて個別のコードベースですが、疎結合（たとえば、サーバーの変更）コードでは、他のすべてのコンポーネントの変更も必要になる場合があります） Gitでこのプロジェクトを整理する最も効率的な方法は何ですか？すべてを1つのリポジトリに配置すると、常に最新バージョンを使用できますが、1つのコンポーネントを変更し、他のコンポーネントを変更し始めると事態は非常に面倒になります。 一方、各コンポーネントを個別のリポジトリとして作成する場合、これらのリポジトリを「リンク」して、アプリのバージョン2.0にサーバーコンポーネントのバージョン1.5などが必要であることを知るにはどうすればよいでしょうか？ 複数の関連するレポをより効果的に管理するために、最新のreadme（または表示されないより良いソリューション）を維持する以外に、gitに機能はありますか？

14 git 

一般的に呼ばれる、Git-flowモデルの修正プログラムは、特定のhotfix-*ブランチに導入され、リリースの直前に小さな統合修正がrelease-*ブランチに導入されます。前のバージョンからの一般的なバグ修正には場所がないようです。 どこに表示されますか？彼らbug-*はdevelop（ちょうどfeatureブランチのように）分岐する独自のブランチにあるべきですか？

14 git  gitflow 

私たちは、独自のgitリポジトリを管理する複数のチームを持つ小規模企業です。これはWebプラットフォームであり、各チームの成果物は夜間テストのために1日の終わりに展開されます。バージョン管理とパッケージングに関するプロセスを形式化しようとしています。 すべてのチームには、日々の開発を行うマスターブランチがあります。各チームの品質保証メンバーは、チームの変更による成果物を、すべてのコンポーネントがシェフによって結合されるテストベッドに展開することを望んでいます。アーティファクトはtarballですが、それらをRPMに変換して、バージョンについて正しく考え、推論できるようにします。 リリースプロセスには、各gitリポジトリの開発ブランチ（ほとんどの場合マスター）からリリースブランチを切り離すことが含まれます。これは、成果物のセットでテストとサインオフを実行する品質保証に与えられます。 たとえば、これは関連するリリースブランチを持つ典型的なgitリポジトリです。 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 開発ブランチから来るパッケージのバージョン管理を実行するスキームを見つけようとして立ち往生しています。各リポジトリのmasterブランチに過度にタグを付けたり、タグをリリースブランチのみに制限したりするのは望ましくありません。ただし、標準のyum / rpmセマンティクスを使用して、テストマシンにデプロイされたパッケージを照会できる必要があります。masterブランチにタグがない場合、開発バージョンはどのようになりますか？私git describeはビルドバージョンの有用な表現を提供できることを理解していますが、ブランチ上のさまざまなリリースポイントがタグ付けされている場合はうまく機能します。 EDIT1：@ Urban48の回答に応えて リリースプロセスについてもう少し説明する必要があると考えました。この議論のためにmaster、すべてのリポジトリにブランチがあると仮定しましょう。このmasterブランチは開発ブランチと見なされ、CI-CD対応の自動化されたQA環境に展開されます。これは、マスターの安定性を確保するために夜間テストのサブセットが実行される場所です。リリースブランチをカットする前に、このジョブのパイプラインを確認します。リリースブランチは短命です。リリースブランチを（安定したマスターから）カットした後、完全なリグレッションが実行され、修正が行われ、運用環境に展開されたとします。これには約1週間かかります。ほぼ2週間ごとに実稼働環境にリリースします。 機能ブランチは常にマスターから切り離され、CI-CD安定性チェックを受けるマスターとマージする前に、ある程度の開発者テストを受けます。 修正プログラムは（リリースブランチからカットされた）修正プログラムブランチで作成され、本番環境への影響を最小限に抑えて展開されます。 リリースおよびホットフィックスブランチのバージョン管理戦略は、semverに従います。QAサイクル中のリリースブランチはv2.0.0-rc1、v2.0.0-rc2などのバージョンを通過し、最終的にQAサインオフがになりv2.0.0ます。 バージョンがになるリリースブランチ（およびマスター）にマージされる小さな機能のドットリリースを行うことがありますv2.1.0。また、ホットフィックスはv2.1.1パターンを想定しています。 ただし、問題はこれらのブランチをバージョン管理することではありません。このバージョン管理スキームをまったく変更しないことをお勧めします。唯一の変更点は、開発ブランチ、つまり 主人。CI-CD環境で、以前のリリースから実稼働環境に存在するバージョンを確実に示す方法を教えてください。これは、理想的にはスマートgitタグ付けによって行われますが、masterブランチに過度にタグ付けしないものが推奨されます。

13 git  continuous-integration  versioning  release-management  packages 

私はGitに不慣れですが、Gitに慣れるために最善を尽くし、これまでのところ、私が単独で取り組んでいるプロジェクトにそれを使用しています。 私がコーディングするとき、自然に（将来を知ることができないので）いくつかのトップダウンアプローチがあり、繰り返し発生するテーマがあります。 私はいくつかの仕事をします。 自分の仕事を「コミット可能な」何かにするためには、他の仕事をする必要があることがわかります。 他の仕事は、それ自身のコミットに値する。 コミット可能なものとは、コンパイルするもの、または完全に混乱しないものを意味します。 そして、それが自分のコミットに値するものによって、私はコミットがただ一つのことをするべきだということを学んだことを言っています。 解決方法は面倒です。他の作業が別のファイルにある場合、新しいブランチを作成し、そこでコミットしてマージします。作業が同じファイルにある場合.. ugh ..ローカルコピーを作成し、ファイルをHEADの状態にリセットし、必要なコミットを行ってから、コピーから作業を復元し始めます。実際にどのように処理する必要がありますか？私はこれが道だとは思いませんよね？私はそうは思いません。なぜなら、それは皆（少なくとも未来も知らない）には幾分頻繁に出会わなければならないからです。それとも、私のワークフローに欠陥があるようです。

13 git 

私は共有ホスティングの下で​​同じウェブホスティングサービスですべてホストされているいくつかのサイトを持っています。私のWebホストはGitをサポートしており、SSHにアクセスできます。ラップトップでもGitをセットアップできます。 「git push origin master」を実行すると、Webサーバー上のファイルが自動的に更新され、以前のコミットのファイルのバックアップも保存されるため、必要に応じて簡単にロールバックできます。これは可能ですか？

13 git  web 

私の目標は、特定の要件を満たさないコミットデータをチェックし、作成中のコミットまたはリモートリポジトリにプッシュされたコミットを拒否することです。 事前コミットフックを行うことの問題は、事前コミットフックファイルを手動で更新する必要がある多くの人々に展開するのが難しいことです。同様に、Gitでは.gitフォルダーにサブモジュールを配置することはできません。サブモジュールを配置することは非常に簡単ですが、悲しいかな。 私が見る他のオプションは、リモート側の更新フックをチェックインすることです。これは、devによってプッシュされた各コミットをチェックし、コミットのいずれかがテストに失敗した場合にプッシュを拒否します。 誰もこの問題に関する洞察を持っていますか？もしそうなら、更新フックスクリプトの例を提供してくれますか？私はそれがどのように機能するかに関して少し混乱しています。

13 git