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

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

1
ビルドスクリプトとビルドサーバーの責任
ビルドスクリプトとビルドサーバーの責任について明確にする必要があります。 継続的な統合とビルドに関するいくつかのネット上の記事を読みました。含む F5キーはビルドプロセスではありません ビルドサーバー：プロジェクトのハートモニター 毎日のビルドはあなたの友達 そして、私たちのソフトウェアのビルドプロセスについてアドバイザーと会話しました。彼は非常に経験豊富であるため、私は彼の発言を信頼しますが、混乱が残りました。 私が理解しているように、私の研究から（そして私が尋ねているのでここで私を修正してください）理想は次のようになるはずです： すべてのプロジェクトにはビルドスクリプトがあります このスクリプトはプロジェクトをビルドします このスクリプトは、依存関係が以前に構築されていることを確認します 依存関係は他のプロジェクトになる可能性があるため、独自のビルドスクリプトを使用すると、ツリーのような階層が生じます。すべてのプロジェクトとアプリケーションをビルドするトップビルドスクリプトがある場合があります。 ただし、ビルドサーバーの責任は次のとおりです。 リポジトリをチェックアウトする ビルドをトリガーする トリガーテストおよびその他のQAツール アーティファクトを利用可能にする これは、手動で、夜間に、またはリポジトリが変更されるたびにトリガーされます。 私のアドバイザーの目的は、私が理解しているように、1つのビルドスクリプトは柔軟性がなく、維持できない方法であるということです（レガシーコードベース用に作成するのに非常に時間がかかるという事実は別として）。また、ビルドサーバーは依存関係を維持する必要があります。たとえば、新しい依存関係を作成するときに古い依存関係を使用すると失敗します。特にAnt、具体的な主題であったため、コードベースで使用されるあらゆる種類の異なるテクノロジーを構築することはできず、依存関係を維持することもできません。 目的を詳しく説明して、責任を明確にしてください。
1
小規模プロジェクトのGitワークフロー/プラクティス（pngのフローチャート）
私は個人的なワークフローを考え出そうとしています。リリースの架空の寿命のフローチャートを作成しました。ある開発者が公開githubリポジトリにプッシュし、友人が何らかの機能を手伝ってバグを修正しました。 これはバージョン管理の合理的なアプローチですか？ 主なアイデアは、パブリックリポジトリを整理することです。 新しいリリースはそれぞれ、終了時にマスターブランチで最終的にタグ付けされるまで、独自のブランチになります。 すべての作業は、異常を防ぐために、実際のリリースブランチではなく、「機能」または「ホットフィックス」ブランチで行われます。 高レベルのブランチへのマージは、常にリベースまたはスカッシュされます（混乱を避けるため）。 やり過ぎだとしても、大事なプロジェクトに必要なスキルを習得することが全体的な目的なので、気にしません。唯一の問題は、私が間違っているか不必要なことを完全にやっていることです。 編集2：元のフローチャートの悪い考えを修正し、ナビゲートしやすくしました。
4
開発マネージャーは、「目標の傾向」をどのように処理する必要がありますか？
最初に用語を作成します： コード目標の調整：午前中にコードをチェックアウトし、他の開発者が前日にファイルごとに行ったすべての変更（特に最初に開発したコードファイル）を静かにレビューし、フォーマット、ロジック、変数名の変更、リファクタリングを修正します長いメソッドなど。その後、VCSに変更をコミットします。 このプラクティスには、私が特定したいくつかの長所と短所がある傾向があります。 Pro：コードの品質/可読性/一貫性が維持されることが多い Pro：他の開発者が元のコードにあまり慣れていないため、いくつかのバグが修正されています。 Con：多くの場合、目標を設定する開発者の時間の無駄です。 Con：前日、バグのないコードを書いたと考えていた開発者が、髪を引っ張る怒りを引き起こすバグをときどき紹介します。 コン：他の開発者は、過度つべこべで悪化し、目標入札のコードに貢献嫌いし始めます。 免責事項：公平を期すために、私は実際には開発マネージャーではなく、実際に「目標管理」を行っている開発者です。 私の防御では、これを正当な理由で行っていると思います（非常に大きなコードベースを油を塗ったマシンに保つため）。また、マネージャーがこの問題に対処する必要があることも間違いなく心配しています。 あなたがマネージャーだったら、この問題にどのように対処しますか？ 更新：これがあまりにもローカライズされているという意味ではありませんが、一部の人は質問しているので、おそらくいくつかの背景が明らかになるでしょう。私は3年前に巨大なプロジェクト（200K LoC）を割り当てられましたが、最近（1年前）にプロジェクトに追加された開発者が追加されました。通常、製品の全体的な安定性について回答する必要があります。コードベースのコアアーキテクチャ部分に驚くほど変更が加えられると、特に緊張します。この習慣は、最初は他の開発者の貢献について楽観的だったために発生しましたが、数週間後までは発見されない深刻な問題を引き起こす過大なミスを引き起こしました。しばしばこれらの
6
クライアントがプロジェクトに貢献できるようにする最良の方法は何ですか？
クライアント用のCRMを構築しています。最初の主要なフェーズが終了し、2番目のフェーズが合意されたので、クライアントは作業の一部をピックアップし、2番目のフェーズを構築する間にデータベーススキーマとビジネスプロセスを若干修正します。 これが実用的かどうかは定かではありませんが、そうであると仮定すると、これを実行可能にするための対策を講じることができる指針が欲しいのです。ここに私がこれまでに得たものがあります： これまで、クライアントは主にユーザーの視点からプロジェクトを見てきました。明らかに、2部構成のセミナーを開催し、内部の仕組みを紹介します。 最初に、既存のデータベーススキーマを表示し、例としてそれを拡張します。 次に、サンプルコードをいくつか表示し、スキーマ拡張のための新しいビジネスプロセスを記述します。 コードは現在、内部Subversionリポジトリにあります。私たちは彼のネットワーク（VPNに接続できる）にパブリックなものをセットアップできましたが、分散システムの方がうまくいくと思います。しかし、そのように感じるのは私だけだと思われるので、説得力のあるいくつかの議論を使用できます。 本番環境で実行されるコードがコミットされることを義務付け/保証する方法がわかりません。「xは休暇に入る直前に重大な、文書化されていない変更を加えたようだ。今ではyはそれ以来ずっと発生しているこのバグを見つけようとしている」災害は避けられない。理想的には、すべての変更は、展開前に次のことを行います。 問題追跡システムに文書化される、 最初に別のテスト環境で発生し、 自動テストに合格する必要があります。 悲しいかな、私はそれらのいずれかの規律が勝つことを疑います。 1）前者は存在せず、2）後者はクライアントが既存のコードを見て、場合によっては変更することを禁止するため、プラグインアーキテクチャまたは個別のプロジェクトは実行可能なオプションではないと想定します。主張する。
6
共有ライブラリの分岐およびバージョン管理戦略
これらの 投稿は関連しているように見えますが、私の脳は溶け始めています：P 私の雇用主はソース管理の使用を開始しました。主に、彼らがより多くの開発者を雇う前に、「リポジトリ」は主に自宅で働く孤独な開発者のハードドライブだったからです。彼が書いた.NETコードはすべてまとめてチェックインされ、多くの重複した（読み取り：コピーアンドペースト）機能があります。現時点では、SCMシステムは栄光のバックアップです。 重複したコードの一部を共有ライブラリに引き込みたいです。元のリポジトリはそのままにしておき、何も壊さないようにします。必要に応じて既存のコードを移動および/またはリファクタリングできます。それで、ライブラリを含む新しいコードのためだけにリポジトリを設定しました。 私の問題は、過度のプロセスに悩まされることなくライブラリをバージョン管理することを中心にしています。ソリューションが生産性に影響を与え始めた場合、うまく落ちます。 私の強迫観念での理想的な解決策は、ライブラリを個別にビルドし、各依存プロジェクトを意図的に選択した互換性のあるバージョンに対してビルドすることです。そのようにして、どのクライアントがどのライブラリのどのバージョンを持っているか、バグをより確実に再現でき、製品とライブラリの独立したリリースブランチを維持でき、共有コードを変更するときに互いのプロジェクトを壊さないようにできます。 これにより、特に自宅で働く開発者にとっては、ライブラリの更新が面倒になります。少なくとも当初は（最終的に）共通部分をまとめると、ライブラリが急速に変化することを期待しています。私はこれを完全に考えすぎている可能性が高く、最新のライブラリコミットに対してすべてを構築するだけで構いませんが、少なくとも一部のコンポーネントを個別にバージョン管理する必要があると判断した日には備えたいと思います配布されました。一部のライブラリをGACにインストールする必要があるという事実により、バージョン管理は特に重要になります。 だから私の質問は：私は何が欠けているのですか？1つのソリューションに固執しているように感じますが、現在、変更をよりスムーズにするバリエーションを見つけようとしています。以前、この種の問題を解決するためにどのような戦略を使用しましたか？この質問はあちこちにあることを理解しています。不確実な点を整理し、明確にするために最善を尽くします。 そして、私はMercurialを使いたいと思っていますが、私たちはすでに集中型商用SCM（Vault）にお金を費やしており、切り替えはオプションではありません。また、ここでの問題は、バージョン管理ツールの選択よりも深くなると思います。
4
大規模な金融/保険会社がgitやgithubを使用する理由
私は、金融/保険業界の大企業（従業員3万人）で働いています。「IT」は主な焦点ではありませんが、正直に言って、これらは情報主導型の産業であり、技術的優位性のある企業はより早く前進しているようです。 私の会社には多くのソフトウェア開発チームがいます。言語やフレームワークはもちろん、バージョン管理機能を備えたマップ上にあります。何も使用しない（知っている）、PVCSを使用するもの、VSSを使用するもの、SVNを使用するものがあります。 gitを企業に持ち込みたい。具体的には、GitHub（プライベートリポジトリ）を持ち込みます。これについて話すのにふさわしい人は知っていますが、正直言って、このような抜本的な動きは、あいまいなセキュリティの懸念や競合他社がそれを使用していないという事実のために、大企業の環境で通常撃ち落とされます参照としてjQuery、Ruby on Rails、Facebookなどのみを引用してください）。 私の質問はこれです。大企業がPVCS / VSS / SVNからGitHub（プライベートリポジトリ）などのホストされたgitソリューションにゆっくりと慎重に切り替える必要がある理由の最も説得力のある理由は何ですか。もちろん、私の計画の一部には、必須ではない開発プロジェクトのPOCが含まれます。
7
ソース管理リポジトリで「レビュー」されたソースコードを持つためのベストプラクティスは何ですか？
ソース管理リポジトリでレビュー済みのソースコードを管理する最良の方法は何ですか？ソースコードはチェックインされる前にレビュープロセスを経るべきですか、それともコードがコミットされた後にコードレビューが行われるべきですか？コードがリポジトリにチェックインされた後にレビューが発生した場合、どのように追跡する必要がありますか？
6
すぐにリリースされる機能を本番リリースに1週間おきにのみ含めるにはどうすればよいですか？
私はかなり大規模なアジャイルチームのソフトウェア開発者です（8人の開発者が1つのコードリポジトリに積極的に変更を加えています）。2週間ごとに、ソフトウェアの新しいバージョンを運用環境にプッシュします。現在のワークフローは次のとおりです。 新しいタスクを開始するとき、開発者はメインの開発ブランチ（gitを使用）から「機能ブランチ」を作成し、この新しいブランチで作業します 開発者がタスクの作業を完了すると、機能ブランチを開発ブランチにマージして戻します 開発者は、開発ブランチをQAブランチにマージします。 QAブランチからビルドがトリガーされます。このビルドの出力はQA環境に展開され、テスターがテストを開始できるようにします。 テスターがQAブランチにマージされたこれらの新機能の問題を見つけることは非常に一般的です。これは、常に、QA環境にいくつかの新しい機能が含まれていることを意味します-テスト済みでバグのないもの、壊れたものなど。QAビルドが実稼働対応状態になることはまれなので、これによりリリースが困難になります。 これを軽減するために、開発者がリリースの数日前に開発ブランチをQAブランチにマージしないことを意味する「QAフリーズ」を開始しようとしました。QA環境のバグ修正はQAブランチで直接行われ、開発ブランチにマージされます。理論的には、これによりQAの新しい壊れた機能が排除され、QAで既に発生している問題を修正できます。 この「QAフリーズ」の概念は部分的には成功していますが、調整が難しく、QAへのマージが許可されているかどうかについて人々はしばしば混乱します。また、「QAフリーズ」の期限を設定することは困難でした。誰もがフリーズとリリースの間に息を吹き込む部屋のアイデアを好みますが、実際には、デッドラインを尊重するよりも次のリリースで機能を持ちます。 1週間おきにリリースのクリーンビルドを確保するより良い方法はありますか？
2
複数のチームのGitワークフロー
Gitの使用を開始し（まだ使用していない）、ワークフローを定義します。 4つの異なるグローバルロケーションに4つのチームがあり、同じ製品を一緒に開発しています。各チームは製品のコードの一部を所有していますが、他のチームが所有するコードを変更する必要がある場合もあります。 そのような環境のGitワークフローに推奨事項はありますか？ 私はすでにこの記事を見てきましたが、ここでのアプローチは「できるだけまれに追加のブランチを作成する」ことであり、「ユーザーストーリーごとのブランチ」アプローチをより重視しています。 また、この記事は素晴らしいアプローチを提示します。 マスターブランチ、定期的にマスターにマージされる各チームごとの永続的なブランチ、およびチームのブランチにマージされるユーザーストーリーごとのブランチを念頭に置いていました。それは理にかなっていますか、それともうまくいきませんか？
2
v1.5より前のSVNでのマージに関する不便さは、メタデータの欠如がもはや問題にならなくなった今では時代遅れになっていますか？
私はSVNを使い始めましたが、DVCSツールと比較してSVNでのマージは非常に難しいと多くのソースが言っています。最新の質問私はSEにここに見つけることができる2012年からです。 時々、v1.5より前のSVNにはメタデータがなかったが、SVNは現在バージョン1.8.9であるという理由が言及されています。 SVNがv1.5よりもはるかに成熟していることを考えると、特にSVN 1.5を使用しなかったため、前述のメタデータの欠如に悩まされていないという事実を考えると、SVN に対するこれらの議論にはまだ多くの妥当性がありますか？ DVCSには完全に異なるアプローチがあり、それがより望ましい場合が多いことを理解していますが、何らかの理由でSVNを「必要」とする人にとって、マージはもはや「地獄」ではありませんか？
3
小規模チーム向けのGitワークフロー
私は、小さなチームで実装するgitワークフローに取り組んでいます。ワークフローのコアアイデア： すべてのチームメンバーが書き込み可能な共有プロジェクトマスターがあります すべての開発は機能ブランチでのみ行われます 機能ブランチは、ブランチ作成者以外のチームメンバーによってコードレビューされます 機能ブランチは最終的に共有マスターにマージされ、サイクルが再び開始されます この記事では、このサイクルの手順について詳しく説明します。 https://github.com/janosgyerik/git-workflows-book/blob/small-team-workflow/chapter05.md これは理にかなっていますか、何か不足していますか？
3
単一開発者のGITワークフロー（単純なFTPから移行）
VCSに移行するのが賢明かどうかを判断しようとしています。私は小さな組織（5人）の単一のWeb開発者です。VCS（Git）は、バージョン管理、オフサイトバックアップ、集中コードリポジトリ（自宅からアクセス可能）などの理由で考えています。 現時点では、一般的にライブサーバーで作業しています。FTPで入力し、編集して保存し、再アップロードして更新します。通常、編集はCMSのテーマ/プラグインファイル（concrete5またはWordpressなど）に対して行われます。これはうまく機能しますが、バックアップもバージョン管理も提供しません。 VCSをこの手順にどのように統合するのが最善か疑問に思っています。会社のWebサーバーにGitサーバーをセットアップすることを想定していますが、クライアントアカウント（通常は同じサーバー上のVPS）に変更をプッシュする方法は明確ではありません-現時点では、詳細を指定してSFTPにログインし、変更を直接。 また、何がリポジトリを賢明に表現するのか分かりません-各クライアントのウェブサイトは独自のものを取得しますか？ 洞察や経験は本当に役立つでしょう。どうしてもGitのフルパワーが必要だとは思いませんが、基本的なバージョン管理と事実上のクラウドアクセスは本当に便利です。 編集：私はそれを最も理にかなっていると思われる2つのオプションに絞り込みました。1つ目はZweiBlumenの回答に基づいており、編集はライブサーバーで行われ、そこから（外部の）Gitサーバーにコミットされます。これには、私のワークフローがあまり変わらないという利点があります（コミットを行うための追加のステップがありますが、それ以外は同じです）。 2番目のオプションは、XAMPPを使用してローカルで作業し、ローカルマシンから変更をコミットすることです。サイトがライブになったときのみ、完成した記事をローカルマシンからWebサーバーにアップロードします（Gitへの最終コミットの直後）。これは理論上は問題ないように見えますが、その後サイトが修正を必要とし、ライブサーバーでそれらを作成する場合（通常どおり）、ローカルリポジトリの変更されたファイルを手動でコピーし、それらの変更をGitサーバー。これは過度に複雑に思えますが、おそらく私の現在のワークフローからはかけ離れすぎています。 私は、オプション1を試してみて、どうやってうまくいくかをバランスよく考えます。
6
リリースに適した分岐戦略の選択
新しいプロジェクトの新しい開発チームから始め、ソースリポジトリ（Microsoft Team Foundation Server 2010など）の分岐戦略を定義する必要があります。私たちは...するべきかどうかという難しい議論にぶつかりました... A。実稼働ビルドを行うリリースブランチが1つあり、実際に何かがリリースされたときにラベルを付ける または B。本番環境への新しいリリースごとに新しいリリースブランチを作成します（例：バージョン1、2、3など...） オプションAは非常に簡単に思えますが、これが長期的に問題を引き起こすかどうかはわかりません。オプションBは、時間の経過とともに積み重なる1回限りの長寿命ブランチを作成するだけのようです。 私たちが決めるのを助けることができる経験はありますか？具体的には、いずれか1つの選択肢のどこに問題があるのか​​を聞きたいと思っています。TFSおよび/またはリリース管理の意味に関連する特定の経験を提供してください。
4
コミットメッセージ内のバグ/問題への言及は良い習慣と見なされていますか？
バグトラッカーにメモを自動的に書き込むようにソース管理を設定しているプロジェクトに取り組んでいます。コミットメッセージにバグの問題IDを書き込むだけで、コミットメッセージがバグトラッカーへのメモとして追加されます。 このプラクティスの欠点はほんの少ししかありません。将来、ソースコードがバグ追跡ソフトウェアから分離された場合（または報告されたバグ/問題が何らかの形で失われた場合）。または、誰かがコミットの履歴を調べているが、バグトラッカーにアクセスできない場合。 私の質問は、コミットメッセージにバグ/問題の参照を含めることをお勧めしますか？他にも欠点はありますか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.