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

コードで重要でないタイプミス（たとえば、print（error）ステートメントの誤ったアポストロフィ）に遭遇した場合、そのエラーを解決するためにコミットする価値がありますか、それともそのままにしておくべきですか？ 具体的には、これらの重要ではないタイプミスを解決する価値に対して、コミットログのガムアップを比較検討することに興味があります。私はそれらを解決することに傾いています。私はつまらないですか？

67 version-control  grammar 

「大規模なコミットをしないでください」と聞いたことがありますが、「大規模な」コミットとは何かを実際に理解したことがありません。関連していても大量のファイルを扱う場合、それは大きいですか？プロジェクトのどの部分を一度に作業する必要がありますか？ 私にとって、他の何かを作成する何かを作成することを忘れたり作成したりするため、「小さなコミット」をしようとするのに苦労しています。その後、次のようなものになります。 カスタム発信キューを作成しました ボット -SingleThreadExecutorにすぎない新しいフィールドmsgQueue -sendMsgは、メッセージが送信されるまでブロックし、メッセージが取得されるまで待機します 送った -adminExist呼び出しが更新されました（コントローラーを参照） -sendMessageの呼び出しを削除 コントローラ -新しいフィールドmsgWaitは、メッセージ間の待機時間を示します -サービスプラグインの開始はreloadPluginsに移動しました -adminExistsは、グローバル管理者のためにサーバーから移動しました。チャンネルで確認し、 サーバー、およびグローバルレベル 管理者 -適切なオブジェクトAdminを取得する新しいメソッドgetServerおよびgetChannel 属する BotEvent -toString（）もextraとextra1を表示します チャネル -nameに名前が変更されたチャネルフィールド -channel（int）のタイプミスを修正 サーバ -管理者をコントローラーに移動しました PluginExecutor -マイナーテストが追加され、後で削除されます JSプラグイン -フレームワークの変更を更新 -InstanceTracker.getController（）をController.instanceに置き換え -VLCトークは独自のファイルで さまざまなNBプロジェクトの更新と変更 --- 影響を受けるファイル /trunk/Quackbot-Core/dist/Quackbot-Core.jarを変更します /trunk/Quackbot-Core/dist/README.TXTを変更します /trunk/Quackbot-Core/nbproject/private/private.propertiesを変更します /trunk/Quackbot-Core/nbproject/private/private.xmlを変更します /trunk/Quackbot-Core/src/Quackbot/Bot.javaを変更します /trunk/Quackbot-Core/src/Quackbot/Controller.javaを変更します /trunk/Quackbot-Core/src/Quackbot/PluginExecutor.javaを変更します /trunk/Quackbot-Core/src/Quackbot/info/Admin.javaを変更します /trunk/Quackbot-Core/src/Quackbot/info/BotEvent.javaを変更します /trunk/Quackbot-Core/src/Quackbot/info/Channel.javaを変更します /trunk/Quackbot-Core/src/Quackbot/info/Server.javaを変更します /trunk/Quackbot-GUI/dist/Quackbot-GUI.jarを変更します /trunk/Quackbot-GUI/dist/README.TXTを変更します /trunk/Quackbot-GUI/dist/lib/Quackbot-Core.jarを変更します /trunk/Quackbot-GUI/nbproject/private/private.propertiesを変更します /trunk/Quackbot-GUI/nbproject/private/private.xmlを変更します /trunk/Quackbot-GUI/src/Quackbot/GUI.javaを変更します …

65 version-control 

私は継続的インテグレーションに関するMartin Fowlerのメモを読んでおり、彼は必須項目として「毎日メインラインにコミットしている」としています。 私が取り組んでいるセクションが完全でない限り、コードをコミットするのは好きではありません。実際には、3日ごとにコードをコミットします：1日目はタスクを調査/再現し、いくつかの予備的な変更を行い、2日目は変更を完了します、そして3日目でテストを書き、提出のためにクリーンアップします^。コードをもっと早く提出するのは気が進まないでしょう。 現在、リポジトリから変更を取得し、通常は1日に2回ローカルに統合しますが、小さな作業を分割できない限り、頻繁にコミットしません。 質問：毎日コミットすることは、それを順応させるためにワークフローを変更する必要があるほど良い習慣ですか、それともお勧めできませんか？ 編集： CVSの意味で「コミット」（別名「プッシュ」）を意味していることを明確にすべきだったと思います。 ^順序はより任意であり、タスクに依存します。私のポイントは、正確なシーケンスではなく、時間とアクティビティを説明することでした。

63 version-control 

更新 私は4人の開発者の小さなチームで働いています。それらはすべてソース管理を使用しています。それらのほとんどはソース管理に耐えられず、代わりに使用しないことを選択します。ソース管理は専門能力開発の必要な部分だと強く信じています。いくつかの問題により、ソース管理を使用するように説得することが非常に困難になります。 チームはTFSの使用に慣れていません。2回のトレーニングセッションを行いましたが、1時間しか割り当てられていませんでした。 チームメンバーは、サーバー上のコードを直接変更します。これにより、コードが同期しなくなります。最新のコードで作業していることを確認するためだけに比較が必要です。そして、複雑なマージの問題が発生します 開発者が提供する時間の見積もりには、これらの問題の修正に必要な時間は含まれていません。ですから、nonoと言うと10倍時間がかかります...これらの問題を絶えず説明し、自分自身を危険にさらす必要があります。 サーバー上の物理ファイルは、〜100ファイルにわたって未知の点で異なります。マージには、当面のプロジェクトの知識が必要であり、したがって、開発者の協力を得ることはできません。 他のプロジェクトは同期していません。開発者はソース管理に不信感を持ち続けているため、ソース管理を使用しないことで問題を悪化させています。 開発者は、マージはエラーが発生しやすく、難しいため、ソース管理の使用は無駄だと主張します。これは議論するのが難しいポイントです。なぜなら、ソース管理がひどく誤用され、ソース管理が継続的にバイパスされると、間違いが起こりやすいからです。したがって、彼らの見解では証拠は「それ自身のために語る」。 開発者は、サーバーコードを直接変更し、TFSをバイパスすると時間を節約できると主張します。これも議論するのが難しいです。開始するコードを同期するために必要なマージには時間がかかるためです。これに私たちが管理する10以上のプロジェクトを掛けます。 永続ファイルは、多くの場合、Webプロジェクトと同じディレクトリに保存されます。そのため、公開（完全公開）は、ソース管理にないこれらのファイルを消去します。これはまた、ソース管理に対する不信感を引き起こします。「公開するとプロジェクトが壊れる」ためです。これらの場所はweb.configで設定されておらず、多くの場合複数のコードポイントに存在するため、これを解決する（保存されたファイルをソリューションサブフォルダーから移動する）には多大な時間とデバッグが必要です。 だから、文化はそれ自体が持続します。悪い習慣はより悪い習慣を生みます。悪い解決策は、新しいハックを駆り立てて、より深く、より時間のかかる問題を「修正」します。サーバー、ハードドライブのスペースを手に入れるのは非常に困難です。それでも、ユーザーの期待は高まっています。 この状況で何ができますか？

62 version-control  teamwork  team-foundation-server  cowboy-coding 

Googleにはすべてのコードの巨大なプライベート（内部）リポジトリがあり、従業員はそこにアクセスできるので、開発中に車輪を再発明する必要はありません。私はそれについてもっと知りたいです！ Googleからもう少し詳しく説明できる人はいますか、それについてもう少し知っていますか？私は主に、それがどのように構成され、従業員がそのような巨大なコードベースで必要なものを簡単に見つけられるようにする方法について知ることに興味があります。

62 version-control  google 

独立した開発者であれば、バージョン管理を使用する価値があると思いますか？リポジトリを自分のコンピューター、またはバックアップとして使用できる他の場所に保管していますか？

60 version-control  solo-development 

プロジェクトで作業する場合、コードは1日でかなり高速に開発される場合もあれば、数週間/月/年の長期にわたって少しずつ開発される場合もあります。コードコミットはプロジェクト開発の指標と見なされるようになっているため、コミットが少ないプロジェクトよりも多くのコードが記述されているという意味ではありません。 では、問題は、いつコミットを正当化できるようにリポジトリに実際にコミットするかです。 アドオンとして：コミットに基づいてプロジェクトの開発を測定することは正しい習慣ですか？

59 programming-practices  version-control  coding 

私たちは、プロジェクトの1つに貢献する必要がある非プログラマー（ライター）と協力しています。 現在、彼らは自分の作業をバージョン管理するためにGit（またはそのことは何でも）を使用するという考えを嫌っています。これは、バージョン管理のねじれた概念に頭を悩ませるだけの価値がないためだと思います。（私が最初にそれらをブランチとマージに紹介したとき-彼らは私がそれらを怒らせていたように見えました。） 今、私たちは彼らを教育したり、それを使うように説得する立場にはありません。私たちは、彼らのすべての作業をバージョン管理するための代替案を探しています（これが必要なものです）-彼らは簡単なワークフローを取得し、彼らの仕事に集中します。 私はいくつかのアイデアを思いつきました... 自明ではない変更を行うたびに作業を個別のファイルとして保存するように指示し、変更を追跡するために差分を使用します。 CSSEditの「マイルストーン」を何らかの方法で実装するプログラムを（Pythonで）作成します。 プロジェクトについて： これは自然言語処理システムです（C + Pythonで記述されています）。さまざまな言語でシステムの入力を準備するために、いくつかのライターを雇いました。そして、ソフトウェアを進化させると、それらのライターが入力（記事）を変更する必要があります。時々、変更は非常に小さい（1つか2つ）こともあれば、大きくなることもあります。 これらの変更をバージョン管理する必要があるのは、入力のあらゆる小さな/大きな変更がシステムの出力を劇的に変更する可能性があるためです。

57 programming-practices  version-control  teamwork 

データベースファイル（スクリプトなど）をソース管理する必要がありますか？もしそうなら、それをそこに保持し、そこで更新する最良の方法は何ですか？ データベースファイルをソース管理する必要もあります。開発サーバーに配置して、誰でも使用でき、必要に応じて変更を加えることができるからです。しかし、その後、誰かがそれを台無しにした場合、それを取り戻すことはできません。 ソース管理上のデータベースに最適なアプローチは何ですか？

57 database  version-control 

仲間の開発者が新しいDrupalプロジェクトの作業を開始し、システム管理者は「更新を簡単にスクリプト化できるようにする」ため、sites / defaultサブディレクトリのみをソース管理に配置することを提案しました。このやや疑わしい主張を別にすれば、別の疑問が生じます。どのファイルをソース管理下に置くべきでしょうか？また、いくつかの大きなファイルを除外する必要がある状況はありますか？ 私の意見では、プロジェクトのツリー全体を制御する必要があり、これはDrupalプロジェクト、レール、またはその他のすべてに当てはまります。これは簡単なように思えます。作成するカスタムコードの場合と同様に、フレームワークのバージョン管理が明らかに必要です。 とはいえ、これについて他の意見を聞きたいと思います。すべてを制御下に置いていないという議論はありますか？

54 version-control  drupal 

バージョン管理から削除する必要があるソースファイルの処理方法が悪い習慣と見なされるかどうかを知りたかったのです。 その例に基づいて説明します。 基本的にデッドコードであるプログラムのJavaクラスを退屈に整理しなければならなかったので、最近非常に怒った。もちろん、それらは削除する必要がありましたが、私はそのような冗長なものを削除する前に-奇妙なことを言うかもしれません-習慣があります： 私はSVN-> Deleteを介してそのような冗長ファイルをすぐに削除しません（選択したバージョン管理システムの削除コマンドに置き換えます）代わりにそれらのファイルにコメントを入れます（私は頭とフッターの両方を参照します）削除されます+私の名前+日付-さらに重要なこと- それらが削除された理由 次に、保存してバージョン管理にコミットします。次回プロジェクト内の何かをバージョン管理にコミット/チェックインする必要があるとき、SVN-> Deleteを押すと、最終的にバージョン管理で削除されます-もちろん、修正によって復元できます。そのため、この習慣を採用しました。 すぐに削除するのではなく、なぜこれを行うのですか？ 私の理由は、少なくともそれらの冗長ファイルが存在した最後のリビジョンに明示的なマーカーを持ちたい、なぜ削除するに値するのかということです。それらをすぐに削除すると、それらは削除されますが、削除された理由はどこにも文書化されていません。私はこのような典型的なシナリオを避けたい： 「うーん...なぜそれらのファイルが削除されたのですか？私は以前はうまく動いていました。」（「元に戻す」を押す->元に戻す人は永遠になくなるか、次の週に利用できなくなり、次の担当者は私のような退屈なファイルの内容を知る必要があります） しかし、コミットメッセージでそれらのファイルが削除された理由に注意しませんか？ もちろんやりますが、コミットメッセージが同僚によって読まれない場合があります。（私の場合は死んでいる）コードを理解しようとするときに、最初にバージョン管理ログと関連するすべてのコミットメッセージを確認するのは、典型的な状況ではありません。同僚はログをクロールする代わりに、このファイルが役に立たないことをすぐに確認できます。時間を節約でき、このファイルはおそらく復元された可能性が高いことを知っています（または、少なくとも問題が発生します）。

53 version-control  svn  evidence-based 

私は成長中のプログラマーで、GitHubに保存しているライブラリの単体テストを最終的に実践しています。 レポジトリにテストスイートを含めることができたのですが、他のプロジェクトを見てみると、テストを含めるのは失敗したように思えます。 これは悪い形と見なされますか？ユーザーは作業コードにのみ興味があり、とにかく自分のフレームワークでテストするという考えはありますか？

50 version-control  unit-testing 

私の会社は、約3か月前にSubversionからGitに切り替えました。切り替えの数週間前に事前通知がありました。Git（または他のDVCS）を使用したことがないため、Pro Gitを読んで、自分のリポジトリを回転させて遊んでいるので、切り替えたときに最小限の痛みで作業を続けることができます。今、私はデフォルトで「Git guy」です。 いくつかの例外はありますが、私のチームのほとんどはGitがどのように機能するのかまだわかりません。たとえば、彼らはまだブランチをソースコードの完全なコピーと考えており、レポを複数のフォルダー（ブランチごとに1つ）に複製することさえしています。彼らは通常、Gitを恐ろしいブラックボックスと見なしています。 私たちの日常業務におけるソース管理の基本的な性質を考えると（Gitが提供する途方もない量のパワーは言うまでもありません）、私はそれである程度の習熟度を達成しない開発者は責任があると考えています。 私のチームに、Gitが内部的にどのように機能するか、そして最も基本的なプル/マージ/プッシュ操作を超えてGitを使用する方法について少なくともある程度理解してもらう必要がありますか？それとも、私はただ何もないところから何かを作っているのですか？

48 version-control  professionalism 

私のチームはソース管理にTeam Foundation Serverを使用しています。今日、チェックインする前にいくつかのバグとスモークテストアプリケーションを修正しましたが、コードをコメントするのを忘れていました。（このコードにより、UIが少し奇妙になりました。） コードをチェックインする前に、どのような優れたプラクティスがあるのか​​を知りたい-この種の間違いを二度とやりたくない。

47 version-control  team-foundation-server  configuration-management 

同じソフトウェア/プログラム/アプリ/スクリプトの2つの異なるバージョンを作成し、バージョン管理下に保存しているとしましょう。最初のバージョンは無料の「ベーシック」バージョンで、2番目は有料バージョンの「プレミアム」バージョンで、無料バージョンのコードベースを取得し、いくつかの付加価値機能で拡張します。新しいパッチ、修正、または機能は、両方のバージョンへの道を見つける必要があります。 現在、有料版のサイドとブランチに沿って、メインコードベース（無料版）のブランチを使用することmasterを検討していdevelopます。無料版に変更が加えられ、ブランチにマージされると（もちろん徹底的なテストの後）、さらにテストするためにコマンドを介してブランチにコピーされ、にマージされます。master-premiumdevelop-premiummasterdevelopdevelop-premiumcherry-pickmaster-premium これは、この状況を処理するのに最適なワークフローですか？認識すべき潜在的な問題、警告、または落とし穴はありますか？私がすでに思いついたものよりも良い分岐戦略がありますか？ あなたのフィードバックは大歓迎です！ PSこれはGitに保存されているPHPスクリプト用ですが、回答はすべての言語またはVCSに適用する必要があります。

45 version-control  workflows