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

私は、nvieのgit-flowのモデルにほぼ従うgit分岐モデルを持つプロジェクトを持っています。 リリースブランチは、SemVer形式で名前が付けられます。たとえば、v1.5.2 リリースブランチに本番環境の青信号が与えられたら、マスターにマージしてタグを適用し、ブランチを削除してブランチを閉じます。 リリースブランチをすぐに削除するので、ブランチのタグ付けに同じ識別子を使用しました。例えば v1.5.2 リリースブランチを閉じるために使用するコマンドは次のとおりです。 $ git checkout master $ git merge v1.5.2 $ git tag -a v1.5.2 -m "Version 1.5.2 - foo bar, baz, etc" $ git branch -d v1.5.2 $ git branch -dr origin/v1.5.2 $ git push origin :v1.5.2 $ git push $ git push --tags これは大部分のケースで機能するようですが、gitリポジトリの別のインスタンス（別の開発マシン、ステージング環境など）がv1.5.2ブランチのローカルチェックアウトを持つシナリオで問題を引き起こしています。 …

20 version-control  git  branching  gitflow 

機能がテスト用にステージングされるようになると、規模が大きくなるにつれて問題に遭遇し始めますが、すべてがテストされ、承認された新しい機能がテスト用にステージングされます。 これは、テスト済みの機能と未テストの機能の組み合わせがあるため、本番環境にほとんどプッシュできない環境を作成しています。これは一般的な問題であると確信していますが、まだ私たちにとって良いリソースが見つかりませんでした。 いくつかの詳細： BitBucketのGIT Azureへのスクリプト展開用のJenkins 私が望んでいるのは、機能が環境を移動するときに機能を分離し、準備ができているものだけをプッシュする方法です。

19 git  continuous-integration  branching  devops 

私はGitHubにリポジトリを所有しており、誰かが1回のコミットでプルリクエストを送信しました。私は彼のソリューションを部分的に実装したいだけで、ユーザーが行ったコード変更の約半分を使用します。この状況ではどうすればよいですか？ 彼のバージョンのブランチを作成し、元のバージョンから2番目のコミットに保存する「古い」コードをコピーして貼り付けます。これにより、コミット間の差分が実際より大きくなり、のようなものがスローされgit blameます。 彼のコミットから保持したいコードをコピーして、新しい別のコミットに貼り付けます。これは、彼がコードへの貴重な貢献に対してクレジットを受け取らないことを意味します。 上記と同じように、彼のコードの一部を新しいコミットにコピーしますが、コミットの作成者を私ではなく彼に変更します。彼は技術的にはコミットされた正確なコードを書いていないので、これが眉をひそめているかどうかはわかりません。しかし、少なくとも彼は使用されている行の属性を取得します。

19 version-control  git  github  etiquette 

Gitでプロジェクトを構成する方法について、いくつかのアドバイスが必要です。Javaを使用し、Mavenはビルドツールです。Mavenは、最終的にすべてのプロジェクトに共通の祖先があると想定しています。Mavenは、Apache Foundationがプロジェクトをセットアップする方法が正確にセットアップされていない場合、本当のドラマクイーンになることもあります（リリースプラグインを使用している人は、おそらく私が話していることを知っています）。 プラグインのバージョンとビルド構成（リポジトリ構成、ビルドするアーティファクト、命名規則、プラグインバージョンなど）を制御する最上位の親pomが必要です。Mavenは、すべてのITプロジェクトをそのメインプロジェクトのサブフォルダーに入れたいと考えています。これは、組織の1つの大規模なGitリポジトリを意味します。 これは非常に騒がしい環境になります。関連のないプロジェクトに取り組んでいる2つのチームがある場合、それらは常に他のチームからマージをプルする必要があります。理想的には、プロジェクトごとに1つのリポジトリが必要です。 しかし、そのような種類は、サブプロジェクトがサブフォルダーであることを要求する Mavenの非常に階層的なモデルと衝突します。 人々がこれら2つのモデルをどのように調整したかについて、いくつかのアドバイスが必要です。

19 java  version-control  git  maven 

私は、会社でGitlabをワークフロー戦略で実装することに取り組んでいます。私の考えは、開発者はリポジトリへのアクセスを許可されるが、コミットしようとするときはいつでも、コードをレビューする必要があるということです。 コミットする前にブランチを作成し、レポジトリにプッシュされた後にマージリクエストを作成できることを知っています。特定の事柄についてはまだ不明です...ブランチを作成するために人に頼ってからマージリクエストを行うという考えは間違っているように見えますが、マスターブランチがadmin」は、統合しようとしているコードを承認します。「github team workflow」を読みましたが、実行可能なソリューションを提供していないようです。プロセスまたはご自身のベストプラクティスに関するアドバイスを歓迎します。ありがとう！

18 development-process  git  gitlab 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 そこで私は、会社がSVNを使用する仕事に就きました（ただし、将来Gitに移行する予定です）。問題は、SVNがわからないことです。多数のGoogleクエリを試しましたが、見つけることができるのはSVN-> Gitチュートリアル、「SVNよりGitが優れている理由」ブログ、および（一部の）比較可能なコマンドを提供する特定の「チートシート」だけです... SVNに関するO'Reillyの本を読む以外に、Gitユーザー向けのSVNへの簡単な（しかし、短すぎない）指示は何ですか？

18 git  svn 

私はGitHubでオープンソースプロジェクトに取り組んでいます。 サブディレクトリ/ Vendorがあり、その中にいくつかの外部ライブラリのコピーがあります。プロジェクトの元のメンテナーは、このディレクトリを外部ライブラリの新しいコピーで時々更新しました。 1人の開発者が、このコピーをgit submoduleに置き換えるというアイデアのあるプルリクエストを送ってきました。 そして、それが良いアイデアかどうかを検討しています。 Gitサブモジュールの長所： サブモジュールは、同様のシナリオ用に特別に設計されました 次の更新中に上書きされるベンダーへの偶発的なコミットの可能性を削除します Gitサブモジュールの短所： gitサブモジュールがメンテナーからプロジェクトをクローン/プルする人に複雑さを押し付けているようです（クローンを作成してプロジェクトの作業を開始するには、追加の手順が必要です： "git submodule init"、 "git submodule update" これについてはどう思いますか？ もう一つ。この問題は、外部依存関係が非常に限られているかなり小さなサイズのライブラリです。今のところ、どんなビルドツールでもやり過ぎだと思います。

18 git  github 

この記事「成功したGit分岐モデル」は、経験豊富なDVCSユーザーの間で非常によく知られていると思います。 私はhg主に使用しますが、この議論はどのDVCSでも問題ないと主張します。 現在のワークフローは、各開発者がマスターリポジトリのクローンを作成することです。独自のローカルリポジトリにコードを記述し、テストを実行し、すべてがうまくいけばマスターにプッシュします。 そこで、JenkinsのようなCIサーバーをセットアップし、将来のプロビジョニングシステム（シェフ、パペット、アンシブルなど）でワークフローを改善したいと考えています。 実部 さて、上記のモデルはうまく機能しますが、ブランチはCIを壊す可能性があります。機能ブランチは、developmentCIとマージをスムーズにするために、オリジンと同期する必要があります（記事によると、ブランチになります）。 アリスとボブが2つの機能に取り組んでいると言います。しかし、アリスは翌日に行われます。ボブの機能には1週間かかります。Bobが完了するまでに、彼の変更は古くなっています（おそらく、Aliceは一部のクラスをリファクタリング/名前変更しています）。 1つの解決策は、毎朝、開発者がプルmaster/originして、変更があるかどうかを確認する必要があることです。Aliceがコミットした場合、Bobは自分のワークスペースにプルしてマージし、機能ブランチが最新になるようにします。 これは良い方法ですか？ これらのブランチは（ローカルクローンではなく）マスターリポジトリに存在する必要がありますか？つまり、すべての開発者がGitHub / Bitbucketのマスターリポジトリにコミット権限を与えて、新しいブランチを作成できるようにする必要がありますか？または、これはローカルで行われますか？ 最後に、記事が提示するモデルは、ブランチがと同期していない場合、CIを破壊する必要がありorigin/masterます。ナイトリービルドを実行したいので、開発者は仕事を離れる前にプルしてマージし、各機能ブランチでもCIを実行する必要がありますか？

18 git  continuous-integration  mercurial  dvcs  branching 

私は最終的にはオープンソースになるプライベートプロジェクトに参加しています。私たちには、アプリを構築するための技術に十分な才能がある少数のチームメンバーがいますが、クリーンで美しい、最も重要な長期保守可能なコードを書くことができる専任の開発者はいません。 コードベースのリファクタリングを開始しましたが、定期的に連絡を取り合っていない別の国にいるチームの誰かがこのまったく別のものを更新する可能性があるため、少し扱いに​​くいです。 解決策の1つは、迅速に通信するか、より良いPMプラクティスを採用することですが、まだそれほど大きくはありません。コードをクリーンアップして、彼が更新したものにうまくマージしたいだけです。ブランチを使用することは適切な計画でしょうか？ベストエフォートマージですか？他に何か？

18 open-source  version-control  git  refactoring  branching 

私は自分のプロジェクトに取り組んでいる初心者プログラマーとしてあなたに来ます（これは順調に進んでいます）。私の共同創立者はプログラミングの方法も学んでおり、おそらくいくつかの問題を修正し、何らかの問題を起こせるようになりました。 彼は非常に良い質問をしました。それは「この仕事はどうするのか」でした。私は他の誰かとプログラムしたことがないので、私が理論化するだけの何か。最適なワークフローを教えてください。gitを使用します。 システムの特定の部分を所有する必要がありますか？コードをチェックインしていますか？コードレビュー？ > 1開発者とどのように連携しますか？

18 git  github  gitflow 

私はいくつかのプロジェクトをgit flowワークフローに移行しましたが、それが大好きです。ただし、一度に複数のメジャーバージョンが維持されているプロジェクトで作業する場合、物事をスムーズに進めるベストプラクティスは見つかりませんでした。 具体的には、「無料版」や「有料版」などのパラレルモデルを維持していません。バージョン1がリリースされ、マイナーバージョン（1.1、1.2などでサポートされているプロジェクト）について話しているのです。 。）バージョン3がリリースされるまで、その時点で2と3が維持され、4がリリースされるまで... gitflowワークフローでプロジェクトの2つ以上のサポートされているバージョンを一度にどのように維持しますか？

18 git  workflows  gitflow 

GitがインストールされたWindows 10があります。このGitは、私のC:/Users/MyNameディレクトリをHOMEディレクトリとして使用し、/.ssh/内部のディレクトリを使用して、適切に秘密のSSHキーを取得します。 「Windows上のUbuntuでのBash」を有効にしてセットアップし（口一杯です！）、そこにGitもインストールしました。両方のGitsに同じキーのセットを使用して、このマシンで作業する環境が問題にならないようにしたいと思います。コミットは常に私から行われます。 bashのHOMEディレクトリーが異なる（/home/MyName）ため、現在遠くにあるキーが表示されないという問題があります../../mnt/c/Users/MyName/.ssh。HOME環境変数を次のように変更することで、勝者になると思いました。 export HOME=/c/mnt/Users/MyName これにより、HOMEディレクトリが正常に変更されましたが、bash gitはまだ./.sshディレクトリ内に含まれるキーを認識しません。 これがA）かどうかはわかりませんが、これはbash gitが異なるファイル形式のキーを想定しているためですか？（現在のものはid_rsaand id_rsa.pub）B）bash gitは変更されたHOME変数を無視していますか？または多分両方。 また、C）このようにHOME変数を任意に変更することが、それを参照する可能性のある他のプログラムについて一般的に良いアイデアであるかどうかもわかりません

18 git  authentication  bash  ubuntu  windows-10 

私たちのチームは、FogBugz＆Kiln / MercurialからJira＆Stash / Gitに切り替えました。ブランチにはGit Flowモデルを使用し、機能ブランチからサブタスクブランチを追加しています（Jira機能のJiraサブタスクに関連）。プルリクエストを作成して親ブランチにマージするときにStashを使用してレビュアーを割り当てます（通常は開発しますが、サブタスクは機能ブランチに戻ります）。 私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで相互に依存しているコードで作業している場合、機能ケースの最適な計画と内訳でもです。別のブランチでは、1人の開発者が他の開発者をブロックします。 開発中に、お互いのブランチ間をプルしようとしました。また、各開発者が複数のブランチからプルして、開発時に統合をテストできるローカル統合ブランチを作成しようとしました。最後に、これはこれまでのところ私たちにとっておそらく最もうまく機能しているようですが、もう少しオーバーヘッドがありますが、機能ブランチからすぐに統合ブランチを作成しようとしました。サブタスクブランチ（機能ブランチ外）がプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。その後、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルできます。これにより、コードレビューに合格するために依存しているブランチを誰も待つことができなくなります。 これは必ずしもGitの問題ではないことを知っています。これは、独自の作業プロセスと文化が混在する、複数のブランチで相互依存するコードを操作することに関係しています。開発（厳密な統合ブランチ）のための厳格なコードレビューポリシーがない場合、開発者1は、開発者2が引き出せるように開発にマージできます。もう1つの複雑な点は、QAに機能を渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。バックエンド開発者2が終了し、プルリクエストがコードレビューに1週間座っている場合、フロントエンド開発者2はコードレビューアができないため、技術的にプルリクエスト/コードレビューを作成できませんバックエンド開発者2 'のためのテスト 結論として、これらのインスタンスでは、どのルートに行くかに応じて、パラレルではなくはるかにシリアルなアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。 最後に言及することは、コードのレビューとファイナライズが完了していないブランチ間でコードを共有することで実現していますが、本質的には他のベータコードを使用しています。ある程度まではそれを避けることはできないと思いますし、ある程度それを受け入れるつもりです。

17 git  workflows  branching  jira  gitflow 

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

17 git  github  branching  forking 

Githubでプロジェクトを分岐し、小さな変更を加えて、プルリクエストを元のメンテナーに送信しましたMerged pull request #11 from my_username/master。 これは私がこれをしているのは初めてなので、エチケットが今何であるのかわかりません：私はgit pull upstream masterそれからをしましたgit push origin master、そして今私自身のリポジトリの最後のコミットは私Merged pull request #11 from my_username/masterにはかなり奇妙に感じます。これは人々が通常行う方法ですか、「歴史をきれいにする」ために何かする必要がありますか？ 注：これは小さなドキュメントの変更であったため、ブランチを作成していませんでした。ブランチに変更を加えmaster、プルリクエストを送信しました。そのため、その部分で実行するクリーンアップはありません。

17 git  github  pull-requests