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

ソースコードのリビジョンを追跡、保存、および取得するためのプログラミング分野。

13
バージョン管理と継続的インテグレーションを使用しない深刻な企業はありますか？どうして？
私の同僚は、継続的な統合を備えたビルドサーバーとバージョン管理ソフトウェアの両方を使用していたため、ソフトウェア部門は非常に高度であるという印象を受けていました。これは私の観点とは一致しませんでした。深刻なソフトウェアを製造していて、どちらも持っていなかった会社を知っているからです。しかし、私の経験はほんの一握りの会社に限られています。 ソフトウェア業界に属し、これらのツールを使用しない実在の会社（プログラマー3人以上）を知っていますか？そのような会社が存在する場合、そうしない理由はありますか？
3
マージした変更をすぐにコミットしないのはなぜですか？
私のオフィスでは、バージョン管理にGitとSourceTreeを使用しています。これは、私が参加したときにバージョン管理がゼロであり、SourceTreeしか使用したことがなかったためです。私は決して専門家ではありませんが、同僚の中で最も経験豊富なので、Gitを適切に使用し、間違いを修正するように全員に教える責任がある事実上の専門家です。 GitとSourceTreeを経て、プロセスのすべてのステップを説明するチュートリアルドキュメントを作成しています。プルプロセスでは、SourceTreeダイアログで[マージされた変更をすぐにコミットする]オプションを選択できます。私はこれが何をするのか、なぜそれが役立つのかを理解しています。私が理解していないのは、なぜこの機能を使用したくないのかということです。 マージした変更を自動的にコミットしたくない理由を誰かが説明できますか？私はこの機能の有用性をよりよく説明し、将来どのような落とし穴に注意すべきかを理解できるように、理由を理解しようとしています。 編集：私の質問がリンクされた質問の複製だとは思わない。リンクされた質問は広くコミットする頻度を尋ねています。SourceTreeでのマージのコミットに関連する特定の機能を使用しないことを選択する理由について質問しています。
5
データベースのコンテンツを制御するバージョン
ユーザーが編集可能なコンテンツを含むWebプロジェクトに取り組んでおり、データベースにある実際のコンテンツのバージョントラッキングを実行できるようにしたいと考えています。基本的に、wikiスタイルの変更履歴を実装したいと思います。 いくつかのバックグラウンド調査を行うと、データベーススキーマをバージョン管理する方法に関するドキュメントがたくさんあります（私のものは実際には既に制御されています）が、データベースコンテンツの変更を追跡する方法に関する既存の戦略は、少なくともスキーマバージョン管理の雪崩では失われます私の検索で。 私は自分の変更追跡を実装するいくつかの方法を考えることができますが、それらはすべてかなり粗雑に見えます： 変更ごとに行全体を保存し、主キーを使用して行をソースIDに関連付けます（現在私が傾倒しているのは、最も単純な方法です）。ただし、多くの小さな変更により、大量のテーブルが膨張する可能性があります。 各変更の前/後/ユーザー/タイムスタンプを保存し、変更を関連する列に関連付ける列名を付けます。 before / after / user / timestampを各列のテーブルに保存します（結果としてテーブルが多すぎます）。 列ごとに変更ごとにdiff / user / timestampを保存します（つまり、特定の日付に戻るには、変更履歴全体をたどる必要があります）。 ここで最善のアプローチは何ですか？自分自身を転がすことは、おそらく他の誰かの（より良い）コードベースを再発明しているように思えます。 PostgreSQLのボーナスポイント。
1
一部のオープンソースプロジェクトがプルリクエストを受け付けないのに、パッチファイルのみをメールで送信するのはなぜですか
一部のオープンソースプロジェクトがプルリクエストを受け付けないが、パッチファイルのみをメールで送信する必要があるのはなぜですか？例：Git githubまたは他の分散scmホスティングでコードを公開しますが。パッチファイルを送信することは、インタラクティブでも便利でもありません。パッチファイルは昔ながらの方法です。プルリクエストはインタラクティブです。他の人も議論するかもしれません。
5
顧客固有のソフトウェアパッチを処理する現実的な方法は何ですか？
私は、他の人が次の問題を解決した効果的な方法を集めようとしています。職場では、特定のお客様にのみ表示したいソフトウェアパッチ（エンドユーザーシステムにインストールする）のリリースを余儀なくされています。カスタムコードは、独自のソース管理ブランチにあります。問題は、同期を保つために2つの並列コード行（およびビルドスクリプト）があり、元のコードにパッチを適用するたびに、顧客固有のコードにパッチを適用してテストする必要があることです。 他の組織はこのシナリオをどのように処理しますか？技術的な（ソース管理に関連する）ソリューションだけでなく、ビジネスソリューションにもオープンです。たとえば、そのブランチで更新を受信できないことを顧客に伝えることについて話してきました。 分岐戦略は次のようになります（Visual Studio TFS Branching Guideに基づいていますが、Subversionを使用しています）
2
.Netで複数の重複するソリューション/プロジェクトを構成する方法は？
私は最近、複数の.netソリューションがあり、それぞれがそのソリューションに固有のいくつかのプロジェクトをホストしているが、他のプロジェクトを「借りる」/「リンクする」（既存のプロジェクトを追加する）古いレガシーコードベースを持つ新しいクライアントで働き始めました技術的には他のソリューションに属します（少なくともTFSのフォルダー構造を使用する場合） これが絡み合ったセットアップを見たことはなく、明確なビルド順序はなく、ソリューションAのプロジェクトはソリューションBでホストされているプロジェクトの出力ディレクトリから直接DLLを参照する場合があり、プロジェクトが存在する場合でもプロジェクトが直接含まれている場合がありますフォルダー構造で遠ざかります。 すべてが開発者の怠lazのために最適化されているようです。 CIサーバーを持っていない理由について私が彼らに立ち向かったとき、彼らはそのように組織されたコードでセットアップするのは難しいと答えました。（私は今それを設定し、このコード編成を呪っている） ソリューションは展開アーティファクト（一緒に展開する必要があるものは同じソリューション内にあります）を中心に編成されていますが、賢明な決定だと思いますが、それらのソリューション（プロジェクト）の内容はいたるところにあります。 複数のソリューション/展開アーティファクトで共通のクラスライブラリを再利用するときに使用するベストプラクティスのコンセンサスはありますか、 VCSでコードを構造化する方法 個別のデプロイメントアーティファクト間でビジネスロジックの共有を促進する方法
7
SQLテーブルの変更をどのようにバージョン管理/追跡しますか？
全員がローカルテーブルと開発テーブルを変更する開発者のチームで作業する場合、どのようにしてすべての変更を同期しますか？誰もがSQLの変更を保持する中央ログファイルですか？テーブルの変更ステートメント、ローカルデータベースを最新バージョンにするために開発者が実行できる個々の.sqlファイルを追跡するWikiページですか？私はこれらのソリューションのいくつかを使用しましたが、うまく機能する優れた堅実なソリューションを一緒に得るために努力していますので、あなたのアイデアに感謝します。
3
選択した{DVCS}の名前付きブランチの適切な命名規則
Mercurialをオフィスにゆっくりと統合し、名前付きブランチの使用を開始したWeb開発を行っています。 しかし、ブランチに名前を付けることに関しては、良い慣習を見つけることができませんでした。 試しました： FeatureName（これが問題の原因であることがわかります） DEVInitial_FeatureName（開発者が出入りするときに混乱する可能性があります） {uniqueID（int）} _ Feature これまでuniqueID_featureNameが勝っていますが、参考のために小さなDBで維持することを考えています。 ブランチID（int）、featureName（varchar）、featureDescription（varchar）、date、whoなど... これにより、1_NewWhizBangFeature、2_NowWithMoreFoo、...のようなブランチが得られ、ログを確認せずにそのブランチが何をするかを簡単に参照できます。 より良い解決策はありますか？
3
長時間実行される未リリースコードのGit分岐戦略
私たちのチームでは、個々の作業単位（ストーリー）に加えて、より長時間実行される作業テーマ（叙事詩）があります。複数のストーリーが壮大です。 従来、各ストーリーに機能ブランチがあり、それらがQAに合格したときにそれらを直接マスターにマージしました。ただし、Epicが「機能完了」と見なされるまで、Epicで完了したストーリーのリリースを控えたいと思います。これらの機能は、Epic全体が閉じられたときにのみ本番環境にリリースされます。さらに、ナイトリービルドサーバーがあります-すべての閉じられたストーリー（不完全なEpicsの一部を含む）がこのナイトリーサーバーに自動的にデプロイされるようにします。 これを達成するためのレポの管理方法に関する提案はありますか？「エピックブランチ」を導入することを検討しました。ここでは、クローズドストーリーをマスターに直接ではなく、関連するエピックブランチにマージしますが、私の懸念は次のとおりです。 壮大なブランチを長時間開いたままにしておくと、マージの競合が心配です ナイトリービルドでは、すべてのエピックブランチを「ナイトリービルド」ブランチにマージする必要があります。繰り返しますが、マージの競合が発生する可能性があり、これは自動的に行われます
2
ファイル名の一部としてのバージョン番号
一部のソフトウェアには、ファイル名の一部としてバージョン番号が含まれていますが、他のソフトウェアには含まれていません。私は後者のタイプにもっと慣れており、それはより一般的だと思いますが、前者のタイプはjavascriptライブラリで時々見ます。たとえば、jQueryのファイル名はのjquery-2.1.0.js代わりに似ていますjquery.js。これらの種類のファイルを更新するたびに、これらのファイルを読み込む他のプログラムの場所を探し、それらが参照するファイル名を変更し、これらのライブラリの古いバージョンを手動で削除する必要があります。それは私にとって不便なので、ファイルの名前を変更してバージョン番号を除外し、ファイル名にバージョン番号を含めないようにします。 これらの数字は何らかのバージョン管理のためのものではないかと疑っていますが、いつどのように使用されるかは明確ではありません。 ファイル名にバージョン番号を含めることの長所と短所は何ですか？ ソフトウェアまたは言語のどの領域がファイル名にバージョン番号を使用し、どの領域/言語が使用しないかについて事実上のコンセンサスはありますか？もしそうなら、その理由はありますか？
2
Gitリポジトリの構造
これが重複する場合は申し訳ありませんが、私は見た。 Gitに移行します。Subversionでは、\ trunk、\ branches、および\ tagsフォルダを使用することに慣れています。 Gitを使用すると、ブランチを切り替えると作業ディレクトリの内容が置き換えられるため、以前の作業方法がGitに当てはまらないと仮定するのは正しいでしょうか？ 私の推測では、gitignoreとreadme.txtを含むレポフォルダーがあり、それからレポを構成するプロジェクトのフォルダーがあります。
7
未解決の変更をコミットしてみませんか？
従来のVCSでは、ビルドを壊す可能性があるため、未解決のファイルをコミットしない理由を理解できます。ただし、DVCSで未解決のファイルをコミットしない理由を理解できません（実際には、ファイルのコミットを妨げるものもあります）。 代わりに、リポジトリをプッシュおよびプルからロックする必要がありますが、コミットしないでください。 マージプロセス中にコミットできることには、いくつかの利点があります（私が見ているように）。 実際のマージの変更は履歴にあります。 マージが非常に大きい場合は、定期的なコミットを行うことができます。 間違えた場合、（マージ全体をやり直すことなく）ロールバックするのがはるかに簡単になります。 ファイルは、解決済みとしてマークされるまで未解決としてフラグを立てたままにすることができます。これにより、プッシュ/プルが防止されます。 単一の変更セットではなく、変更セットのセットをマージとして機能させることもできます。これにより、などのツールを引き続き使用できますgit rerere。 それでは、なぜ未解決のファイルで眉をひそめたり、予防したりするのですか？伝統以外の理由はありますか？
1
Git / Mercurialリポジトリが使用するスペースが少ないのはなぜですか？
ここでのいくつかの議論と、DVCSリポジトリが中央のカウンターパートとほぼ同じ、またはそれより少ないスペースを使用することについて読んだことがあります。私はそれを見逃したかもしれませんが、私はそれがなぜであるかの良い説明を見つけていません。知ってる？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.