タグ付けされた質問 「version-control」

SVNトランクにコミットされる前にコードをレビューする最良の方法は何ですか？私が考えているアイデアの1つは、開発者にコードをブランチにコミットさせ、ブランチのリビジョンをトランクにマージしながらコードを確認することです。これは良い習慣ですか？そうでない場合、トランクにコミットされる前にコードをレビューするために他に何ができますか？

14 version-control  code-reviews  svn 

バージョン管理管理システムで多くのコンポーネントを持つ大きなプロジェクトを管理する方法を知りたいです。 私の現在のプロジェクトには、4つの主要な部分があります。 ウェブ サーバ 管理コンソール プラットホーム。 Webとサーバーの部分は、私が書いた2つのライブラリーを使用します。合計で5つのgitリポジトリと1つのmercurialリポジトリがあります。プロジェクトビルドスクリプトはプラットフォームリポジトリにあります。構築プロセス全体を自動化します。 問題は、複数のコンポーネントに影響する新しい機能を追加するときに、影響を受ける各レポジトリに対してブランチを作成する必要があることです。機能を実装します。それを元に戻します。私の直感は「何かが間違っている」です。 単一のリポジトリを作成し、そこにすべてのコンポーネントを配置する必要がありますか？その場合、分岐が簡単になると思います。または、私が今やっていることをやるだけです。その場合、各リポジトリにブランチを作成するこの問題をどのように解決しますか？

13 version-control  branching  configuration-management  merging 

私の会社（Acme Technologyと呼びます）には、元々Acme Labsの研究グループから来た数千のソースファイルのライブラリがあり、開発グループで数年間インキュベートされ、最近では少数の顧客に提供されています非開示。Acmeは、おそらくコードの75％をオープンソースコミュニティにリリースする準備をしています。他の25％は後でリリースされますが、現在のところ、顧客が使用する準備ができていないか、競合他社の手に渡らないようにする必要がある将来のイノベーションに関連するコードが含まれています。 現在、コードは#ifdefsでフォーマットされており、同じコードベースを、大学の研究者やはるかに広範な商業顧客がオープンソースに移行する前に利用できるプリプロダクションプラットフォームと連携することができます。実験とプロトタイピング、および将来のプラットフォームとの前方互換性テストに利用できます。単一のコードベースを維持することは、2つのコピーを並行して維持するのが困難な私のグループの経済性（および健全性）にとって不可欠であると考えられています。 現在のベースのファイルは次のようになります。 > // Copyright 2012 (C) Acme Technology, All Rights Reserved. > // Very large, often varied and restrictive copyright license in English and French, > // sometimes also embedded in make files and shell scripts with varied > // comment styles. > > > ... …

13 open-source  licensing  version-control  parsing 

注： 私の質問は、特定の問題（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 

職場ではSVNを使用していますが、名前のみです。分岐もマージもしません。リポジトリの2つのコピーを保持します。1つは展開の際にコピーされ、バグ修正のために保持される「タグ」ブランチとして機能します。一方のコピーで行われた変更をもう一方のコピー（「トランク」）にコピーすることを忘れないでください。リポジトリ内の単一のフォルダー内に、プロジェクトを分割するのではなく、12個のプロジェクトがあります。要するに、SVNを使用するのはコミットできることだけです。他のすべては手動で行われます。 Mercurialを評価しています。私は過去にGitを使用しました（DVCSを使用したのはチームで1人だけです）。Mercurialをすぐに使用しています。ブランチは簡単で、マージははるかに簡単で、ローカルに心のこもった内容をコミットして中央にプッシュするだけなので、物事を行う「より良い方法」としてMercurialをチームの他のメンバーに紹介することを議論しています準備ができたら分岐します。SVNのすべての利点が得られます（そして、SVNを本当に理解していないので、今のところ多くの利点が得られません）。また、新しい機能については、バージョン管理されていないファイルがたくさんあります。失敗した。ワークフローは少し単純に思えます-「コミット」はローカルであり、「プッシュ」はSVNのコミットに似ていることを覚えておく必要があります。 これは取るべき良いアプローチですか？チームは非常に柔軟であり、仕事の質を向上させ、物事を簡単にする方法を提供することを心に留めておいてください。CIOは、SVNを使用していない可能性について述べたときに私に尋ねましたより良いものがありますか？」彼も一緒に乗っています。

13 version-control  svn  mercurial 

最近、リファクタリング全般の処理方法に関する議論に参加しました（それ自体が興味深いトピックです）。最終的に、次の質問が提起されました。 他の誰かが同じコードの機能に取り組んでいる間に誰かがコードの一部をリファクタリングしたために発生したマージ競合をどのように処理しますか？ 基本的に、効率的な方法でこれに対処する方法がわかりません。これに関して従うべきベストプラクティスはありますか？レガシーコードが大量にあるシステムでこれを処理する方法に違いはありますか？

13 version-control  refactoring  legacy 

詳しく説明すると、1人のプロジェクト（チームのソース管理、ドキュメント、ビルドなど）を実行している間に配置する必要があると考える人々と、2人目が来るまで何をする必要がないかを知ることに興味があります。プロジェクトに。 このシナリオを経験したことがある人なら誰でも、彼らの洞察に感謝します。

13 project-management  version-control  development-process  documentation  builds 

私の状況の紹介 私は小さなWeb開発会社で働いています。私を含む4人のASP.NET開発者のチームがあります。ほぼすべてのプロジェクト（98％以上）は1人のプロジェクトで、完了までに1〜4週間かかります。ソースまたはバージョン管理は使用しません。唯一のものは、すべてのプロジェクトの最新のソース（==ライブアプリケーションのソース）を含むローカルサーバー上の共有フォルダーです。 まれに、同じプロジェクトで複数の人と作業する必要がある場合は、... Beyond Compareを使用します。1日に1、2回、開発者はお互いにコンパイルするバージョンがあるかどうかを尋ね、Beyond Compareを使用してコードを同期します。2人しかプロジェクトに取り組んでいない場合、これは「かなりうまく」機能しますが、3人目の開発者がプロ​​セスに入るとすぐに、管理不能なゴミになります。特に誰もがデータベースに変更を加え始めたとき。 私（および仲間の開発者の1人または2人）は、上司にGit、Mercurial、TFSなどの何らかの形式のソースおよびバージョン管理の使用を開始するように何度も言っています（私たちの上司は非常にマイクロソフトです）。残念なことに、上司はソースとバージョン管理システムに切り替えるメリットを認識していません。なぜなら、彼の目ではすべてがうまく動作し、新しいシステムのセットアップと全員の確認に時間とお金を費やしたくないからです。使い方を知っています。利点（コラボレーションの簡素化、アプリケーションのさまざまなバージョン、コードを変更するより安全な方法など）を彼に説明した後でも、彼はそれが必要だとは考えていません。 4人の開発者のうち、2人（私を含む）のみがソース管理（Git）の経験があります。そして、その経験は非常に限られています。Githubリポジトリーをコンピューターにクローンし、いくつかの変更を加え、コミットしてGithubにプッシュする方法を知っています。それでおしまい。 問題/懸念の説明 数週間以内に、私たちの標準のためのかなり大きなプロジェクトに取り組み始めます。おそらく、2〜3人の開発者がそれを完了するのに数か月かかります。私はプロジェクトリーダー（プロジェクトマネージャーおよびリードデベロッパー）になり、すべての責任を負います。Beyond Compareアプローチには問題がありますが、私の責任となるこの大きなプロジェクトでこの道を歩きたくありません。 私たちができることを疑うので 独自のGitサーバーをセットアップし、 みんなにGitを使って作業することを教え、 この大きなプロジェクトでGitをうまく活用し、 複数の人がソースやバージョン管理を使用せずに同じプロジェクトで共同作業できるようにする良い方法を知っている人がいるなら興味があります。 更新 皆の回答とコメントに感謝します。計画は次のとおりです。 開発者とミーティングを行い、すべての技術者がソース管理の実装について同じように感じるようにします。誰もが背後にいる場合、私たちはより強力なポイントを作ります。 アイデアを上司に提示し、ソース管理が本当に必要であることを彼に伝えます。 できるだけ早く実装してください。

13 development-process  version-control  teamwork 

開発中、Web開発中などでバージョン管理を使用してチームを関与させるための重要な方法は何ですか？ 私はそれなしで仕事をすることを拒否します。つまり、プロジェクトに関わるすべての人もそれを使わなければなりません。それはちょうど良い習慣です。 TowerのようなGUIは役立ちましたが、そのコンセプトは怒り（「私の仕事じゃない！」という態度）、ti病、またはまっすぐにそれを使用しない（FTPを使用する、開発や展開などのバージョン管理を回避する） ）。 編集：画像/ PSDを意味するだけではないことを少し明確にすべきでした。

13 version-control  teamwork 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 私の質問は、非常に小さなサイズの新しいチーム（たとえば2〜5）をブートストラップすることです。集中管理型または分散型のどちらの種類のチームに最適かは、どのタイプのバージョン管理が最適です。

13 version-control 

現在、私の会社は、次のように編成された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 

現在、多くのSVNおよびGitリポジトリ（それぞれ約50％）で構成される複雑で非効率的なビルドシステムがあり、これにはgitサブモジュールリポジトリも含まれます。また、全体を多かれ少なかれうまく管理する自家製のスクリプトもあります。 （クローズドソース）コードベースの主なポイントは、それが密結合されており、すべてのプロジェクトが同じバージョンで同時にリリースされることです。 これをよりシンプルなシステムと単一のVCSに移行し、gitサブモジュール、google Repo、monoreposなど、いくつかのオプションを検討しています。最終的なVCS​​はまだ定義されていません（それを義務付けるオプションを除きます）。svn、git、またはそれが私たちの状況により適している場合は他のものでもかまいません。 各ソリューションのプラスとマイナスをリストしようとしていますが、モノレポで現在抱えている大きな問題の1つは、外部エンティティと一部のモジュールを共有することは簡単に思えないことです。これらの人々がそれらのモジュールをチェックアウトして正常に動作できるようにしたいが、残りのレポジトリのコードや履歴にアクセスできないようにする必要があります。現時点で私たちが頻繁にまたは大々的にやることではありませんが、将来的にはそうなる可能性があります。 このような権限管理システムは、VCSシステムに存在しますか？ または、この問題を軽減する方法はありますか？

12 version-control  migration 

Gitで継続的な展開を行う場合、無視されたファイルをgitignoreでどのように処理しますか？これらのファイルはプライバシー上の理由で無視されます（つまり、GitHubなどの他のリモートリポジトリにプッシュされないようにします）が、無視されたファイルが継続的なデプロイメントリポジトリにプッシュされないため、アプリケーションは実行されませんソフトウェアが正しく機能するために必要です）。 人々は通常、これについてどのように対処しますか？この場合、Gitは無視されたファイルのため、継続的な展開の最適な候補ではありませんか？

12 version-control 

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

12 version-control  git  svn  workflows 

問題 私は約10人の開発者がいるソフトウェアプロジェクトに参加しており、Mercurialを介してソースコードを共有しています。リリースごとに開発ブランチと本番ブランチがあります。プロジェクトの過程で、1つのブランチ（v1など）からのソースコードが、ソフトウェアの以前のリリース（v2）のパッチブランチとメンテナンスブランチに入りました。 これにより、間違ったコミットのバックアウトに時間を費やしたり、コードが間違ったブランチに入ったことに気付かなかった場合、間違った（おそらくQAdでない）コードが間違ったブランチに到達してデプロイされます。 ブランチとマージの設計/方法 v1-test v1-patch1 v1-patch2 ^---------^-----------^ v1-prod / / \ \ -----------------------/ \ \ v1-dev \ \ \ --------------------------\ v2-dev \ \ \ ^-------^------------- v2-prod v2-test v2-patch1 したがって、準備ができたと判断されるまでリリース開発ブランチに取り組み、すべてのリリースとメンテナンスが行われる単一のテスト/ UAT /生産ブランチに分岐します。タグは、このブランチのリリースをビルドするために使用されます。v1のテスト中に、v2のブランチが作成され、開発者は新しい機能の開発を開始します。 起こりがちなのは、開発者がv2-devブランチの作業をv1-devまたはv1-prodにコミットすることです。さらに悪いことに、v2-devをv1-prodにマージします（または同様のミス）。 ほとんどの開発者は-prodブランチにアクセスしないように指示しますが、コードはまだ潜入しています。 v2は開発を開始したばかりですが、v1には問題を修正するための非常に大きなパッチがまだ残っている可能性があることに注意してください。つまり、v1は単に奇妙な小さなパッチを取得しているだけではありません。 これまでに試したこと ゲートキーパーを備えた、独立した-prodブランチがあります。-prodブランチはその名前を通じて警告を発するはずであり、ほとんどの開発者はそのブランチにいる必要はありません。これは実際に問題を軽減していません。 開発者の間でこの問題に対する意識を高め、彼らをより警戒させようとしました。繰り返しますが、これはあまり成功していません。 開発者が間違ったブランチにコミットする場合に考えられる考えられる理由 ブランチデザインが複雑すぎる 複数のブランチを並行して積極的に開発する。（プロジェクトは、雪崩モデルを使用するという症状を示します。） 開発者はDVCSを十分に理解していない ある程度関連性のある私が読んだ質問 私は間違ったブランチにコミットしないことについてこの質問を読みました。視覚的なキューに関する答えは役に立つかもしれません。しかし、私たちが経験している問題は、より根本的な問題の症状ではないと完全に確信しているわけではありません。 視覚的な手がかりを使って、それらをコマンドラインに簡単に組み込むことができますが、チームの約半数が日食を使用していますが、視覚的な手がかりを組み込む方法はわかりません。 質問 ソフトウェア、プロジェクト管理、またはガバナンスの形で、間違ったブランチへのコミットを減らして（理想的には停止して）時間を浪費したり、デプロイされたコードを汚したりするために、どのような方法を使用できますか？ 上記のように貢献していると思われる理由に関する特定のコメントをいただければ幸いですが、これは返信を制限するものではありません。

12 version-control  training  dvcs