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

SVNのバックグラウンドから来て、DVCSシステムでの作業に慣れるのが最も難しいのは、時限爆弾のように、コミットされていない変更をすべての人がどのように考えるかということです。 Mercurialでは、変更をフェッチしようとして、作業コピーにコミットされていない変更がある場合は、フープをジャンプして、入ってくる変更だけをマージする必要があります。ブランチを切り替えてみますか？それはあなたにすべてを棚上げすることを強いるでしょう、そしてあなたは反対側ですぐにそれをすべて棚から外さなければなりません。（SVNはこれらのシナリオのいずれでも問題ありません。） Gitもほぼ同じです。私はプロジェクトで別の開発者と並んで作業しており、彼のコミットの1つを私のフォークにチェリーピックしようとしました。私の作業コピーのコミットされていない変更が、彼のコミットで変更されたファイルとは完全に異なるファイルにあるため、許可されませんでした。 マージオプションすらありません。どうやら最初に変更を隠しておく必要があります！ 人がそのような極端な注意を払って完全に無害なものを扱うとしたら、私はそれを「恐怖症」と呼びます。それは精神障害と見なされるべき非合理的な恐怖です。しかし、GitとMercurialはインテリジェントで合理的な開発者の2つの異なるチームによって設計されたので、私が知らないことを彼らが知っているのかどうか疑問に思う必要があります。 コミットされていない変更に対するこの姿勢を正当化する技術的な理由はありますか？もしそうなら、なぜ問題の問題はDVCSにのみ存在するように見えるのですか？

10 version-control  dvcs 

App.configおよび同様のファイルでシークレットがソース管理されているいくつかのプロジェクトを継承しました。幸い、それは公開リポジトリではないため、リスクはそれほど深刻ではありませんでした。Azure KeyVaultなど、これを管理するためのより良い方法を検討しています。（しかし、この質問がその解決策に固有であるとは思わない。） 一般に、問題を解決するだけではないですか？たとえば、Azure KeyVaultでは、アプリIDとアプリシークレットが、ソース管理の対象外にしておく必要があるものになります。残念ながらこれがうまくいかない傾向の典型的な例を次に示します。他のアプローチも同様になり、APIキーまたはキーストアファイルを保護する必要があります。 Azure KeyVaultのような製品は、シークレットを個別の構成ファイルに保存し、それが.gitignoreまたは同等のものに含まれていることを確認するよりも優れており、意味のないほど複雑であるように思えます。このファイルは、必要に応じてサイドチャネルを介して共有する必要があります。もちろん、人々はおそらく安全にお互いにそれを電子メールで送信しません... 問題を解決するだけでなく、秘密を管理する方法はありますか？この質問には、明確に定義された単一の答えがあると思います。類推して、HTTPSが問題を解決するだけではないのかと尋ねると、答えはCAキーがOSと共に配布され、OSの配布方法を信頼しているので、私たちはそれらを信頼しているということです。（別の質問にする必要があるかどうか...）

10 version-control  code-security 

ソフトウェア開発に関連するドキュメントはたくさんあります。これらには、要件、設計ドキュメント、外部PDF、顧客ファイル、テスト手順などが含まれます。現在、これらのドキュメントは場所（wiki、「ネットワーク上の場所」、ローカル開発者のハードドライブ（！）、そしてさらに悪い場所）。 それらを追跡する最良の方法は何ですか？開発にはビジュアルスタジオ（2010）を使用しており、プロジェクトに非開発者が実際にいないため、それらをVS "ソリューション"内に保存して、ソース管理され、すべての開発者が普遍的にアクセスできるようにします。 ただし、VSは実際にこれを行うように構築されていないようです。ドキュメントファイルを編集する場合、ビルドプロパティが[なし]、[コピーしない]でセットアップされている場合でも、VSはソフトウェアを再構築してから再度実行する必要があります。ソリューション内に「ドキュメントプロジェクト」を作成する方法はありません。（これには空のC＃プロジェクトを使用します）。Visual StudioとWord / Excelフラットは、ソース管理がうまく機能しません。チェックインされたファイルを表示して、最初にファイルを閉じてプロジェクトに移動し、変更を行う前に手動でチェックアウトしないと、変更を行うことはできません。遅くても退屈な作業です。 とにかくこれは私たちのチームが考え出した最高のものですが、私は本当にもっと良い（無料の）ソリューションがあったらいいのにと思います。

10 version-control  documentation 

私は、役割と責任、特に開発ブランチからトランク（またはメイン）へのマージの責任者に関する「ベストプラクティス」を探しています。基本的に私は自分の大義を助けるための弾薬を探しています。 私が直面していることを説明させてください。私は特定のアプリケーションのリード開発者（所有者）です。私たちの会社は最近、VSS（私のアプリケーションが保存されているVSSデータベースの管理者でした）からTFS（私たちの「運用」チームによって作成された開発ブランチに対する権限しか持っていません）に移行しました。以前の仕事ではTFS管理者でしたので、TFSとMSBuildの使い方を知っています。 使用されている分岐およびマージ戦略に問題はありません（メインブランチ、必要に応じてバグ/プロジェクト開発ブランチが作成され、メインにマージされてからリリースブランチに昇格されます）。私が抱えている問題は次のとおりです。 自分でブランチを作成することはできません。「オペレーション」チームメンバーにブランチを作成させるには、TFSタスクを作成する必要があります。 Mainから開発ブランチにマージできません。「オペレーション」チームメンバーがマージを実行するようにTFSタスクを作成する必要があります。「運用担当者」は開発者である場合とそうでない場合があるため、チームが変更を「踏まない」ことを期待しています。彼がマージしているコードに関する知識はほとんどありません。 開発からMainにマージできません。繰り返しますが、 "ops guy"にマージを実行させるには、彼が正しく実行することを期待して、TFSタスクを作成する必要があります。次に、別のTFSタスクを作成してブランチにマージし、開発者以外がMainにマージすることで発生した問題を解決できるようにします。 MSBuildスクリプトを作成または編集できません。ここでも、MSBuildの新機能である「ops」チームと協力して、最も基本的なビルドタスクのみを実行できるようにする必要があります。（複雑なことは何も忘れてください、またはカスタムタスクを天国で禁止してください）。 MSBuildスクリプトを実行できません。繰り返しますが、「ops」チームだけがこれを行うことができます。 このすべてをオフにするには、通常、要求されたタスクを実行する「オフショア」リソースであるため、早朝に（ブランチ/マージ/ビルド）へのタスクを作成しても、完了しない可能性があります。その夜まで。 これで、リリースブランチを維持する「運用」チームに問題はありません。彼らがしていることはすべて、（基本的に）Mainから最新バージョンを取得し、それをリリースブランチにプロモートすることです。"Main"が安定していて準備ができている限り、リリースブランチは適切です。 私の意見では、テクニカルリード（Iなど）は、トランク（「メイン」）の保守と、開発ブランチとの間のマージを担当する必要があります。チームリーダーには、MSビルドスクリプトを生成して、統合テスト環境にビルドおよびデプロイする機能も必要です。 私のケースを証明するのに役立つベストプラクティスドキュメントを誰かに教えてもらえますか？私が行ったすべての検索で、分岐とマージの手法に関するベストプラクティスのみが判明しました。WHOについての言及では、分岐/マージを実行すべきではありません。

10 version-control  team-foundation-server  branching 

BitBucketの機能と価格設定（最大5ユーザーまで無料）のおかげで、何が問題なのだろうと思いました。結局のところ、無料のランチなどはありません。 BitBucketは、（TOSに従って）販促資料に自由に含めるハンサムな男のほかに、私の無給の参加から抜け出しますか？

10 version-control 

私は約9か月前にSVNの使用を開始しましたが、控えめに言ってもそれは画期的なことです。でも、まだ少し迷ってる気がします。アプリケーション開発を本当に強化するために利用しなければならないことがまだまだたくさんあるように思います。 例えば なんらかの「サブリポジトリ」などへの揮発性/主要な変更を検疫できるようにしたいと思います。大きな変更が、非常に緊急のマイナーなバグ修正を妨げていることがわかりました。不完全なコードや壊れたコードをプッシュせずに1つの単純な更新をプッシュするにはどうすればよいですか？

10 version-control 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 5年前休業。 Gitはオープンソースプロジェクトに最適です。しかし、私は疑問に思っていました。1年間のプロジェクトに取り組んでいる20人のプログラマーがいる企業にとって、どのソース管理システムが望ましいのでしょうか。私が聞いたところによると、Gitはプルを使用しています。メイントランクで変更を取得するために他の誰かを経由する必要があるのは望ましいことではないでしょうか。特に全員が同時に作業している場合はどうでしょうか？ それは私が疑問に思っていた例の1つにすぎません。私はSVNの使用方法を知っていますが、すべての作業がPHPで行われ、通常はスタンドアロンの1週間のプロジェクトだったため、最後の仕事でさえプロジェクトで使用しませんでした。私はローカルコード用のSVNを持っているだけで、他の人と一緒に使用する必要はありませんでした。 それでは、優れたソース管理とは何ですか。具体的にはなぜこれに適しているのでしょうか。

10 version-control 

だから私はバージョン管理にとても慣れていて、私のbashプロファイルのバージョンの追跡を開始しようと考え~/.bash_profileました。GitHubでさまざまなエイリアスなどを共有できるという追加の利点があります。 私の.bash_profileファイルをホームディレクトリに残す必要があると仮定すると（通常のファイルのように単独で追跡するためにディレクトリにラップすることはできません）、これを行うための最良の方法は何ですか？ホームディレクトリでgit repoを初期化したくないので、存在する他のすべてのファイルを無視する必要があります。 では、何が良い解決策となるのでしょうか？ 別のディレクトリにコピーを作成し、時々それを更新/コミットできると思いますが、実装されたディレクトリ内の単一のファイルをバージョン管理するための良い方法があるかどうか知りたいですか？

10 version-control  git  bash 

私たちは1人の開発者と、すべてのコードを含む1つのsvnリポジトリから始めました。 ^/foo/trunk/module-a ^/foo/trunk/module-b ^/foo/trunk/module-b/submodule-b1 ^/foo/trunk/website1 （当時、これは大きな改善でした）。これが少し成長する機会を得た後、循環依存、テストスイートの遅延、コードの再利用に関する一般的な問題が発生し始めました（たとえば、website1の機能セットが他の汎用モジュールaに侵入したため）。 コードベースをモジュール化して、まもなくgitに移動することを期待して（そしてgitがsvn mega-reposを好きではないところを読んだことを期待して）、もっと細かい構造に移行しました： ^/module-a/trunk/ ^/module-b/trunk/ ^/module-b/trunk/sumbmodule-b1 ^/earlier-sub-sub-sub-module-c/trunk etc. (about 120 such modules) これは概念的に素晴らしかった。モジュール化されたコードの増加、テストスイートの高速化、ドキュメント化の容易化など。より一般的なコンポーネントの一部をオープンソース化し、すべてのモジュールをpipインストールpip install -e .可能にしました（developmentvirtualenv にインストールするために使用）。 ^/srv/trunkランタイム環境のフォルダ構造を含むリポジトリを作成しました。^/srv/trunk/libモジュール、/srv/trunk/src残りの部分^/foo/trunk、^/srv/trunk/wwwウェブサイトなど そして最後に（非常に長い時間前に使用したperforceからのアイデア（[ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html]））を作成し、「vcs-関連するすべてのリポジトリと、それらを開発環境にチェックアウトする場所と、それに対応するコマンドをリストしたテキストファイル。たとえば、vcs-fetc行： svn srv/lib/module-a ^/module-a/trunk いずれかを引き起こします（初回） cd /srv/lib && svn co ^/module-a/trunk module-a または（後で） cd /srv/lib/module-a && svn up そして同様にgithub repos（私たち自身と変更された/変更されていないベンダーパッケージの両方）についても同様です。 本番環境の作成には同じvcs-fetchプロセスを使用しましたが、vcs-fetchを実行した後、prodで実行されていたバージョンを知る方法がないことはすぐにわかります。 mega-repoを使用すると、トランクから製品を更新する前にリビジョン番号をメモするだけで済み、戻るのは簡単でしたsvn -r nnn up .。svnとgitの両方のコード（およびhgの1つのモジュール）と〜120リポジトリでは、これを行う方法は明らかではありません。 …

9 version-control  deployment 

だから私はこの質問を読んでいましたが、参照されていないコードを削除する必要がありますか？ 後で必要になった場合に備えて、コードは参照用にソース管理されているため、参照されていないコードを削除するというアドバイスがありました。 この削除されたコードをどのように整理して、後のバージョン（または他のプログラマー）が後で見つけられるようにしますか？どういうわけか、別のブランチを作成するか、それをソース管理でタグ付けしますか？ 私はこれまでソース管理から削除されたコードを復活させたことはありません。私はほとんどそれを使って、まだ生きているコードの変更を追跡しました。他の誰かの実験的な作業が含まれる前にブランチを参照したので、トランクで削除されたコードの興味深いセクションをマークするための良い方法でしょうか？

9 version-control 

私は私たちのウェブサイトプロジェクトをバージョン管理するためのより良い方法を考えています。私はフロントエンドの開発者にすぎないので、VCSに関する深い知識はありません。 ワークフローは変化しており、過去のバージョン管理の習慣は時代遅れになっています。主な問題は、各Webサイトにフロントエンドファイルの2つの配列があることです。 開発環境（少ないファイル、非圧縮のjs、イメージなど）。「不正な」ビルド環境（すべて圧縮され、人間が読み取れないもの）。 ただし、ソースファイルを含むWebサイトを販売することはできません。まあ、それは完全に正しくないと感じています。 2つのリポジトリを持つソリューションがあります。1つはビルド、1つは開発で、gulpがビルドファイルをビルドディレクトリに送信します。しかし、それを維持するのは面倒であり、小さな会社では、それはそれほど素晴らしいとは思いません。それは多くのレポを作成し、人々はいくつかのレポで、時には1つのsvnレポでさえも管理しなければならず、問題が発生します。 したがって、同じsvn内のソースファイルとprodファイルの1つのリポジトリを持つソリューションもあります。ただし、Webサイトがローカルの開発サーバーから本番サーバーに移動するときに、ソースファイルを削除する必要があります（そのため、単一のリポジトリには、その場所、開発または本番に基づいて異なるファイルがあります）。私が聞いたことから、それは良くありません バージョン管理システムに関して、不適切なフロントエンドワークフローを管理する正しい方法は何ですか？

9 web-development  version-control  development-process  svn  front-end 

私はGitの広い世界に慣れていません。私はマニュアルを読んで練習してきましたが、検索してみて理解できなかったいくつかの点について混乱しています。 不思議なんだけど： プロジェクト（最初のコミット後）で、ソースファイルをステージングする適切なタイミングはいつですか？コミットする直前？追加/削除または変更した直後ですか？ ファイルが2つのコミットの中間でステージングされ、その後変更された場合、Gitはどうなりますか？それが述べられたときのコンテンツの変更とそれ以降の内容について注意する必要がありますか？ 新しいファイルを作成し、それをステージングしてから削除したい場合、Gitが「-f」フラグを使用するように求め、単純な「git -rm file.ext」が機能しないのはなぜですか？ 「ステージの意味」など、Gitのマニュアルやその他のチュートリアルのさまざまな主題を読みましたが、前述のように、上記のことはまだわかりません。 ですので、できれば、自分の言葉と例を使って質問に答えてください。そうすれば、理解しやすくなるでしょう。 ありがとうございました。

9 version-control  git  versioning 

.NET Frameworkでは、ローカライズされた文字列はXMLファイル（または複数のファイル）にあります。これらのファイルはプロジェクトの一部であり、他のソースコードファイルと同様にソース管理にコミットされます。通常、Visual Studioは、これらのファイルをテーブルとして表示し、ローカライズされた文字列を編集するために使用されます。 私は小さなチームで、多言語インターフェースが必要な製品を扱っています。 開発者として、翻訳が不正確である可能性を考慮して、ローカライズされた文字列を両方の言語でドラフトします。 チームの別の人（開発者以外）が両方の言語でコンテンツをレビューし、必要に応じて修正します。 現在の問題は、開発者以外の人はソース管理もIDEも使用しないことです。これは、この人にとっては面倒で困難（バージョン管理は開発者以外には難しい）であるためです。 別の解決策は、ローカライズされた文字列をExcelファイルとしてエクスポートし、このユーザーがExcelを確認するのを待ってから、変更された文字列を再インポートすることです。ここでの注意点は、他の文字列を作成したり、既存の文字列の名前を変更したりする可能性があるため、ローカルバージョンとレビュー済みの文字列を比較することが困難になることです。 何をすべきか？ 他のチームではどうなりますか？

9 version-control  team  collaboration 

Drupalのコンテンツ同期モジュールに取り組んでいます。ウェブサイトに配置され、ウェブサービスを介してコンテンツを公開するサーバーモジュールがあります。別のサイトにあり、定期的にコンテンツをフェッチしてインポートするクライアントモジュールもあります。 サーバーはDrupal 6で作成されます。クライアントはDrupal 7で作成されます。Druapl7バージョンのサーバーが必要になるでしょう。そして、来年リリースされると、クライアントとサーバーの両方のDrupal 8バージョンが必要になります。 私はgitとソース管理にかなり慣れていないので、gitリポジトリをセットアップするための最良の方法は何だろうと思っていましたか？インスタンスごとに個別のリポジトリがある場合、つまり、次のようになります。 Drupal 6 server = 1 repository Drupal 6 client = 1 repository Drupal 7 server = 1 repository Drupal 7 client = 1 repository etc または、サーバー用のリポジトリとクライアント用のリポジトリを用意し、各Drupalバージョンのブランチを作成するほうが理にかなっていますか？ 現在、私は2つのリポジトリを持っています-1つはクライアント用、もう1つはサーバー用です。

9 version-control  git  drupal 

3組のテストスイートがあります。 実行に数時間しかかからない「小さな」スイート 複数時間かかる「中」のスイートで、通常は毎晩（毎晩）実行されます 実行に1週間以上かかる「大きな」スイート 短いテストスイートもたくさんありますが、ここではそれらに焦点を当てません。 現在の方法論は、トランクへの各コミットの前に小さなスイートを実行することです。次に、ミディアムスイートが毎晩実行され、午前中に失敗したことが判明した場合は、昨日のコミットのどれが原因であるかを特定し、そのコミットをロールバックして、テストを再試行します。大規模なスイートでは、同様のプロセスが、毎晩ではなく毎週のみ行われます。 残念ながら、ミディアムスイートはかなり頻繁に失敗します。つまり、トランクが不安定になることがよくあります。これは、変更を加えてテストするときに非常に煩わしいことです。トランクからチェックアウトするとき、それが安定していることを確実に知ることができず、テストが失敗した場合、それが私のせいかどうかを確実に知ることができないので、それは迷惑です。 私の質問は、トランクを常に最高の状態に保つような方法でこれらの種類の状況を処理するためのいくつかの既知の方法論がありますか？例：「特別な事前コミットブランチにコミットし、夜間が経過するたびにトランクを定期的に更新する」。 そして、それがSVNのような集中化されたソース管理システムであるか、gitのような分散型システムであるかは重要ですか？ ちなみに、私は物事を変更する能力が限られているジュニア開発者ですが、私が経験しているこの痛みに対処する方法があるかどうかを理解しようとしています。

9 testing  version-control  development-methodologies  branching