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

一般的な規則は、チェックインを小さくし、頻繁にチェックインすることです。ただし、場合によっては、基になるフレームワークに大幅な変更を加える必要があります。次に、タスクを完了する前にチェックインすると、完成した作業をチェックインするまでプロジェクトが中断されます。 それで、仕事を失うリスクを減らすために、またはあなたがしていることを決定するために人々がどのような戦略をとっていますか？ 可能な場合は、半分完了した作業をコメントアウトしてチェックインします。または、コンパイルして新しいファイルを使用していない場合は、それらをチェックインします。変更が大きいほど、プロジェクトをブランチしてからマージし直す可能性が高くなります。すべてが再び機能するようになったとき。ソース管理システムが許可する場合の別のオプションは、基本的に小さなブランチであるシェルフセットです。そのため、その日のうちに終了するか、決定ポイントに到達したら、変更を保留します。そして、何か壊滅的な事態が発生した場合、またはそのポイントに戻りたい場合は、それを行うことができます。

9 version-control 

1つの長いフラットなコミット履歴の代わりに、階層がないのはなぜですか。そのため、トップレベルでプルリクエストがあり、レベルを下げてそのPRのコミットを確認できます。PRはgithubに固有のものであると思いますが、あなたはそのアイデアを理解しています。たとえば、いくつかのコミットを機能やバグ修正としてグループ化することを意味します。 確かに、コミット履歴をナビゲートしやすくなります。 この質問には明白な答えがあると思いますが、それを見つけることができないようです。

9 version-control  git 

あなたはそれがどのように行われるかを知っています：作業の95％を迅速に自動化する方法を見つけたいくつかの小さな反復的なタスクがあります。スクリプトを作成して実行し、出力を手動で修正すれば完了です。もちろん、スクリプトは会社の品質要件に適合しないため、コミットしません（ドキュメントもテストもないため）。 しばらくして、同じような作業をしている同僚がいます。あなたは「ねえ！そのためのスクリプトを作成しました。調べてみましょう。[見える]ああ、それは以前のラップトップに保管されていたので、もう持っていません。残念です。」 これらのスクリプトは多くの場合、多くの時間を節約することができ、チームのリーダーとして、バージョン管理に保存してほしいと思います。ただし、他のコードベースと同じ厳格な標準をこれらのスクリプトに課すと、ほとんどの開発者はそれらを自分たちに守ってくれると思います。 私が思い付くことができる他の唯一のオプションは、開発者がバージョン管理の特別な部分にスクリプトを保存できるようにすることです。バージョン管理の（GitHub Gistsのように）品質管理はありません。リスクは、他の人がコードを見つけたり理解したりできないためにコードを使用できないことです。 この問題はどのように解決できますか？それとも解決すべきではないのですか？

8 programming-practices  version-control  teamwork 

Q＆Aシステムに取り組んでいて、現在のアプリケーションに最初の公式バージョン/タグとして「1.0.0」のタグを付けようとしています。ベータテストのために、次に限定されたテスト対象者にロールアウトするところです。この段階で「1.0.0」は正しいですか？ また、その段階で多くのバグが見つかることは間違いありません。「1.0.0」のままにしておきますが、リリースされるまでタグを強制的に移動します。または、バグを修正したら、新しいタグ「1.0.1」を付けますか。その後、おそらく「1.0.2」のテストを繰り返します。 したがって、拡張機能（たとえば、新しいメニュー、新しい検索入力フィールドなどの新機能）に取り組む場合、これらは「1.0.0」から「1.1.0」へのように小さな変更でしょうか？

8 version-control  git  semantic-versioning 

今月から新しいプロジェクトを開始します。プロジェクトは1年間で、本番環境への展開はプロジェクトの終わり頃にのみ行われます。 反復的な開発（反復ごとに1か月）を行うため、これは、QAテストの各反復の終わりに機能をテスト環境にドロップすることを意味します。 私たちの分岐戦略は： トランク-すべての開発はトランクで行われます。 機能の分岐-トランクから分岐すると、大きな機能を開発するために必要に応じて作成され、トランクで実行すると壊れる可能性があります。 QAリリースブランチ-各反復の最後に、トランクのブランチが作成されます。このブランチ（バージョン番号を含む）は、テスト環境にリリースされます。このバージョンで発見されたすべての重大なブロッキングバグはこのブランチで修正され、修正はトランクにマージする必要があります。新しいリリースブランチがトランクから作成される次の反復の終了後にQAリリースブランチが破棄されるため、重大ではない/重要でないバグはQAリリースブランチでは対処されず、トランクでのみ修正されます。 本番ブランチ-これは、プロジェクト終了時の最新のQAリリースブランチになります。これはタグ付けされ、すべての製品バグ修正はこのブランチにあり、トランクにマージされます。 これは正しい分岐戦略ですか？他に検討し損なったことはありますか？ SVNを使用しています。

8 version-control  branching 

維持する必要のある（大きな）テストファイルがいくつかあります。これは、彼らの歴史へのアクセスが要件であることを意味します。 利点 新しい開発者は、だけでテストスイート全体を入手できgit pullます。 ファイルの履歴がバックアップされます。 ファイル自体がバックアップされます。 欠点 リポジトリのサイズが大幅に増加しました。 リポジトリをコピーする新しい開発者のダウンロードサイズが大幅に増加します。 テストファイルを維持するためのベストプラクティスは何ですか？ これらのファイルをソース管理に保存しますか？代替案はありますか？

8 testing  version-control  files 

私は最大5人の（ウェブ）開発者がいる小さなチームで働いています。私たちのチームは頻繁に成長しており、複数の人が同じコードで作業しているときに問題が発生したため、VCSをセットアップすることにしました。 現在の状況 現在、中央開発サーバー（LAMP）を使用しています。したがって、すべての開発者が同じコードベースで作業し、コードがテストされてライブサーバーの準備ができている場合は、ftp経由でコードをコピーするだけです。私はこれがanno 1600ワークフローの一種であることを知っていますが、そうです。それが何であるか、そしてこの質問の理由でもあります。 開発サーバーでは、ディレクトリ構造は次のようになります。 /var/www /Project1 /Project2 /Project3 ... さらに、いくつかの小さな非Webアプリケーション-Android / iPhone / Windows 8などのアプリといくつかのC＃ツールもあり、これらもVCSに含める必要があります。 目標と問題 私たちの目標は、VCSのクリーンセットアップを取得することです。VCSは、問題追跡ソフトウェアと連携し、コードを上書きせずに同じプロジェクトで同時に作業できるようにし、バージョン管理の利点を提供します。 私たちにとっての最初の質問は、どのテクノロジーを使うべきかということだと思います。私たちの一部は、すでに転覆を経験しています。しかし、gitはある種の「標準」になり、多くの「プロgit」の議論がWebユーザーの間で存在するため、私たちはgitを使用する傾向があります。 不確実性が始まります。git-分散型VCS-を使用する場合、各開発者のコ​​ンピューターで別個の開発サーバーの使用を開始する必要があるようです。それに関する問題は次のとおりです。 ときどき別のコンピューターで作業するため、コードのプッシュを忘れると問題が発生します。 開発サーバーはライブサーバーと同じである必要があるため、仮想マシンで作業する必要があります（これは私たちの環境では強制できないため、不可能だと信じています）。 開発サーバーは通常、「トライアウト」または「プレゼンテーション」サーバーとしても機能し、開発者以外の人が何が起こっているのかを確認できました。 単一の（！）開発サーバーを使用しながらシステムから利益を得ることができるように、gitで別の可能なセットアップはありますか？たぶん、開発者ごとに異なるディレクトリがあります。または、作業中のファイルをロックし、リポジトリにコミットして、同じコードベースで作業することはできますか？それが私たちにとっての要因になった一方で、複数の開発者がアプリケーションの同じ部分で同時に作業することはまだ珍しいと言うことが重要かもしれません。

8 web-development  version-control  git  svn 

休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 分散型の問題追跡は、私にとってベルトのような考えのように見えますが、実際に大きな成功を収めたことはありません。その正当な理由はありますか？ 気がついた： どこでもバグズ セットアップするには複雑すぎる 要件が多すぎる ある程度成功し、一部の大規模プロジェクトで使用されている 化石 あまりにも多くのものを統合しようとし、最終的にそれらすべてのやや悪いバージョンになります-おそらく、まともな（おそらく私が見た中で最高の）分散型問題追跡部分を除いて 他のいくつかの小さなプロジェクト どれも牽引力を獲得していません 私は自分で作ることを考えていますが、始める前に、他の誰もが大きな成功を収めていない理由を知りたいと思います。 予想される問題：（すべて克服できると思います） 更新された分散問題をマージすることは、コードファイルをマージするのと同様に複雑です。 コメントはいつでも入ってくる可能性があり、おそらく正しいフローではないため、会話の継続性が破壊される可能性があります 最新の問題がある中央サーバーへの期待

8 version-control  issue-tracking  distributed-computing 

私は中小規模のレガシーコードベースで作業しており、チケットで作業しているときに、クリーンアップが必要なコードや、アプリケーションのフォローを理解するためだけにクリーンアップが必要なコードに遭遇します。 実際の例は次のとおりです。 if( !a && b ){ doSomething1(); doSomething2(); doSomething3(); doSomething4(); doSomething5(); }else if( a ){ doSomething1(); doSomething2(); doSomething3(); doSomething4(); doSomething5(); }else if( !b && ( a || c ) ){ doSomething1(); doSomething2(); doSomething3(); doSomething4(); doSomething5(); } もう1つは、数十のソースファイルにわたってコメントとドキュメントのタイプミスとエングリッシュを修正することです。 しかし、多くの場合、このクリーンアップは主な問題とは無関係になり、クリーンアップをコミットするのがどのように最善かと思います。私の見方では、3つのオプションがあります。 修正前：これは発生順になっているため、年代順に機能しますが、何かが壊れると修正が複雑になり、修正を本番環境と比較することが難しくなります。また、ノイズである追加のコミットが導入されます。 修正あり：しかし、これにより、欠陥のあるコードをfindGeoragphyが正しいファイルで実際に置き換えることができなくなりfindGeographyます。 修正後：これには、コードを理解し、修正を再テストし、修正をコミットしてから、元に戻ってクリーンアップをやり直すために行った削除とクリーンアップが必要です。これにより、欠陥のあるコードとの最も明確な相違が可能になりますが、作業が重複し、偽のコミットにつながる可能性もあります。 tl; dr：では、クリーンアップコードをコミットする最良の方法は何ですか？ コンテキスト：ユニットテストはありません。変更を実行し、それらを目立たせ、壁を越えてQAに送信し、手動の回帰修正によって検証することにより、開発を進めます。また、フォームのクリーンアップを行わないと、コードがわかりにくくなります。これは理想からかけ離れていることは知っていますが、これは私の選択ではなく、私の食卓に食物を載せる実際のエンタープライズ開発者です。

8 version-control 

ここで何が尋ねられているのかを知るのは難しい。この質問は、あいまいで、あいまいで、不完全で、過度に広い、または修辞的であり、現在の形では合理的に回答することができません。再開できるようにこの質問を明確にするヘルプについては、ヘルプセンターに アクセスしてください。 7年前休業。 私はあなたのほとんどがプロジェクトの戦略と方法論に沿ってアドバイスすることを知っています。 しかし、私は簡単な質問をしますが、シニアの観点から、開発者からの小さな小さなコミット、またはブランチにプッシュされた大きなコードの塊を見るには何が良いでしょうか？

8 version-control  teamwork 

リリースごとに正確な変更ログを提供したいプロジェクトに取り組んでいますが、手間をかけずに機能する変更ログを収集する方法が見つかりませんでした。問題は主に、バージョン間の時間が長く、各バージョンに多くの機能とバグ修正が同梱されている場合、およびソフトウェアに複数のブランチが同時に開発されている場合です。 私が検討したいくつかのオプション： コミットメッセージから変更ログを作成し、開発者が変更ログの行を作成する場合と同じようにメッセージを書き込むように要求します（実際には変更ログを作成します）。 複数のブランチがあり、ブランチ間でマージする場合は機能しない可能性があります（どのコミットが最終的にリリースで終わったかを知るのは難しいかもしれません）。 コードの変更ごとに、バグ追跡システムに対応するチケットが必要であることを要求します。変更ログは、チケットに基づいて書き込むことができます。 開発者は、特にバグの修正よりもチケットの作成に時間がかかる場合は、マイナーな変更のチケットを作成するだけでもイライラするかもしれません。 開発者がコードに変更を加えると同時に、常に変更ログを（プロジェクトルートのテキストファイルとして）更新する必要があります。 自動化できる手作業のように感じます。 プロジェクトマネージャーに、現在のバージョンと以前のバージョンの差分を取り、変更されたことがわかったものに基づいて、その時点で変更ログを書き込むよう依頼します。 リリースの責任者のための余分な作業。コードを見ただけでは、変更の実際的な効果が何であるかは明らかではない場合があります。 リリース予定の機能のみを出荷してください。コーディングを始める前でも、変更ログを書き込むことができます。 ウォーターフォールモデルを使用していない限り、実際のオプションではありません。 私はこれらのそれぞれまたはそれらのバリエーションを過去に使用したことがありますが、それらはあまりにも信頼性が低く、面倒で、堅固でした。問題を解決する方法について魔法の弾丸または良いアイデアを持っている人はいますか？

8 version-control  release 

私の会社は、4.0より前のVirtualBoxと同様に、独自の拡張バージョンとともに、オープンソースソフトウェアプロジェクトの開発とリリースを目指しています。 2つのコードベースを維持して、オープンソース製品への変更を簡単に商用バージョンに組み込み、誤ってプロプライエタリコードをオープンソース製品にプッシュするリスクを最小限に抑えるための最良の方法は何ですか？

8 open-source  proprietary  version-control 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 マージに関しては、各コントロールバージョンにそれを実行するエンジンがあります。競合は避けられませんが、問題は-どのリビジョン管理が競合を回避するのに最適なAIを持つかです。 そのようなものを測定することは可能ですか？ 具体的には、GITへの移行を検討しています。これは、誇大宣伝とうわさがあり、競合をより適切に処理するためです... コメントは大歓迎です...

8 version-control 

販売中のアプリを開発しているとしましょう。このプロジェクトにパブリックリポジトリを使用することには意味がありますか？デフォルトの著作権はコードを使用している他の誰かからコードを保護していませんか？もしそうなら、プライベートリポジトリに支払うことにはどのような利点がありますか？

8 version-control  git  github 

だから私は最初のGitHubリポジトリを作成し、誰かが自分のコードを投稿してはいけない理由があるのだろうかと考え始めました。他人のIPであるコードや、その他の起こりうる法的状況など、明白な意味ではありません。私は、ひどいものではあるが独自のコードを投稿する初心者について話している。 このサイトで何度か聞いたことがありますが、採用マネージャーの一部がGithub（または同様のサイト）でその人をチェックすることです。そのため、コードが不足している場合はどうなりますか？たとえば、私が上級開発者のポジションではなく、ジュニア開発者のポジションを狙っている場合、希望するポジションは重要でしょうか？

8 version-control  code-quality