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

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

3
ホットフィックスの処理中の複数のアクティブなリリースに対する適切なGitワークフロー
私の製品に最適なGitワークフローを選択しようとしています。パラメーターは次のとおりです。 年に数回のメジャーリリースを行っています。 製品の複数のバージョンが同時にアクティブになっています（v10.1、v11.2など）。 同時に複数のリリースで作業できるようにする必要があります（v12.1で作業できるようになりましたが、リリースの終わりに達すると、v12.2で作業を開始します） 重大なバグが見つかった場合、リリースを修正できる必要があります これまでのところ、ここで私はそれがうまくいくと思う方法です： 単一のリモートリポジトリが使用されます マスターからブランチ12.1を作成します 12.1に基づいて機能ブランチを作成し、コミットして12.1にマージしてプッシュ 将来のリリースで作業を開始する必要がある場合は、12.1に基づいて新しいブランチ12.2を作成します その後、12.1の機能で作業する場合、12.1からブランチを作成し、変更をコミットし、12.1と12.2の両方にマージします 12.2の機能で作業している場合、12.2からブランチを作成し、変更をコミットし、12.2にのみマージします リリース12.1が完了したら、それをマスターにマージし、12.1でマスターブランチにタグ付けします 修正プログラムが必要な場合は、それを必要とする最も古いリリースブランチから修正プログラムブランチを作成し、変更をコミットし、そのリリースと影響を受ける可能性がある将来のリリースのすべてのリリースブランチにマージします。最新の安定版リリースブランチが影響を受けた場合は、マスターにマージします。 私はいくつかの懸念があります： 特に多くの重複する変更があった場合、古いブランチから新しいブランチへのホットフィックスのマージがスムーズなプロセスになるかどうかはわかりません。競合があるように見える場合は、各ブランチで手動で修正プログラムを適用する方が賢明でしょうか 私が見たワークフローモデルは、リリースブランチがあまり生き残っていないようです。いったんリリースがマスターにマージされ、タグが付けられ、削除されます。私の問題は、マスターのタグがすべてある場合、リリースの状態を管理する方法がわからないことです。ブランチで修正する方が簡単なようで、いつでも戻ることができるリリースがあります最新の修正プログラムが含まれています（リリースの修正プログラムにタグを付けることもできます）。マスター内に戻って、修正プログラムが適用されたリリースのコピーを適用し、そのタグを更新する方法があるかどうかはわかりません。 私が見落としているかもしれないことや、私が指定した要件を考慮して物事を達成するより良い方法についてのコメントを歓迎します。
3
複数のサブプロジェクトでプロジェクトを分離する場合
私が取り組んでいるプロジェクトを1つではなく2つのリポジトリに分割することが理にかなっているかどうかを知りたいです。 私が言えることから： フロントエンドはhtml + jsで記述されます .netのバックエンド バックエンドはフロントエンドに依存せず、フロントエンドはバックエンドに依存しません フロントエンドは、バックエンドに実装された安らかなAPIを使用します。 フロントエンドは、任意の静的httpサーバーでホストできます。 現在、リポジトリは次の構造を持っています。 ルート： フロントエンド/* バックエンド/ * 両方のプロジェクトを同じリポジトリに保持するのは間違いだと思います。両方のプロジェクトは相互に依存関係を持たないため、個々のリポジトリと、必要に応じてサブモジュールを持つ親リポジトリに属する​​必要があります。 私はそれは無意味であり、それを行うことで利益を得ることはないと言われました。 私の議論のいくつかを以下に示します。 相互に依存しない2つのモジュールがあります。 長期的に両方のプロジェクトのソース履歴があると事態が複雑になる可能性があります（探しているバグとはまったく関係のないコミットの半分がある間にフロントエンドで何かを探してみてください） 競合とマージ（これは起こらないはずですが、誰かがバックエンドにプッシュすると、他の開発者がバックエンドの変更をプルしてフロントエンドの変更をプッシュすることになります。） 1人の開発者はバックエンドでのみ作業するかもしれませんが、常にフロントエンドを引っ張る必要があります。 長い目で見れば、いつ配備するのか。何らかの方法で、フロントエンドを複数の静的サーバーにデプロイし、バックエンドサーバーを1つ持つことができます。いずれの場合も、バックエンド全体を複製するか、すべてのサーバーにフロントエンドのみをプッシュするか、バックエンドを削除するカスタムスクリプトを作成する必要があります。1つだけが必要な場合は、両方よりもフロントエンドまたはバックエンドのみをプッシュ/プルする方が簡単です。 反論（1人が両方のプロジェクトで作業する可能性があります）、サブモジュールで3番目のレポを作成し、それで開発します。履歴は個々のモジュールに分けられており、バックエンド/フロントエンドのバージョンが同期して実際に連携するタグをいつでも作成できます。フロントエンドとバックエンドの両方を1つのリポジトリにまとめても、それらが連携して機能するわけではありません。両方の履歴を1つの大きなレポにマージしているだけです。 サブモジュールとしてフロントエンド/バックエンドを使用すると、プロジェクトにフリーランサーを追加する場合に物事が簡単になります。場合によっては、コードベースへの完全なアクセス権を実際に与えたくないことがあります。「外部者」が表示/編集できるものを制限したい場合、1つの大きなモジュールがあると事態が難しくなります。 バグの紹介とバグの修正のために、フロントエンドに新しいバグを挿入しました。その後、誰かがバックエンドのバグを修正します。1つのリポジトリで、新しいバグの前にロールバックすると、バックエンドもロールバックされ、修正が困難になる可能性があります。フロントエンドのバグを修正しながらバックエンドを動作させるには、別のフォルダにバックエンドをクローンする必要があります...その後、物事を再マージしようとします... 1つのリポジトリのHEADを移動するので、2つのリポジトリを作成するのは簡単です他を変更しないでください。また、異なるバージョンのバックエンドに対するテストは簡単です。 誰かが私を説得するためにもっと議論をすることができますか、少なくともプロジェクトを2つのサブモジュールに分けるのが無意味な（より複雑な）理由を教えてください。プロジェクトは新しく、コードベースは数日前のものなので、修正するのに早すぎません。
10
ソロ開発者としてコミットメッセージを作成しますか？
私と他のプログラマとの間でリポジトリが共有される私のプロジェクトでは、私が主な開発者であっても、常にコミットメッセージを書き込みます。 しかし、私がプロジェクトに取り組んでいるソロ開発者であり、リポジトリが私のラップトップでホストされており、クライアントによってさえホストされていないプロジェクトでは、私以外の誰もコミットを見ることができませんメッセージ？ これまで私はそれらを書いてきましたが、私は決して戻ってコミットメッセージを見たことがないことに気付きました。メッセージを書き留めるために開発に時間をかけますが、それでも私には二度と見られません。 単独の開発者としてコミットメッセージを書く正当な理由はありますか、それともスキップして開発に専念することをお勧めしますか？
11
ソース管理のバイナリ
組み込みデバイスやその他の奇妙な世界向けに開発する場合、ビルドプロセスに非常に特殊なバージョンを使用する複数の独自のバイナリが含まれる可能性が非常に高くなります。質問は、ソース管理の一部ですか？私のオフィスでは、「ソース管理からのチェックアウトにはコードをコンパイルするために必要なすべてが含まれます」というルールに従っており、これはいくつかの深刻な議論につながっています。 これに対する主な議論は、ソース管理DBの肥大化、バイナリファイルの差分の欠如です（この件に関する以前の質問を参照）。これは、前の開発者が意図した正確な環境があることを確認し、ビルドし、適切なファイルを探し出すことなく（特定のバージョンも同様に！）
9
単独で、または小さなプロジェクトで作業するときに、何らかの種類のバージョン管理を使用していますか？
非常に多くの場合、私は自分だけの小さなプロジェクトに取り組んでいます。私は1台のマシンで作業していますが、最近、何らかのバージョン管理を使用することを考えました。これには、たとえば次のような利点があります。 ローカルバックアップを気にする必要はもうありません 間違いは簡単に元に戻すことができます 履歴を維持できます しかし一方で、たとえば次のような欠点もあります。 追加のリソースが必要 設定する時間、慣れる時間など あなたの経験から、一人で作業するときにリビジョン管理を使用するのは良いことですか？
3
書き換えのバージョン管理の実践
製品（プロトタイプ）P_OLDを言語Xで開発し、現在は言語YでP_NEWとして最初から書き直しています。 P_NEWとP_OLDは同じ製品であるため： P_NEWは古いP_OLDのブランチである必要がありますか、それとも独自のリポジトリである必要がありますか？ バージョン管理の観点からこのような大きな変更を処理する通常の方法は何ですか？
10
一時的なコードはバージョン管理下に置くべきですか？
一時/ローカルコードの例を次に示します。コードベースを操作するために必要ですが、その一部であると有害です： プロジェクトファイル。現在のPCのレイアウトを反映するために、パスを編集する必要がある場合があります。 メイクファイル。たとえば、デバッグ中は最適化をオフにする必要がありますが、CIサーバーはオフにする必要はありません。 汚いいハッキング。たとえばreturn 7、関数に応じて、関数に応じて何かをテストするために、値7で破損する疑いがある場合、または7はまだ実装されていないボタンのコードです。私のブランチの人生。 リポジトリにプッシュしてからプッシュする前に、常にトップにリベースするgitコミットにそれらを保持しようとしましたHEAD~。これは非常に不便であり、svnでは機能しません。スタッシングは私をさらに怖がらせます-「押した後にポップするのを覚えていましたか??」。 コードをバージョン管理から外すと、コミットがアセンブルされるたびに不快なノイズが発生し、金曜日の夕方に誤ってコミットに導入される可能性があります。 このような使い捨てのコードの正解は何でしょうか？
11
あなたの最高のプログラマーは、他の全員のコードをソース管理にチェックインする必要がありますか？
svnとgitの違いの 1つは、リポジトリへのアクセスを制御する機能です。変更をコミットすることを誰に許可するべきかについての観点の違いがあるため、2つを比較するのは困難です！ この質問は、どこかの会社のチームの中央リポジトリとしてgitを使用することに関するものです。チームのメンバーのスキルレベルはさまざまであり、ほとんどの企業と同じであると想定しています。 Gitは、あなたの最高の（最も生産的で、最も経験豊富な）プログラマーだけがコードのチェックインを信頼していると想定しているようです。その場合は、実際にコードを書くのに時間を割いて、他の人のコードを確認してチェックインすることになります。これで成果はありますか？この質問は、一般的なバージョン管理のベストプラクティスではなく、最高のプログラマーの時間を最大限に活用することに焦点を当てたいと思います。当然の結果として、自分の仕事の大部分が他の人のコードをレビューすることである場合、優秀なプログラマーは辞めますか？両方の質問が要約されると思います：レビューは生産性に見合う価値があるのでしょうか？
1
本番コードで名前が間違っている関数を処理する方法は？
最近、GitHubでPythonライブラリに出会いました。ライブラリは素晴らしいですが、関数名に1つの明白なタイプミスが含まれています。dummy_fuction()それがあるべきときにそれを呼び出しましょうdummy_function()。この関数は間違いなく「インザワイルド」であり、組み込みシステムで使用される可能性が最も高くなります。 最初に思い浮かぶのは、正しい名前の関数の2番目のバージョンを追加し、次のリリースの最初のバージョンに非推奨の警告を追加することです。 3つの質問： 上記のアプローチは、意図しない結果をもたらす可能性がありますか？ この種の問題に対する標準的なアプローチはありますか？ 非推奨の警告はいつまで残しておくべきですか？
2
優れた/より良いソースコード管理慣行を実施する方法
私は間違った問題に焦点を合わせているのではないかと思うので、まず、私が思い描くかもしれない準最適な解決策を提示する前に、問題が何であるかを説明します。 現在の状況： 現在、私の同僚は、変更がプロジェクト全体に広がっている巨大な塊で、長い時間を経て初めてコードの変更をコミットします。かなり前のことですが、彼らはネットワーク共有に.zipアーカイブを置くだけだからです。それでも、マージは悪夢です-率直に言って、私はそれで十分でした。また、話したり説明したり、物beいをするのもうんざりです。これはやめなければならない-私なしで常に「悪者」である。 私の解決策： 問題に気づいていない、および/または問題に関心がないようであり、数日以上続く努力は期待できない...それを何時間も打って、subversionサーバーにそれをしてもらいたいしつこい。 私の質問： 私はここから離れたところにいるのでしょうか、それとも間違った問題を見ていますか？私は何かを見逃しているようで、問題を解決するツールを見ることで間違ったことを尋ねていると思います。 この問題を解決するツールを探しているべきですか、それともこれを修正するために何をすべきですか？
4
ゼロ知識コードのホスティング？[閉まっている]
オンラインサービスプロバイダーによって保存されたデータの政府による広範囲な監視に関する最近の啓示に照らして、現在、ゼロ知識サービスが大流行しています。 ゼロ知識サービスは、すべてのデータがサーバーに保存されていないキーで暗号化されて保存されるサービスです。暗号化と復号化は完全にクライアント側で行われ、サーバーはプレーンテキストデータまたはキーを認識しません。その結果、サービスプロバイダーは、たとえ暗号化を解除したい場合でも、第三者にデータを解読して提供することはできません。 例を挙げましょう。SpiderOakは、Dropboxのゼロ知識バージョンとして見ることができます。 プログラマとして、私たちはコードのホスティングサービス（Bitbucket、Assemblaなど）の特定のクラスに対して、最も機密性の高いデータ（コード）に大きく依存し、信頼しています。もちろん私はここでプライベートリポジトリについて話しています-ゼロ知識の概念はパブリックリポジトリには意味がありません。 私の質問は： ゼロ知識コードホスティングサービスを作成するための技術的な障壁はありますか？たとえば、SVN、Mercurial、Gitなどの一般的なバージョン管理システムで使用されるネットワークプロトコルについて、クライアントとサーバー間で通信されるデータを暗号化するスキームの実装を困難（または不可能）にするものがありますか？サーバーが知らないキー？ 今日存在するゼロ知識コードホスティングサービスはありますか？
10
間違ったブランチで作業することをどのように回避しますか？
通常、問題を回避するには注意するだけで十分ですが、時々、ランダムのソース管理パスをチェックして、作業中のブランチを再確認する必要があります（例：「うーん... devブランチにいますか？」）ファイル。 もっと簡単な方法を探して、それに応じてソリューションファイルに名前を付けることを考えました（例 MySolution_Dev.sln）が、各ブランチで異なるファイル名を使用して、ソリューションファイルをマージすることはできません。 大したことではありませんが、正しいブランチにいることをすばやく確認するために使用する方法や「小さなトリック」はありますか？TFS 2008でVisual Studio 2010を使用しています。
18
SourceSafeは本当に安全ですか？
午前中ずっと何かをチェックしようとして過ごしたので、今では2日間分の仕事を失いました。 その前に起こった-と明らかにSourceSafeで一般的な発生です。SourceSafeは問題なく正常に使用できますか？
11
分散型バージョン管理システムのビジネスケース
git / mercurial / bazzrシステムが集中システム（subversion、perforce）よりも優れている理由を検索しましたが、ビジネス上の理由は見つかりませんでした。 DVCSを非技術者に販売しようとした場合、DVCS が利益を上げるためにどのような議論を提供しますか。 私はまもなくマネージャーにgitを売り込みます。subversionリポジトリーの変換には少し時間がかかり、smartgitライセンスの購入にはいくらかの費用がかかります。 編集私はこの質問を集中型と分散型の一般的な議論にしようとしましたが、必然的にgit vs subversionに変わりました。確かに、転覆よりも優れた集中システムがあります。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.