タグ付けされた質問 「dvcs」

前提条件 チームはDVCSを使用します IDEはコメントの解析をサポートしています（TODOなど） CodeCollaboratorのようなツールは予算的に高価です gerritのようなツールはインストールするには複雑すぎるか、使用できません ワークフロー 著者は中央リポジトリ機能ブランチのどこかに公開しています レビュー担当者が取得してレビューを開始します 質問/問題レビューアの場合、「REV」などの特別なラベルを付けてコメントを作成します。そのようなラベルは、製品コードに含めることはできません-レビュー段階でのみ： $somevar = 123; // REV Why do echo this here? echo $somevar; レビュアーがコメントの投稿を完了すると、愚かなメッセージ「comments」でコミットし、プッシュバックします 作成者は機能ブランチをプルバックし、同様の方法でコメントに回答するか、コードを改善してプッシュバックします 「REV」コメントがなくなると、そのレビューは正常に終了したと考えることができます。 作成者は機能ブランチをインタラクティブにリベースし、それを押しつぶしてそれらの「コメント」コミットを削除します。これで機能をマージして、通常は内部レビューが正常に完了した後のアクションを開発または実行する準備ができました IDEサポート 私は、カスタムのコメントタグがEclipseとNetBeansで可能であることを知っています。確かにそれはblablaStormファミリーにもあるはずです。 ご質問 この方法論は実行可能であると思いますか？ 同様のことを知っていますか？ それで何を改善できますか？

16 teamwork  code-reviews  workflows  dvcs 

従来のVCSでは、ビルドを壊す可能性があるため、未解決のファイルをコミットしない理由を理解できます。ただし、DVCSで未解決のファイルをコミットしない理由を理解できません（実際には、ファイルのコミットを妨げるものもあります）。 代わりに、リポジトリをプッシュおよびプルからロックする必要がありますが、コミットしないでください。 マージプロセス中にコミットできることには、いくつかの利点があります（私が見ているように）。 実際のマージの変更は履歴にあります。 マージが非常に大きい場合は、定期的なコミットを行うことができます。 間違えた場合、（マージ全体をやり直すことなく）ロールバックするのがはるかに簡単になります。 ファイルは、解決済みとしてマークされるまで未解決としてフラグを立てたままにすることができます。これにより、プッシュ/プルが防止されます。 単一の変更セットではなく、変更セットのセットをマージとして機能させることもできます。これにより、などのツールを引き続き使用できますgit rerere。 それでは、なぜ未解決のファイルで眉をひそめたり、予防したりするのですか？伝統以外の理由はありますか？

15 version-control  git  mercurial  dvcs 

ここでのいくつかの議論と、DVCSリポジトリが中央のカウンターパートとほぼ同じ、またはそれより少ないスペースを使用することについて読んだことがあります。私はそれを見逃したかもしれませんが、私はそれがなぜであるかの良い説明を見つけていません。知ってる？

15 version-control  git  svn  mercurial  dvcs 

これは少し奇妙に聞こえるかもしれませんが、何らかの方法でネットワーク接続された複数のマシンからGitで作業する良い方法について疑問に思っています。私には2つの選択肢があるように見えますが、両方の利点があります： 共有にはgit自体を使用します。各マシンには独自のリポジトリがあり、それらの間でフェッチする必要があります。 他のマシンがオフラインであっても、どちらのマシンでも作業できます。これ自体はかなり大きいと思います。 マシン間のネットワークで共有される1つのリポジトリを使用します。 コードは常に最新であるため、マシンを切り替えるたびにgit pullを実行する必要はありません。 このマシンでファイル共有を使用して作業を行っていたため、他の非ホスティングマシンからコードをプッシュするのを忘れたことを心配しないでください。 私の直感では、一般的に誰もが最初のオプションを選択します。しかし、私が見る欠点は、常に他のマシンからコードにアクセスできるとは限らないことであり、毎日の終わりにすべてのWIPブランチをgithubにプッシュしたくないことは確かです。また、コンピュータから直接取得できるように、常にコンピュータの電源を入れたままにする必要はありません。最後に、複数のブランチを最新の状態に保つためのすべてのgitコマンドが退屈になる可能性があるという小さな点があります。 この状況に3番目の対処法はありますか？このプロセスを簡単にするサードパーティのツールが利用できる場合がありますか？この状況に定期的に対処する場合、何を提案しますか？

15 git  workflows  dvcs 

閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 その説明に当てはまる人の良い例は、プロジェクトマネージャーかもしれません。 先日、上司から「このGithubのことは何か、なぜ重要なのか」と尋ねられました。彼はいくつかの独自のプロジェクトを持っているので、プライベートホスティングが必要になります。私はいつも以上に説明するのに苦労しました。 。私の考えでは、「DRVSを使用して、それがどれほど有益であるかを本当に理解しなければならないかのようです」と考えていました。 最終的に私は彼に無制限のプライベートリポジトリを提供するため、BitBucketを指すようになりました（リポジトリとは何かを説明する必要さえありました）。 誰もがVCSがいかに彼らの命を救ったか、人生を楽にしたかなどの本当に良い具体的な例を持っていますか？基本的に、どのように職業にプログラマーではなく、プログラミングに不慣れではない人にDVSCを販売しますか？

13 dvcs 

関連： すべてのgitコミットはプロジェクトを動作状態のままにする必要がありますか？ 次のコミットをローカルで行うと仮定します。 データベーススキーマを変更して、アプリケーションを破壊します。 データベーススキーマと再度互換性があるようにアプリケーションを更新します。 両方のコミットをプッシュする限りmaster、動作状態のままです。ただし、履歴バージョンは壊れています。 私はgit rebase -iコミットを一緒につぶすために使用できることを知っています。ただし、結果のコミットは大きくなり、説明が少なくなります。コミット履歴を検索して、何かを変更した理由を調べる必要がある場合は、元のコミットが自分が何をしたのか、そしてなぜなのかを示したいと思います。 私の質問は： masterで壊れた履歴コミットが原因で問題が発生した人はいますか？ もしそうなら、個々のコミットメッセージと変更を破棄せずに、そのような困難を避ける簡単な方法はありますか？

13 git  dvcs 

問題 私は約10人の開発者がいるソフトウェアプロジェクトに参加しており、Mercurialを介してソースコードを共有しています。リリースごとに開発ブランチと本番ブランチがあります。プロジェクトの過程で、1つのブランチ（v1など）からのソースコードが、ソフトウェアの以前のリリース（v2）のパッチブランチとメンテナンスブランチに入りました。 これにより、間違ったコミットのバックアウトに時間を費やしたり、コードが間違ったブランチに入ったことに気付かなかった場合、間違った（おそらくQAdでない）コードが間違ったブランチに到達してデプロイされます。 ブランチとマージの設計/方法 v1-test v1-patch1 v1-patch2 ^---------^-----------^ v1-prod / / \ \ -----------------------/ \ \ v1-dev \ \ \ --------------------------\ v2-dev \ \ \ ^-------^------------- v2-prod v2-test v2-patch1 したがって、準備ができたと判断されるまでリリース開発ブランチに取り組み、すべてのリリースとメンテナンスが行われる単一のテスト/ UAT /生産ブランチに分岐します。タグは、このブランチのリリースをビルドするために使用されます。v1のテスト中に、v2のブランチが作成され、開発者は新しい機能の開発を開始します。 起こりがちなのは、開発者がv2-devブランチの作業をv1-devまたはv1-prodにコミットすることです。さらに悪いことに、v2-devをv1-prodにマージします（または同様のミス）。 ほとんどの開発者は-prodブランチにアクセスしないように指示しますが、コードはまだ潜入しています。 v2は開発を開始したばかりですが、v1には問題を修正するための非常に大きなパッチがまだ残っている可能性があることに注意してください。つまり、v1は単に奇妙な小さなパッチを取得しているだけではありません。 これまでに試したこと ゲートキーパーを備えた、独立した-prodブランチがあります。-prodブランチはその名前を通じて警告を発するはずであり、ほとんどの開発者はそのブランチにいる必要はありません。これは実際に問題を軽減していません。 開発者の間でこの問題に対する意識を高め、彼らをより警戒させようとしました。繰り返しますが、これはあまり成功していません。 開発者が間違ったブランチにコミットする場合に考えられる考えられる理由 ブランチデザインが複雑すぎる 複数のブランチを並行して積極的に開発する。（プロジェクトは、雪崩モデルを使用するという症状を示します。） 開発者はDVCSを十分に理解していない ある程度関連性のある私が読んだ質問 私は間違ったブランチにコミットしないことについてこの質問を読みました。視覚的なキューに関する答えは役に立つかもしれません。しかし、私たちが経験している問題は、より根本的な問題の症状ではないと完全に確信しているわけではありません。 視覚的な手がかりを使って、それらをコマンドラインに簡単に組み込むことができますが、チームの約半数が日食を使用していますが、視覚的な手がかりを組み込む方法はわかりません。 質問 ソフトウェア、プロジェクト管理、またはガバナンスの形で、間違ったブランチへのコミットを減らして（理想的には停止して）時間を浪費したり、デプロイされたコードを汚したりするために、どのような方法を使用できますか？ 上記のように貢献していると思われる理由に関する特定のコメントをいただければ幸いですが、これは返信を制限するものではありません。

12 version-control  training  dvcs 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 編集：最近のダウン投票（この時点で+ 8 / -6）を考えると、ガートナーのライフサイクルはプログラマーの観点から偏ったメトリックであることは私に明らかにされました。これは私が経営陣に提示する論文の一部であり、経営陣はガートナーの聴衆の一部です。 DVCSを与える暴露＆熱意を（誇大広告とみなさ、ことが「可能性」というか、少なくともなどの攻撃これを読んだとき）、次の質問を考える：「どのように私はDVCSsの準備ができていることを管理を説得するガートナーのハイプ・サイクルを使用することができます（または準備ができている）、それは単なる誇大広告ではありません」 DVCSsが誇大広告であるかどうかを尋ねるだけでは建設的ではありませんが、ガートナーの誇大広告サイクルは、それを尋ねるよりも客観的な手段です（この手段が偏っているとみなされても）。他の楽器を知っている場合は、ぜひとも言及してください。 編集＃2：Gartnerのライフサイクルはすべてのテクノロジーに対応しているわけではないことに同意しますが、一部の人は誇大広告と見なされるほどの話題を生み出したと考えられるため、少なくともこのツールを使用して、どんな程度でもそれを証明/反証するために。私はDVCS、BTWの擁護者です。 編集＃3：答えてくれてありがとう。バウンティは詳細と実践的なアドバイスで私の質問に答えてカレブに行きます。受け入れられた答えは、別の有用な手段を提供し、私の質問を超えて答えてくれた哲学者に送られます。 会社でDVCSの採用を支持して書いているホワイトペーパーの研究をしていて、社会的証拠の概念につまずいた。DVCS採用の社会的証拠が必ずしも貨物カルトではないことを証明したいので、5段階で技術の成熟度を説明するガートナーの誇大広告サイクルにつまずいた。 私の質問は：誇大広告サイクルの特定の段階での分散バージョン管理システム（一般的にはgit、mercurial、bazaarなど）の現在の場所の指標は何でしょうか？...（その他の（複雑ではない））つまり、DVCSの現在の期待は、a）開始、b）膨張、c）減少（幻滅）、d）増加（啓発）、またはe）安定化（成熟）、および（より重要な）理由であると言いますか？ それは難しい質問であり、主観性が関与していることは知っていますが、特定のフェーズの最も明確な議論/証拠に答え（および従来のクッキー）を付与します。

12 research  dvcs  cvcs 

私の理解から、SVNは「簡単に分岐できます。マージが難しい」。何故ですか？マージ方法に違いはありますか？

12 git  svn  mercurial  dvcs 

現在SubversionとTeamCityを使用していますが、Mercurial（特にFogBugzユーザーのKiln）の使用に移行します。 明らかにこれにより、開発パターンに変更（できれば改善）がもたらされます（2人全員！）が、私が悩んでいる1つの問題は、継続的な統合/ CIサーバーのメリットを享受できるように物事を構造化する方法です（利益が存在し、今後も存在することは当然のことであり、その議論はこの質問の範囲外です。 SVNを使用すると、限られた数の中央リポジトリにコミットします-事実上プロジェクトごとに1つ（多かれ少なかれ1つのVisual Studioソリューション）なので、ビルドをトリガーし、すべてのファイルがコミットされていないという安心感を得るのが簡単です依存関係などの漂流など。しかし、mercurialを適切に進める場合は、リポジトリインスタンスを増やしたいと思うでしょう。変更点は、一般に決定的な「ライブ」レポジトリに向かって流れると予想されます。私が苦労している問題は、ライブリポジトリが私にとってCIビルドをトリガーするには遅すぎるように見えることです。開発者ごとにプロジェクトごとに1つのCIビルドが多すぎると思われます（そして他の問題を引き起こします）。 私は少し釣りをしていますが、それは、中央のSubversionリポジトリが提供するものの1つ（私はセットアップで！）が、何をいつ構築するかについて非常に明確だからです。 nb Mercurialを継続的インテグレーションで使用するメカニズムについては質問していません。個人的なプロジェクトの御and走、そのパターンと構造、そして頭を動かそうとしている作業プラクティス/ワークフローを持っています。

12 continuous-integration  dvcs 

Git（および一般的にDVCS）を使い始めて、履歴書き換えの変更を検討し始めたとき、リポジトリがローカルのみの場合は安全ですが、リモートで作業してみようとすると問題が発生する可能性がありますそのような変更をプッシュします。 私が期待している機能は、「セーフモード」を有効にする機能です。これにより、基本的に、私がすべきでないことは何もできなくなります。そして、それはどういう意味ですか？つまり、すでにオリジンにプッシュされたものの履歴書き換えの変更を意味します。正確に定義することはできませんが、これには次のようなケースが含まれます。 commit --amend HEADがすでにプッシュされている場合 rebase 非ローカルブランチの reset プッシュされたブランチの これらは、おそらく次のpush失敗をもたらす状況の例です（IIRCは早送りではないため）。そのうちのいくつかを偶然に作成し、リモートでブランチを再作成する必要がありました。そして、私はこれを十分に速く実行できたので、私が書き直した歴史を誰も引き出せなかったのは幸運でした。 この種の変更を特定し、必要に応じて、ユーザーがそれらを変更できないようにすることは可能だと思います。おそらくそのためのオプションはありますか？ 存在しない場合、作成しようとする価値があると思いますか？そのような「危険な変化」を特定する方法を正確に定義してみませんか？

11 git  dvcs 

GitとMercurialは同様のモデルに従い、同様の用語を使用します。Mercurialの最初のリリースは、Gitのわずか12日後でした。これらの2つのプロジェクトは、同時に最初の開発でどのように似たような結果になりましたか？誰もが歴史を知っていますか？

11 git  mercurial  dvcs 

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

10 version-control  dvcs 

私の会社では、PerforceからDVCSへの移行を模索しています。現在、ソフトウェア開発チームはドイツ、中国、米国、メキシコに分散しており、ある場所から別の場所への帯域幅がそれほど大きくない場合があるため、現在、多くのPerforceプロキシを使用しています。 ITと話して、地理的に分散された観点から物事をスムーズに実行する方法を探し始めました。これにより、どのリポジトリサーバーが真のソースであるかを決定せずに（つまり、透過的に複製することなく）すべての人が最新かつ最高の状態を得ることができます。 おそらくpre-pushおよびpre-pullフックを介してDNSメカニズムをエミュレートできると思いました。たとえば、国A、B、Cについて考えてみます。祝福されたAからプルすると、A自体がBからの変更をプルし、次にBからCへの変更をプルします。BとCに新しい変更がある場合、Aに落ちます。逆に、プッシュがある場合、それはすべての祝福されたリポジトリに伝播される可能性があります。 私がいることを承知している、一般的に一つだけ恵まれレポを持っているが、これは世界的に拡大しないことがあり、それぞれの祝福されたリポジトリがただ一つの国からのチームに適用可能です。 私の質問は、DVCSレポレプリケーションの概念は実際に使用されているものですか？それを成功させた人はいますか？その場合、正しい方法は何ですか？

9 dvcs  distributed-development  data-replication 

私は最近、dvcsについて同僚と話し合っていました。これは、私たちのオフィスがTFSからの切り替えを検討し始めているためです（私たちはMSショップです）。その過程で、彼はMercurialを使用しているものの、「ブランチ」または「チェックアウト」コマンドを聞いたことがなく、これらの用語が彼にとってなじみのないものであると彼が言ったので、私は非常に混乱しました。彼がそれらについて知らなかった可能性があるのではないかと考え、dvcsブランチがローカルファイルで「適切に」機能する方法を説明した後、彼はかなり混乱しました。 彼は、TFSのしくみと同様に、「ブランチ」を作成したい場合はクローン作成によって行うので、リポジトリの完全なコピーを持っていると説明しました。これは本当に奇妙に思えましたが、私が認めなければならない利点は、ファイルが別々であるため、2つのブランチを同時に見たり作業したりできることです。 このサイトを検索して、多くのオンラインリソースがこの「クローンからブランチへ」の方法論を宣伝するコメントを見る前にこれが尋ねられたかどうかを確認する際に、ポスターを落胆させました。これは実際にdvcsコミュニティで一般的ですか？そして、この道を行くことの長所と短所は何ですか？一度に複数のブランチを表示する必要がなく、切り替えが高速で、すべてのクローンがディスクをいっぱいにする必要がないため、それを行うことは決してありません。

9 workflows  dvcs  branching