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

新しい開発を開始する前にバージョンをバンプするプロジェクトもあれば、リリースにタグを付けるときにバージョンをバンプするプロジェクトもあります。 どちらのアプローチが優れていますか？ 新しいフェーズの開始時にバージョン番号が変更されていない場合、開発者はバージョン番号を変更するのを忘れて、プログラムをリリースするだけです。 リリースにタグを付ける前にバージョン番号が変更された場合、バージョン番号（タグとMakefile / AssemblyInfo.cs）は一致しません。 git describe 現在のリビジョンがv1.2.3.4より後の場合、v1.2.3.4-15-g1234567が表示されることがありますが、ファイルはすでにv1.2.3.5に変更されています。

9 version-control  versioning 

私は初心者の開発者であり、プロジェクトのニーズを満たすために、GITやSubversionなどの専門的なツール（これらのツールについて十分に理解していません）をどのように使用するのか、最初から疑問に思っていました。彼らがそれを使用する場合、どのようにそのようなものを設定しますか？ 私のアプリケーションはそれほど大きくなく、まだチームで作業していません。それらは私にとって非常に役立ちますか？ このサイトにはツールの使用方法に関する質問がありますが、初心者のサポートが必要です。

9 version-control  git  svn 

仮定して： チームは一元化されたバージョン管理を使用しています。 完了までに数日かかる大きな機能に取り組んでいますが、ビルドが中断するため、それより前にコミットすることはできません。 チームメンバーは、作業中のファイルの一部を変更する可能性がある何かを毎日コミットします。 これは一元化されたバージョン管理であるため、ある時点でローカルチェックアウトを更新する必要があります：新しい機能をコミットする直前に少なくとも1回。 コミットの直前に1回だけ更新すると、チームメイトによる他の多くの変更が原因で多くの競合が発生する可能性があり、一度にすべてを解決するのは苦痛の世界になる可能性があります。 または、頻繁に更新することもできますが、毎日解決する競合がいくつかあるとしても、少しずつ簡単に解決できるはずです。 頻繁に更新することを常にお勧めしますか？

9 svn  version-control  cvcs 

トランク、公式ブランチ、ほとんどのサブプロジェクト/非公式ブランチのメインバージョン管理システムとしてGITを使用するプロジェクトに取り組んでいます。したがって、私は自分のブランチでGITを使用して、コミュニティの残りのメンバーが知っているシステムを使用して私のブランチにアクセスできるようにしたいと考えています。 しかし、私は公式ブランチと非公式ブランチの両方に重なるプロジェクトの一部と、トランクに入らないいくつかのパッチに取り組んでいます-そのため、パッチを個別に保ち、すべてで使用できるようにする必要がありますトランクで使用するためのブランチと選択パッチ。これは当然、Mercurialキューの使用に傾いています。 自分のローカルリポジトリにmercurialを使用できないが、全体をGITとMercurialがホストするリポジトリの両方にプッシュする理由はありますか？むしろ、そうしない理由があるのではないかと思います。

9 version-control  git  mercurial 

バックグラウンド 私はgit過去にVCS（主に）を使用して多くの既存のプロジェクトを管理してきましたが、うまく機能します。通常、既存のプロジェクトでは、全体的な機能を最適化または変更するコードを変更するたびにチェックインします（変更するすべての行ではなく、適切な手順で私が意味することを知っています）。 問題 私があまり練習していないことの1つは、新しいプロジェクトを作成することです。私はおそらく非常に大きく成長する自分自身の新しいプロジェクトを開始する過程でんだけど、私はそこにあることを発見していますたくさん行うと、最初の数日/時間/週/期間までに変更する多くの製品が実際に最も基本的な形で機能するまで。 既存のプロジェクトの場合と同様に、プロセスの各ステップでチェックするポイントはありますか？まだ機能していないので、私は自分が加えた変更でプロジェクトを中断していません。現時点では、毎日の終わりにコンピュータを離れるとき、単にVCSをバックアップとして使用しています。 私の最初の数回のコミットは、「基本的なディレクトリ構造」や「作成されたDBテーブル」のようなものでした。新しいプロジェクトを開始するときにVCSをどのように使用すればよいですか？

9 git  svn  mercurial  version-control 

私は、共有サーバーや2つのマシン間のネットワーク接続を使用せずに、2つのマシンで個人プロジェクトを開発しています。 一般的なバージョン管理システムは、共有リポジトリとしてのポータブルストレージ（USBフラッシュデバイスなど）の使用を確実にサポートしていますか？

9 version-control 

多くのソフトウェアショップがバイナリをソース管理下に置いていることを知っています。しかし、私たちのショップは、DirectXランタイム、CUDA、nVidia Optixなど、フレームワーク全体をリポジトリに格納するようになりました。 開発マシンのセットアップをより簡単にすると言われています（おそらく最新のものを入手してコーディングを開始します）。ただし、リポジトリが大幅に肥大化し、無関係な履歴が発生します。 このような使用パターンを見たことがありません。それは良い習慣だと思いますか？ [編集：]分離されたサードパーティのバイナリをソース管理することに問題はありません。質問は、通常10以上のバイナリで構成されるフレームワークランタイム全体に関係しています。極端な例として、Windows SDKを取り上げます（これはリポジトリに保持しません。感謝しますが、原則として違いはありません）。

9 version-control 

/software/109817/superior-refusing-to-use-subversionを参照してください 私の質問も同様ですが、私のシナリオの主な違いは次のとおりです。 PHPとウェブ技術を使用して、新しいプロジェクトをゼロから始めています。私のやり方があれば、最初から採用するので、開発にダウンタイムはありません。 私の開発チームは私と私の上司で構成されています。私たちは比較的小さな会社の「IT」部門です。 Webアプリは、ソース管理がまったくないレガシーアプリケーションを置き換えます。地理的な法的要件の違いにより、（私が採用される前に）アプリをバージョンごとに7つの完全に別個のディレクトリにフォークすることが決定されました。その後、さまざまな開発者がさまざまな場所でさまざまなことを行いました。それら全体にパッチを当てるということは、まあ、もっとうまくできると思います。それが私が投稿している理由だと思います。 メールから直接貼り付けた上司の提案： 更新はSUBMISSIONSフォルダーにパッケージとして送信する必要があります。パッケージには、関連するすべてのファイルと、更新の説明、含まれているすべての新しいファイルのリスト（説明付き）、および変更の詳細を含むすべての変更されたファイルのリストを含む「UPDATE.NFO」ファイルが含まれている必要があります。 更新パッケージは、個々の要素に焦点を当て、意図された目的から逸脱しないようにする必要があります。コードはモジュール化され、可能な限り再利用できるように設計する必要があります。 提出されたすべてのパッケージは、提出後すぐに各開発者のテスト環境にインストールする必要があります。各開発者は、新しい追加を確認し、本番環境へのインストールに関する懸念を表明します。標準のパッケージアップデートは、本番環境にロードされる前に、このレビュープロセスのために最低3営業日保持される必要があります。優先度の高い更新/修正では、この要件をスキップできます。 ソース管理が発明された理由は、それをすべて自動化するためですよね？それが私が大学で使用したものだから、私は転覆を提案しました。「コードがめちゃくちゃになる」（つまり、バイナリマジックを使用しており、明確に読み取ることができない）ため、ボスはSubversionを好みません。一度試してみましたが、Windowsで使用しようとすると、奇妙な小文字/大文字のエラーが発生し、ファイルをチェックアウトできませんでした。それがsubversionだけなのか、それとも不快なすべてのソース管理製品なのかはわかりません。 では、上司に対してどのような議論をするべきでしょうか。それとも彼は正しいのですか、そして奇妙なバグから私たちのすべての仕事を失う危険があるかもしれませんか？ または私は完全に間違っていますか？私の状況ではソース管理が本当に必要ですか？これは私たちが話している主要なビジネスクリティカルなソフトウェアなので、間違いなく巨大になるでしょう。しかし、開発者は2人だけです（現在）。 さらに、彼を納得させることができない場合、私だけにそれを使用することに意味がありますか？私は実際にsvnを使用した非常に限られた経験を持つ誰かとして話しています。私が本当に知っているのは、チェックアウトとコミットだけです。個人の開発作業に役立つソース管理の機能（svn以外の製品が含まれる場合があります）は何ですか？ 「別の仕事を取得する」コメントはありません。それは議論に役立たない。

9 version-control 

私の職場は最近Gitに切り替わり、私はそれを愛しています（そして嫌いです！）。私は本当にそれを愛し、それは非常に強力です。私が嫌う唯一の部分は、時々それがあまりに強力であるということです（そして多分少し簡潔で混乱しています）。 私の質問は... Gitはどのように設計されましたか？短時間で使用するだけで、他のバージョン管理システムでは処理できなかった多くのあいまいなワークフローを処理できるという感じがします。しかし、それはまた、下にあるエレガントな感じです。そして速い！ これは、Linusの才能に一部疑いの余地はありません。しかし、私は疑問に思っています、gitの全体的なデザインは何かに基づいていますか？BitKeeperについて読みましたが、アカウントは技術的な詳細が不十分です。圧縮、グラフ、リビジョン番号の削除、分岐、隠蔽、リモートの強調...それはどこから来たのですか？ ライナスは本当にこれを公園から追い出して、ほとんど最初の試みで！学習曲線を過ぎてから使用すると非常に便利です。

9 design  version-control  git  linux 

私のアプリケーションには、バージョン管理に保存されているアイコンファイルがあります。明日はアイコンを変えることにするかもしれません。私は、アイコンファイルの2つの可能な命名規則の間で議論しています： ファイル名は固定してください（例：application.ico）。 ファイル名に画像の性質を反映させます（例：happyface.ico）。 オプション1は、ファイルが何であるかを言いません。大きく異なる2つの画像が同じものの「バージョン」がどういうわけか異なるという錯覚を与える可能性があります。オプション2では、新しいファイルを追加して古いファイルを削除するだけでなく、新しいアイコンのファイル名を反映するようにリソースファイルを変更する必要があります。 関連するが異なる角度で： ヘッダー画像のあるウェブサイト。ファイル名はheader.jpgまたはsunrise-family-smiling.jpgですか？ 画像ファイル名は、アプリケーションでの機能やコンテンツを反映する必要がありますか？このためのベストプラクティスは何でしょうか？

9 version-control  naming  binary 

これは、大規模なチームとの共同作業の厄介な要素になっています。チェックインを管理し、機能の競合を防ぎ、ソース管理で依存関係を適切に管理するにはどうすればよいですか？ 現在、私の職場ではTFS 2008を使用しており、12月初旬にTFS 2010に移行しています。まず、どのソース管理も他より優れていますが、複数のチェックインを防ぎ、ソース管理履歴全体をロールバックするのに役立つアプローチは誰ですか？揮発性トランクは、新しい機能を実装してトランクにマージし直すときに分岐または分岐する最善の方法ですか？ 他の人の経験や、おそらくソース管理を管理するためのいくつかのベストプラクティスをぜひ聞きたいです。

9 version-control 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 4年前休業。 私は最近、サブバージョンを使用して、私のWeb開発でバージョン管理の作業を始めました。これは、開発したファイルの管理には最適ですが、データベースに加える必要がある変更には何もしません。私の知る限り、私が取り組んでいるサーバーにはDB管理システムがなく、おそらく何もインストールすることができません。この種の環境でDBを管理するには、どのようなオプションがありますか？

9 database  version-control 

私は、Mercurialをバージョン管理システムとして機能させるための準備を進めています。驚いたことに、VCSを使用したことがないので、これは誰にとっても大きな取引です。バグを管理者の耳に入れて数か月した後、彼らはついに光を見て、共有フォルダーのネットワークで作業するよりもはるかに優れていることに気付きました。 これを展開する過程で、私は自分のものを管理するためのさまざまな戦略を考えており、私は「中央」リポジトリとしてBitbucketを使用することに傾倒しています。Bitbucketのプロジェクトはもっぱらプライベートプロジェクトであり、誰もがそこからプッシュおよびプルします。 私はさまざまな提案を受け入れていますが、誰もが同じような設定をしていますか？もしそうなら、あなたはどんな警告に遭遇しましたか？

9 version-control  teamwork  mercurial 

24時間体制で、会社のバージョン管理の戦略を考えてみます。現在はSVNを使用していますが、構造はありません-基本的にトランクしかなく、それにコミットするだけです。最近、開発マネージャーが「タグ」として機能する2番目のリポジトリーを開始しましたが、同じリポジトリーの一部ではなく、完全に別のリポジトリーであるため、「トランク」と手動でマージする必要があります。実際には、「Dev」と呼ばれるフォルダーが1つだけあります（実際には「Dev」フォルダーは日付によって異なりますが、「Dev」だけがメインのフォルダーです）。他のすべてのプロジェクト。プロジェクトごとに構成されているわけではなく、ブランチ/タグ/トランクなどの概念はありません。最初に設定した人（長い間、もちろん）SVNをセットアップする方法をまったく知らないようで、それ以来、何かを壊すことを恐れて適切に行う方法を学ぶことに誰も悩まされていません。CIは使用していません（残念ながら自動テストも行っていません）。 まず、プロジェクトごとに分離する必要がありますか？たとえば、2つのASP.NET Webサイト（Webアプリケーション、Webサイトではない）、Webサービス、すべてのテーブルスクリプトとストアドプロシージャの展開フォルダー、外部プロジェクト用の2つのコマンドラインクライアントWebサイトと、共通のビジネスオブジェクトなどを含む共有フォルダー。これらはそれぞれブランチ/タグ/トランクの設定を備えた独自のプロジェクトであるか、または次のようである必要があります。 dev/ branches/ tags/ trunk/ Site1/ Site2/ WebService/ SharedCode/ すべてのブランチがあり、すべてにDevフォルダー全体のコピーがありますか？共有コードライブラリと少なくとも1つ（通常は両方）のWebサイトにも変更を加える必要がある状況がよくあるため、このアプローチは飲み込みやすいかもしれません。 次に、開発サーバーとライブサーバーへの定期的なリリース（用語では "プッシュ"）を行います。私がこれを処理する最良の方法を読んだことから、すべての開発はtrunk /に行き、ブランチは「一時的」であり、トランクに影響を与える可能性のある新しい機能を追加するために使用され、タグはリリース用です？それで、毎月プッシュしてみましょう、そして私は真新しいモジュールに取り組んでいます。トランクを分岐し、その分岐をコードに使用して、コードの記述とテストなどを行います。モジュールが完成したら、トランクにマージして（おそらくブランチを削除して）、デプロイの準備ができたら、タグを付けます（「May2011」としましょう）。公開後にバグ修正がある場合は、May2011タグで修正され、トランクにマージされます（トランクも修正されます）。そして、May2011は修正により再び押し出されますか？これはタグ付けの意図ですか？

9 version-control  svn 

これが私の話です。私の同僚の1人がすべてのコードをレビューするために使用し、リビジョンシステムにホストされています。私は彼が所属するパーツの変更の適切なレビューについて話しているのではありません。彼はコードファイルをファイルごとに、行ごとに監視します。すべての新しいファイルとすべての変更。私はスパイされているように感じます！ 私の推測では、コードがすでに制御システムにホストされている場合は、少なくとも実行可能として信頼する必要があります。私の質問は、多分私は偏執狂的過ぎて、お互いのコードをレビューする練習は良いですか？ PS：私たちはたった3人の開発者からなるチームであり、私たちがもっと増えれば、同僚が私たちが書くすべてのコードをレビューする時間がないことを恐れています。

9 programming-practices  version-control  collaboration