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

私はオフィスのデスクトップでプログラムしますが、時には自宅のラップトップの別の部屋で、さらには家から離れていてもプログラムします。必要なのは、必要に応じて作業を一方から他方に自動的またはオンデマンドで同期するシステムです。 私はホームネットワークを設定していません。それはできると思いますが、おそらく別の取締役会にとっては質問でしょう。ソースコードをクラウドに保持するようなシステムについて考えてきましたが、これを開始するのに十分な知識がありません。これを行うには、一種の無料または安価な方法が必要です。 私は.NET（実際にはWindows Phone 7）で働いています。

23 version-control 

コードのフォーマットが重要です。インデントさえ重要です。そして、小さな改善よりも一貫性が重要です。ただし、プロジェクトには通常、1日目から明確で完全で検証可能で強制的なスタイルガイドがなく、大きな改善がいつでも届きます。たぶんあなたはそれを見つける SELECT id, name, address FROM persons JOIN addresses ON persons.id = addresses.person_id; /として書かれた方が良い SELECT persons.id, persons.name, addresses.address FROM persons JOIN addresses ON persons.id = addresses.person_id; クエリに列を追加する作業中。これは、コード内の4つのクエリすべての中で最も複雑なものか、数千ものクエリの中でささいなクエリかもしれません。移行がどれほど困難であっても、価値があると判断します。しかし、主要なフォーマットの変更全体でコードの変更をどのように追跡しますか？あきらめて「これが私たちが再び開始するポイントです」と言うか、リポジトリ履歴全体のすべてのクエリを再フォーマットすることができます。 Gitのような分散バージョン管理システムを使用している場合は、最初のコミットに戻り、そこから現在の状態に変更できます。しかし、それは多くの作業であり、作業中は他のすべての人が作業を一時停止する必要があります（または、すべてのマージの母親に備える必要があります）。すべての結果の中で最高のものを提供する履歴を変更するより良い方法はありますか？ すべてのコミットで同じスタイル 最小限のマージ作業 ？ 明確にするために、これはプロジェクト開始時のベストプラクティスに関するものではなく、大規模なリファクタリングがGood Thing™と見なされたが、追跡可能な履歴が必要な場合に何をすべきかを示しています。バージョンが常に同じように動作することを保証する唯一の方法である場合、履歴を書き換えることは素晴らしいことではありませんが、クリーンな書き換えの開発者の利点はどうですか？特に、書き換えたバージョンが元のバージョンとまったく同じように機能することを保証する方法（テスト、構文定義、またはコンパイル後の同一のバイナリ）がある場合はどうでしょうか？

23 version-control  coding-style  indentation 

私たちは職場で優れたソース管理およびプロジェクト管理ソリューションを探しています。GitHub組織とプライベートリポジトリを作成することを提案しました。私は多くの理由でGitHubが大好きですが、これはGitHubについてではありません（実際、同僚は競合するプラットフォームを支持してポイントを提示するつもりです）- 私たちのプライベートコードをオンラインで保存することです。 これが良いアイデアかどうかを理解しようとしています。サーバーコストの必要性を（少なくとも直接）排除し、コードの検索（すべてがオンライン）を容易にするため、間違いなく有利に思えます。 しかし、私たちのチームは未定であり、私の質問に私を導きます。この決定を下すために、私たちは何を考慮すべきですか？

22 version-control  cloud-computing  closed-source 

などの製品バージョンは、v1.0.0.100ソフトウェアの固有の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終パッケージ/ビルド/バイナリバージョンを維持するための2つの方法があります。 バージョン管理。ファイルはどこかにバージョン番号を保存します。Continuous Integration（CI）ビルドサーバーには、このチェックインバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。 環境および/またはビルドパラメータ。これらはバージョン管理外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは、同じ方法で番号を配布および使用しますが、値の取得方法が異なります（ソースツリーに対する相対位置をスクリプトに知らせるのではなく、ビルドスクリプトに提供されます）。 最初のアプローチの問題は、メインラインのブランチ間でマージが複雑になる可能性があることです。同じソフトウェアの2つの並行リリースを引き続き維持する場合、最後のマージ以降に両方のバージョンが変更されている場合、2つのメインライン間のマージ時に競合を解決します。 2番目のアプローチの問題は、調整です。1年前のリリースに戻ると、タグ情報のみに依存してリリース番号を識別します。 どちらの場合も、CIビルドの前に知られていないバージョン番号の特定の側面があるかもしれません。たとえば、CIビルドは、実際には自動化されたビルド番号である4番目のコンポーネント（たとえば、ブランチ上の140番目のビルド）にプログラムで配置できます。VCSのリビジョン番号でもあります。 ソフトウェアのバージョン番号を把握する最善の方法は何ですか？VCSで「既知の」部品を常に維持する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？ 現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを介してバージョン番号を維持しています。masterブランチにマージする前に、CIビルドの開始前にバージョン番号が適切に設定されていることを注意する必要があります。Gitflowのワークフローに関しては、ソース管理でバージョン番号が追跡されていればrelease、リリースの準備でブランチを作成するときに、バージョン番号が適切に設定されることを保証できると思います。QAは、このブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時に、masterリリースへのコミットメントを示すマージが行われます。

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 gitをローカルでのみ使用しても大丈夫ですか？プライベートリポジトリ（Githubなど）を提供するサービスに料金を支払う必要はありませんが、gitはクローズドソースプロジェクトを整理するのに最適な方法だと思います。

22 version-control  git  solo-development 

バージョンデータを保存する手段としてファイルを使用するソース管理システムが増えているようです。VaultとTFSはデータストアとしてSql Serverを使用します。これは、データの一貫性と速度の点で優れていると思います。 だから、実際にデータベースソフトウェアを使用する代わりに、SVN、GIT、CVSなどがファイルシステムを本質的にデータベースとして使用していると思うのはなぜですか（SVNサーバーが通常のコミット中に破損するため、この質問をします） MSSQL、Oracle、Postgreなど）？ 編集：私の質問をする別の方法は、「VCS開発者が既存のシステムを使用するのではなく、なぜ独自の構造化データストレージシステムをロールバックするのですか？」

22 version-control 

現在のところ、この質問はQ＆A形式には適していません。回答は、事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は、議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 会社のバージョン管理システムを選択したい。これまでのところ、Git、Subversion、Mercurialがあることを知っています。 最近、Gitが最もよく使用されていることがわかりました。そのため、まだSubversionを使用する特別な理由があるのでしょうか、それともGitに直接アクセスする必要があるのでしょうか。

22 version-control  git  svn 

私は最近、バージョン管理のないチームで働き始めました。ほとんどのチームメンバーは、どのようなバージョン管理にも慣れていません。私は自分の仕事を追跡するためにMercurialを個人的に使用しています。私は他の人にそれを採用することを奨励し、少なくとも彼らが変更を開発するときに彼らのコードのバージョン管理を開始したいと思います。mercurialなどの分散バージョン管理の採用をどのように奨励できるかについて、誰にでもアドバイスをいただけますか。DVCSのマネージャーを含む人々を獲得する方法に関するアドバイスは大歓迎です。

21 version-control  code-quality 

私は1年前にコンピューターサイエンスの大学を卒業し、現在は小規模なWeb開発会社（私と他の1人の開発者、マネージャー、カスタマーサービス、テスター）で働いています。始める直前まで、ソース管理システムはありませんでした。現在、SVNの実装を徐々に始めていますが、他の（シニア）開発者（以下、Joeと呼ぶ）は、SVNリポジトリにコミットする必要があるコードは、本番用としてテストおよび承認されたコードのみであると主張しています。つまり、大規模なプロジェクトでは、一度に数週間以上コミットが行われない可能性があります。 これは通常の習慣ですか？次のようなソース管理の多くの利点を失うように思えます。 プロジェクトの進捗状況をきめ細かく追跡 問題が表示され解決されたときの問題の追跡 ミスを簡単にロールバック コードの簡単なバックアップ。ワークステーションがダウンした場合でも多くを失うことはありません ここで説明するように、リビジョンを実行可能ファイルにスタンプすると仮定すると、どの生産サイトでどのコードが実行されているかを正確に識別しやすくなります。 簡単なコラボレーション（チームワークは行いませんが、すべてソロプロジェクトです） 等。 編集：歴史的に、この会社には真のチームワークがなかったことを強調する必要があります。2人の開発者が別々のプロジェクトに取り組んでいます。また、多くのプロジェクトは小規模であるため、数週間で完了することができます。そして、同社は10年以上ビジネスを続けており、ソース管理なしで順調に進んでいます。通常、プロジェクトは予定時間内に完了します。

21 web-development  version-control 

一般的に、製品ライフサイクル中に複数のリリースがあり、以前の製品のサポートが必要な長期プロジェクトの場合、製品バージョンとコードベースの分岐を処理する最良の方法は何ですか？ より具体的な意味では、適切な分散バージョン管理（例：git）があり、チームの規模は小規模から大規模であり、開発者は一度に複数のプロジェクトに取り組んでいると想定します。直面している主要な問題は、その時点で存在していた古いバージョンをサポートする契約上の義務があることです。つまり、新しい開発では古いコードにパッチを適用できません（Microsoft Office製品がその例です。所有している機能年）。 その結果、各主要製品には複数の依存関係があり、それぞれのバージョンは年間リリース間で変更される可能性があるため、現在の製品のバージョン管理は複雑です。同様に、各製品には独自のリポジトリがありますが、ほとんどの作業はメインソーストランクではなく、その年の製品リリースのブランチで行われ、製品がサポートされるように製品がリリースされるときに新しいブランチが作成されます。これは、バージョン管理を使用するときに考えられるように、製品のコードベースを取得することは単純な問題ではないことを意味します。

21 version-control  versioning  branching  product-management 

私は多くのバージョン管理システムを知っています：CVS、SVN、TFSなど... 私は最初の「リビジョン管理/バージョン管理システム」をグーグルで調べましたが、さまざまな矛盾する答えがありました。 ソース管理が発明されたのはいつですか？誰が発明したのですか？それは何と呼ばれていましたか？

20 version-control  history  scm 

私は、最近のiOSプロジェクトの一部として開発した1組のライブラリを、他のiOS開発者が自由に利用できるようにする計画で、GitHubアカウントを設定しています。 現在、ほとんどのコードのオフサイトバックアップはありません。そのため、当初、私はすべての個人プロジェクト、または少なくともすべてのiOSプロジェクトをGitHubがホストするプライベートリポジトリにアップロードすると考えていました。 。しかし、私は多くのプロジェクトを抱えており、その多くはかなり価値の低いものです（つまり、本を改造して学習体験のために書いたものです）。GitHubはプライベートリポジトリによって課金されるだけでなく、リポジトリを階層的に整理する方法もありません。 私が不足しているものがあり、階層でgitリポジトリを使用し、必要なときにそれらをチェックアウトしたり、現在SVNで行っている方法で作業したりできますか？ GitHub（またはBitBucketのような競合他社）には、プロジェクト構成の機能がいくつか欠けていますか？ それに失敗すると、この状況を処理する一般的に受け入れられている「Gitの方法」は何ですか（リリースを目的としていないプロジェクトを破棄し、オフラインで保存し、何らかの方法で一緒にバンドルするなど）。 私が知る限り、私のオプションは次のとおりです。 ライブラリをGitHubに配置し、他のすべてのプロジェクトで自分のSVNをホストし続け、オフサイトバックアップ（非難）に非VCSソリューションを使用し、 私がリリースする予定のライブラリとソフトウェアをGitHubに（それぞれパブリックおよびプライベートとして）入れ、あまり気にしないプロジェクトのために自分のSVNをホストし続け、XYZの実装方法に関する記憶を更新するために再訪する可能性が高い私の家が破裂した場合（二重の荒れ）、それらを消しても構わないと決めます。 [GitHubおよび/またはBitBucket]にすべてを配置し、必要なものを検索するか、[GitHubおよび/またはBitBucket]アカウントへのオフラインポインターセットを維持することで、途方もない数のリポジトリを持つことに対処する（トリプルブレチ）

20 version-control  git  github 

私は個人的なプロジェクトにDVCSを使用しており、他の人からプロジェクトへの貢献を管理するのが簡単になることを完全に見ることができますが（たとえば、典型的なGithubシナリオ）、「伝統的な」チームにはいくつかの問題があるようですTFS、Perforceなどのソリューションで採用されている集中型アプローチ（「従来」とは、誰もが同じコードに触れる可能性のある、誰も「所有しない」1つのプロジェクトに取り組んでいるオフィスの開発者チームを意味します。） これらの問題のいくつかは私が自分で予見しましたが、他の考慮事項でチャイムしてください。 従来のシステムでは、サーバーに変更をチェックインしようとすると、競合する変更を他の誰かが以前にチェックインした場合、チェックインする前にマージを強制されます。DVCSモデルでは、各開発者がローカルで変更され、ある時点で他のリポジトリにプッシュされます。そのリポジトリには、そのファイルのブランチがあり、2人が変更しました。今、誰かがその状況に対処する責任を負わなければならないようです。チームの指定された人は、すべての競合のマージを処理するためにコードベース全体の十分な知識を持っていない場合があります。したがって、誰かがそれらの開発者の1人にアプローチし、プルしてマージを実行してから再度プッシュするように指示する（または、そのタスクを自動化するインフラストラクチャを構築する）必要がある追加のステップが追加されました。 さらに、DVCSはローカルでの作業を非常に便利にする傾向があるため、開発者がプッシュする前にローカルリポジトリにいくつかの変更を蓄積して、こうした競合をより一般的で複雑にする可能性があります。 チームの全員がコードの異なる領域でのみ作業する場合、これは問題ではありません。しかし、私は誰もが同じコードで作業している場合に興味があります。一元化されたモデルは、競合を迅速かつ頻繁に処理することを余儀なくし、大規模で痛みを伴うマージを行う必要性を最小限に抑えるか、誰かにメインリポジトリを「ポリシング」させるようです。 あなたのオフィスであなたのチームとDVCSを使用している人のために、あなたはそのような場合にどのように対処しますか？毎日の（またはより頻繁に、毎週の）ワークフローが悪影響を受けていると思いますか？職場でDVCSを推奨する前に注意すべきその他の考慮事項はありますか？

20 version-control  dvcs  team 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ジョエルテストの基準の1つは、毎日のビルドです。アイデアは、ビルドが壊れた場合、それを壊した人がそれを修正するために周りにいるということです。ビルドを修正できない場合は、全員が古いバージョンをチェックアウトして作業する必要があります。一元化されたバージョン管理では、マージと分岐を可能な限り避けることが重要であるため、これがいかに悪いかを理解できますが、これは分散バージョン管理にとってささいな迷惑のように聞こえます。これに同意しますか？毎日のビルドが重要な理由は他にもありますか？

20 joel-test  version-control  builds 

私は、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