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

注： 私の質問は、特定の問題（Liferayを含む）に焦点を当てていますが、gitで同じプロジェクトのさまざまなバージョンを維持する必要がある人にとって役立つことを願っています。 私はLiferay Portalの多くのプラグインを書いている会社で働いています。これらのプラグイン（ポートレット、テーマなど）は通常再利用可能であり、もちろん、ポータルの新しいバージョンに合わせて更新する必要があります。 しかし、移行する必要があり、私たちは、言うのLiferayの新バージョンへのポートレットせることが通常であるとその前のバージョンを維持します。また、一部のクライアントに対して非常に具体的なカスタマイズを作成する必要が頻繁にありますが、これは「メインバージョン」に追加しても意味がありません。 これらの要件により作業が複雑になりますが、幸いなことに、いくつかの単純化を想定できます。たとえば、プラグインは一度に1人のプログラマのみが頻繁に更新します。プラグインに複数の機能を同時に追加することは非常にまれです。 現在、Gitoriousに移行しています。このようなシナリオの分岐モデルを考えています。 私のモデル 私が提案したのは： 各プラグインには、プロジェクト内のGitoriousに独自のリポジトリがあります。たとえば、子猫を表示するためのポートレットにはkittens-portlet、liferay-portletsプロジェクト内にリポジトリがあります。 新しいプラグインを作成するときは、Liferayバージョンに応じて名前が付けられたブランチ（たとえば、lf5.2）に作成します。 プラグインで更新が行われるたびに、更新は本番環境で承認およびデプロイされ、プラグインにバージョン（たとえばlf5.2v1、lf5.2v2など）のタグが付けられます* プラグインをLiferayの新しいバージョンに移植するたびに、最新バージョンをブランチします（たとえば、ブランチを作成しlf6.0ます）。 本番環境に入ると、新しいブランチのヘッドはなどのタグを受け取りlf6.0v1ます。 クライアント固有の方法でプラグインをカスタマイズする必要があるたびに、クライアントの名前でブランチを作成します（たとえば、lf5.2clientcorpクライアント「ClientCorp Inc.」のブランチを作成します） これは通常とは異なるモデルですmaster。マージされないブランチはまったくなく、多くあります。これは、そのようなモデルを持つリポジトリが次のように見えると思う方法です： 友人がこのシステムをかなり複雑でエラーが発生しやすいと感じました。彼は、優れた人気のあるVincent Driessenモデルを提案しました。もちろん素晴らしい（そしてテスト済み！）が、私たちの状況には複雑すぎるようだ。 私の友人のモデル 次に、彼は別のモデルを提案しました。Liferayバージョンの各プラグインのリポジトリを作成し（したがって、を作成しkittens-lf5.2-portlet、次にを作成しますkittens-lf6.0-portlet）、それぞれにmasterブランチとdevelopブランチがあります。これmasterにより、いつでも展開の準備が整います。（それとも、他の方法で回避することが、可能性masterとstableによって示唆されているように、スティーブLosh）。 これは非常に簡単ですが、私はこのシステムが好きではありませんでした： その結果、プロジェクトに膨大な数のリポジトリが作成され、Gitoriousの閲覧が困難になる可能性があります。 プロジェクトのディレクトリの名前が関連しています。誰かがリポジトリをkittens-lf6.0-portletディレクトリにクローンし、antを使用してWARを生成する場合（通常どおり）、WAR名kittens-lf6.0-portletも同様になります。このポートレットの古いバージョン（kittens-portletたとえば、名前が付けられている）は、アップグレードされたポータルでは異なる（おそらく欠落している）ポートレットと見なされます。少し注意すれば回避できますが、回避したいです。 同じプラグインの異なるバージョンは別々に維持されます。私は私の心を壊します:( kittens-lf6.0-portlet リポジトリのい名前だと思います。 私は、2つの最後のポイント-これも2つのより主観的なポイント-が私の不本意の主な理由だと思います。それにもかかわらず、すべての4つの異議が立っています。 OTOH、私自身の提案は私には奇妙に思われ、それに隠されたバグがあるのだろうかと思います。OT3rdH gitは非常に強力で柔軟性があるため、その可能性を探ることに恥ずかしさは感じないと思います。 だから、私は尋ねます： 最高のモデルは何でしょうか？わたしの提案？友達のモデル？今では伝統的なビンセント・ドリーセンのシステムですか？ 他にどのような分岐モデルを提案しますか？ 私のモデルが悪いと思うなら、なぜそう思うのですか？私は欠点と盲点が何であるかを学びたいです。 *実際には、次のようなバージョンでコミットにタグ付けすることを好みますv1が、どうやらgitのタグはブランチ内でスコープされていません-つまり、1 つのv1タグlf5.2ともう1つのタグを持つことはできませんでしたlf6.0ので、ブランチ。それは正しいですか？

13 version-control  git  branching 

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

13 project-management  git  github  svn 

関連： すべてのgitコミットはプロジェクトを動作状態のままにする必要がありますか？ 次のコミットをローカルで行うと仮定します。 データベーススキーマを変更して、アプリケーションを破壊します。 データベーススキーマと再度互換性があるようにアプリケーションを更新します。 両方のコミットをプッシュする限りmaster、動作状態のままです。ただし、履歴バージョンは壊れています。 私はgit rebase -iコミットを一緒につぶすために使用できることを知っています。ただし、結果のコミットは大きくなり、説明が少なくなります。コミット履歴を検索して、何かを変更した理由を調べる必要がある場合は、元のコミットが自分が何をしたのか、そしてなぜなのかを示したいと思います。 私の質問は： masterで壊れた履歴コミットが原因で問題が発生した人はいますか？ もしそうなら、個々のコミットメッセージと変更を破棄せずに、そのような困難を避ける簡単な方法はありますか？

13 git  dvcs 

現在、私の会社は、次のように編成されたSVNリポジトリにVisual Studioのソリューションを持っています。 SolutionFolder (~3.5 GB) |-> SolutionName.sln |-> .. Some source code folders... (~250 MB) |-> ThirdParty (~3 GB) |-> Tools | -> Tool1 | -> Tool2 Tool1とTool2は独立してビルドされます（独自のソリューションがあります）が、メインビルドで使用される実行可能ファイルを生成します。ThirdPartyフォルダーには、一部のプリコンパイルされた100 MB以上の.libファイルやboostなどの大きなライブラリなど、プロジェクトのすべての依存関係が含まれています。 （1）開発者が1回のチェックアウトだけを行う必要があり、（2）ビルドの各バージョンに必要な依存関係のバージョンを追跡する必要がないように、すべてを1つのSVNリポジトリに含めると便利です。反対に、このレポを確認するには時間がかかります。 このプロジェクト構造をgitに移動する最良の方法は何でしょうか？おそらく、メインリポジトリからThirdPartyとツールを除外するのが最善ですが、ThirdPartyを1ステップで簡単にダウンロードできるようにして、バージョン管理が必要です（メインリポジトリとThirdParty / Toolsのバージョンの不一致は悪いでしょう）。 この時点では、歴史を保存することには興味がありません。そのようなプロジェクトを整理する方法を理解するだけです。

13 version-control  git 

したがって、次のことが起こると想像してください（そして、すべてSourceTreeを使用している）。 私たちはすべてorigin / developに取り組んでいます。 私は一週間休みに行きます。 私の同僚は、過去数日間、起源/開発を自分のローカル開発ブランチにマージせずにローカルで作業しています。 彼はプッシュを試み、最初にマージする必要があると言われ、次にプルを行います。 彼は競合を取得し、マージ後の自動コミットの進行を停止します。 GitがSVNに似ていると仮定すると、私の同僚は作業コピーの「新しい」ファイルを破棄してから、マージをコミットします。これらの「新しい」ファイルを発信元/開発者のヘッドから消去します。 その改訂に加えて、数週間分の開発作業が行われます。 私は休日から戻ってきて、私の仕事の数日間が不足していることがわかります。 私たちはすべてGitに非常に新しい（これを使用する最初のプロジェクトです）が、それを修正するために私がしたことは： 「develop」の名前を「develop_old」に変更します。 developer_oldを新しいブランチ「develop_new」にマージします。 不良マージの前の最後のコミットに、develop_newブランチをリセットします。 Cherryはそれ以降、各コミットを1つずつ選択し、手作業で競合を解決します。 開発元と開発元をプッシュします。 この時点で、develop_newは、すべての変更の「良い」コピーであり、その後の数週間分の作業が再適用されることを望んでいます。私はまた、「逆コミット」がマージで奇妙なことをすることを想定しています。特に今後数週間の作業はそれに基づいているためです-そして、そのマージには私たちがしたいものと一緒に欲しいものがたくさん含まれているのでt。 私はこれが二度と起こらないことを望んでいますが、もし二度と起これば、私は物事を修正するより簡単/より良い方法を知りたいです。そのマージに基づいてレポで多くの作業が行われたときに、「悪い」マージを元に戻すより良い方法はありますか？

13 git 

通常、プログラムを作成するときは、明確なタスクが先にありますが、迷惑なものを見つけて、進行中にクリーンアップしたいと思います。 ここには3つのオプションがあります。 後で実行します（チケットを追加するのを忘れたり、時間を費やす必要がある場合があります） 今すぐ実行し、現在の作業と一緒にコミットします（不明） 今すぐ実行し、個別にコミットします（それを見つける必要があり、間違いを犯し、意図せずにオプション2に進む可能性があります） これはおそらくかなり基本的なことですが、svn / git / otherを使用してこれを回避する方法は何ですか？

12 version-control  git  svn  workflows 

現在、次のような状況にあり、サブ機能ブランチに対して機能ブランチがブランチされています（同じ機能のバックエンドとフロントエンドの作業など）。 o | o development |\ | o feature-a | | | o | |\ | | o feature-a-sub | | | | | | | \ | o merged feature-a into feature-a-sub | / o feature-a-sub merged into development | | | o feature-a with future work on it …

12 git  branching 

ずっと前に、私が仕事をしている小さなWeb開発者チームは、Web開発にgitを使い始めました。当時は、ステージングまたはマスターに直接コミットし、2つの間で頻繁にマージしていました。それは何もないよりはましでしたが、混乱でもありました。 少し前に、gitflowワークフローを採​​用しました。それは確かに前に来た混乱よりも優れていますが、やや面倒で過度にリリース/マイルストーン指向です。私の仲間の開発者は、それがどのように機能するのか、何をマージすべきか、何をマージすべきでないのかを明確にするように頻繁に頼まれます。一般的に、リリースの特定のマイルストーンを追跡せずにコードを頻繁にデプロイするWeb開発作業には適さないようです。 友達の最近の提案で、GitHub Flowを見始めました。ここでスコットチャコンの投稿を読むと、これで問題が完全に解決されます。 それでは、なぜGitHubでgit-flowを使用しないのでしょうか？まあ、主な問題は、常に展開することです。git-flowプロセスは、主に「リリース」を中心に設計されています。運用環境に毎日（多くの場合1日に数回）展開するため、実際には「リリース」はありません。 FWIW、私はアトラシアンのサイトでこの素敵なワークフローのまとめを見ました：https ://www.atlassian.com/git/workflows#!workflow- feature-branch しかし、それらはすべて、小さなチームでのWeb開発には不適切な選択肢のように見え、頻繁な/毎日のリリースではなく、主要なアプリケーションリリースを対象としています。 これは、git-flowとgithub-flowを比較するよう求めるSEに関する質問です /programming/18188492/what-are-the-pros-and-cons-of-git-flow-vs-github -フロー それは一般的に良い答えですが、下のコメントで言及したように、meta.programmers.SEは一般的なワークフローのベストプラクティスに関する質問がここにあることを示しているようで、単なるgit-flowやgithubよりも幅広い回答のリストを期待していました-ウェブ開発に固有のフロー。したがって、ここで新しい質問が必要だと思います。 それで、かなり継続的な展開を伴うプロジェクトに取り組んでいる小規模なWeb開発チームにとって、最適/推奨のgitベースのワークフローは何ですか？それはgithub-flowか何かですか？

12 web-development  git  gitflow 

会社でGitLabサーバーを設定していますが、今はGitLab CIを追加しています。 このタスクを開始する前に、GitLabとGitLab CIで使用される同じサーバー上でランナーを実行する際に不利な点があるかどうかを理解したいと思います。 セキュリティ上の懸念があることを読みましたが、内部でのみ使用しているため、これが問題になるとは思いません。 何か不足していますか？

12 git  continuous-integration  gitlab 

同僚と私は、現在のgitリポジトリから派生したバージョンをビルドするたびにコードに統合することの問題/メリットを交互に議論/議論しています。 メリットは次のとおりです。 バージョン番号を更新する際に人的エラーを心配する必要はありません デバイスで見つかったものと、そのソースコードのソースコードとの間のトレーサビリティ （私たちにとって）発生した問題は次のとおりです。 IDE派生ビルドシステム（MPLABXなど）は、これらの種類のフックをどこに配置するのかを把握するのを難しくする可能性があります（最終的にはかなり安っぽくなります） これをビルドスクリプト/メイクファイルに実際に統合するためのさらなる作業 特定のビルドアプローチ（たとえば、1人がXCodeと他のMPLABXを使用してビルドした場合）へのカップリングは、ダウンストリームのサプライズを作成する可能性があります だから私たちは他の人がこの議論に上陸した場所に興味があります。議論が逸話になるのは本当に簡単です。エンドツーエンドの自動化に固執し、先行作業とそれが生み出すカップリングの量を掛ける人が大勢います。そして、議論の反対側には多くの人がいます。彼らは、最も簡単なことをして、リスクを抱えて生きています。 どの側に着陸するのが最適であるかについて、合理的な答えはありますか？

12 c  git  builds  build-system 

この質問のフォローアップとして： 自分でチームで作業している場合、ブランチをマージするときに、すべてのコミットを1つの差分にまとめてからその差分をマージすることで、有用なコミットメッセージを維持できます。そうすれば、ブランチでどのような変更が導入されたかを簡単に確認できます。また、マスターブランチを参照するときに、そのブランチで達成された機能/変更/その他を説明する1つの要約があります。 私の質問は、チームで作業するときにこれをどのように達成できますか？その状況では、ブランチはリモートリポジトリにプッシュされます。つまり、ブランチ内のすべてのコミットを1つのコミットにまとめることはできません。ブランチがパブリックである場合、マスターブランチで有用なマージコミットを1つ持つことができますか？（「有用」とは、マスター行のコミットが（1）ブランチで行われた内容の有用な要約と（2）同じものの差分を示すことを意味します。）

12 git  branching 

私は個人的なワークフローを考え出そうとしています。リリースの架空の寿命のフローチャートを作成しました。ある開発者が公開githubリポジトリにプッシュし、友人が何らかの機能を手伝ってバグを修正しました。 これはバージョン管理の合理的なアプローチですか？ 主なアイデアは、パブリックリポジトリを整理することです。 新しいリリースはそれぞれ、終了時にマスターブランチで最終的にタグ付けされるまで、独自のブランチになります。 すべての作業は、異常を防ぐために、実際のリリースブランチではなく、「機能」または「ホットフィックス」ブランチで行われます。 高レベルのブランチへのマージは、常にリベースまたはスカッシュされます（混乱を避けるため）。 やり過ぎだとしても、大事なプロジェクトに必要なスキルを習得することが全体的な目的なので、気にしません。唯一の問題は、私が間違っているか不必要なことを完全にやっていることです。 編集2：元のフローチャートの悪い考えを修正し、ナビゲートしやすくしました。

12 project-management  programming-practices  version-control  git  workflows 

git、maven、およびjenkinsを使用して次のことを行うための好ましい方法は何ですか： 「dev」ブランチと「release」ブランチを維持したいアプリケーションを開発しています。ジェンキンスに両方を構築してほしい。リリースアーティファクトのバージョンが1.5.2になり、開発ビルドが0.0.1-SNAPSHOTになるだけになる可能性があります。2つの異なるpom.xmlファイルを持つ必要はありません。 プロファイルを調べましたが、アーティファクトのバージョンを変更できないようです。私が見た1つの方法は、テストビルドに「修飾子」を追加することです。もちろん、ファイルの名前を変更することもできます。これは、アプリがスタンドアロンのものであるため、これに関する実際のアーティファクト情報は重要ではないからです。 これを行うための好ましい方法は何ですか？または、これをどのように行いますか？

12 git  workflows  versioning  jenkins  maven 

アプリのファミリーがあり、すべてが同じベースを持っています。これまで私はこのベースを開発してきましたが、Gitのワークフローは非常にシンプルでした。 開発はdevelopブランチで行われます name-of-the-featureブランチで新機能が開発されています リリースはrelease-**ブランチで行われます これまで、コードは家族のすべてのアプリで同じでした。彼らが共有する基盤が完成し、今後コードはアプリごとに異なるとしましょう。 同じベースを持つgitとこの複数のアプリをどのように扱うべきかわかりません。 それぞれに独自のgitプロジェクトが必要ですか？ それらは同じプロジェクトにあるべきですが、それぞれが独自のブランチにありますか？ 重要なのは、それらを別々のプロジェクトに配置すると、アプリのベースで行われたすべての変更は、アプリごとに繰り返されることになります。私はgitにあまり詳しくありませんが、各プロジェクトをブランチに保存すると、ベースの変更を各アプリにマージできますか？ 誰もこのような状況を経験していますか？どうすればいいかわかりません。 ありがとう！ 編集済みバージョン を言ったとき、バージョン番号のような意味ではありませんでした。実際には、同じベースを共有する異なるアプリです。

12 git 

私の理解から、SVNは「簡単に分岐できます。マージが難しい」。何故ですか？マージ方法に違いはありますか？

12 git  svn  mercurial  dvcs