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

技術的な観点から、特定のコミットをリモートのデフォルトブランチにマージする前に、ユニットテストを実行する事前/事後プッシュフックを追加することができます。 私の質問は-ビルドパイプラインでユニットテストを保持する（つまり、破損したコミットをレポに導入する）方が良いのか、それとも「悪い」コミットが発生しないようにする方が良いのかです。 私は、この2つのオプションに制限されていないことを理解しています。たとえば、マージコミットをレポジトリにプッシュする前に、すべてのコミットの分岐とテストを許可できます。しかし、この2つのソリューションを正確に選択する必要がある場合、どちらを選択しますか。

43 version-control  continuous-integration  hooks 

バグの修正/ CRの実装の一環としてコードに加えた変更ごとに、開始タグ、終了タグ、説明、解決策などのコメントを追加するよう求められています。 私の懸念は、これが付加価値を提供するかどうかです。現状では、バージョン管理履歴にすべての詳細があります。これは、すべての変更を追跡するのに役立ちますか？ しかし、私のリードは、コメントを「良い」プログラミング手法として主張しています。彼らの議論の1つは、CRのスコープを変更/変更する必要がある場合、コメントがないと面倒になることです。 変更は主にコードの中間にあると考えると、私たちが行うすべての変更にコメントを追加することは本当に役立つでしょうか？バージョン管理に任せてはいけませんか？

42 version-control  bug  comments  change 

これは、組織のニーズによって明らかに異なるため、「最良」を決定するための実際の試みというよりも議論の問題です。私は、カテゴリー（集中型vs分散型、オープンvsプロプライエタリなど）の異なるシステムを支持する議論についてもっと興味があります。 だから、最高のバージョン管理システムは何だと思いますか？

41 version-control 

PDFファイルを処理する機能のテストコードを書いています。テストの背後にある基本的な考え方は、特別に選択したいくつかのPDFにそれらを向け、それらを処理し、出力が期待どおりであることを確認することです。 私の質問は、これらの大きなPDFをどこに保存すればよいのかということです。コードとともにバージョン管理にチェックインする必要がありますか？または、それらを別の場所に配置しますか？明らかに、テストコードはPDFなしでは（または異なるPDFでさえ）役に立たないのですが、それでもリポジトリにそれらを入れることは間違っていると感じています。

40 testing  version-control  data 

ヘッダーコメント内のファイル自体にバグ番号を入れるのは良い習慣ですか？ コメントは次のようになります。 MODIFIED (MM/DD/YY) abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode cde 01/17/14 - Bug 2314558 - some other error description 役立つように思えますが、それは悪い習慣と見なされていますか？

40 version-control  development-process  source-code  comments 

動作するコードのみをコミットすることを要求するのは良い考えですか？ このコミットでは、リポジトリを次のように動作状態のままにする必要はありません。 ...設計の初期段階にありますが、コードはまだ安定していません。 ...あなたはプロジェクトの唯一の開発者です。物事がうまくいかない理由を知っています。さらに、壊れたコードをコミットして誰かの作業を停止することはありません。 ...現在、コードは機能しません。これに大きな変更を加えます。物事がugくなる場合に戻るポイントを得るために、コミットしましょう。 ...チェーンが長く、壊れたコードがローカルブランチに存在する場合は問題ありません。すなわち ローカルファイル ステージングエリア ローカルブランチでコミット リモートの個人機能ブランチでのコミット リモートdevelopブランチとマージ リモートmasterブランチとマージ リモートreleaseブランチとマージ ...早くコミットし、頻繁にコミットします。 したがって、上記のリンクされた質問では、回答の大半は、コンパイルできないコードをコミットしても、ローカルおよび機能ブランチでは問題ないと述べています。どうして？壊れたコミットの価値は何ですか？ 追加：ローカルブランチでは、好きなことは何でもできると言っている、非常に投票されたコメントがいくつかあります。ただし、質問の技術的な側面には興味がありません。むしろ、ベストプラクティス-業界で長年働いてきた人々が最も生産性を高めてきた習慣-を学びたいと思います。 膨大な量の素晴らしい答えに驚いています！彼らは、コードを整理するためにブランチを使用するのが十分ではないという結論に至ります。

40 version-control  git  branching 

複数のブランチが開発されていると言う、AとBだけでなく、増分「バグ修正」ブランチC。 今Cはすでに「完成」しており、マスターにマージされています。AそしてB、まだ開発中であり、（おそらく）別のバグ修正ブランチがmasterにマージされる前に修正されません。 C新しい機能ブランチにできるだけ早くマージすることをお勧めしますか？新しい機能がmasterできるだけ近くにあるように？それとも、新しい機能を完成させてからマスターにマージするだけで、独自の「世界」で開発することをお勧めしますか？ とにかく競合が発生するため、それらの修正に時間を費やす必要があります。

40 version-control  branching  merging 

Gitでは、適切なコミットテンプレートを設定および実施できます。 会社で実施する適切なコミットテンプレート/ガイドラインを（できれば議論を伴って）推奨できますか？

38 version-control  git  dvcs 

時々、ソフトウェアのコミット履歴を確認すると、実際には大きなコミットがいくつかあることがわかります。数百のソースコード行（デルタ）が変更された10または20のファイルが変更される場合があります。このようなBIGコミットには一般的に使用される用語がありますが、その用語が何であるかを正確に思い出すことはできません。誰も私を助けることができますか？プログラマーがこのようなBIGと巨大なコミットを指すために通常使用する用語は何ですか？ ところで、たくさんの変更をまとめてコミットするのは良い習慣ですか？ 更新：感動的な議論をありがとう！しかし、「コードボム」は私が探している用語だと思います。

37 programming-practices  version-control  terminology 

このプロジェクトでは、ユーザー固有の構成ファイルを使用します。このファイルは、ユーザーごとに異なるため、現在バージョン管理されていません。問題は、開発者が構成を必要とする新しいモジュールを追加するか、既存のモジュールの名前を変更すると、プライベート構成ファイルが更新されないため、他の開発者にエラーが発生することです。 この問題を解決するために、2つの構成ファイルで作業することを考えました。バージョン管理になり、新しいモジュールを追加する各開発者によって定期的に更新されるデフォルト/グローバル構成ファイルと、除外されるプライベート構成ファイルバージョン管理され、ユーザー固有の変更のみが含まれます。 ただし、これは依然としてアドホックなソリューションのようです。 より良い解決策を提案できますか？ 専門家は何をしますか？

36 version-control  configuration-management 

私は自分の仕事で唯一の開発者であり、VCSの利点を理解しています。良い習慣に固執するのは難しいと思います。現時点では、主にWebアプリを開発するためにgitを使用しています（私の仕事のためにオープンソース化されることはありません）。 私の現在のワークフローは、開発サイトに多くの変更を加え、テストし、修正し、テストし、満足して変更をコミットしてから、コミットをライブサイトにプッシュします（したがって、大きな新しい変更に取り組んでいる場合、週に1回コミットしますが、私のIDEにはコミットされていないものの良い取り消し履歴があります）。 基本的に、マシンを切り替えるときにだけgitを使用します（たとえば、devコンピューターを自宅のdevコンピューターに移動するか、ライブコンピューターに移動します）が、日中は実際には利点がありません。これにより、変更の長いランドリーリストが作成されます（また、コミットごとに適切なメッセージを見つけるのに苦労しています。急いでいるときはいつでも、「管理者とテンプレートのその他の変更」などのくだらないメッセージを残す傾向があります）。 どのくらいの頻度でコミットする必要がありますか？1行の変更ごとにコミットを取得する必要がありますか？テストの前にコミットする必要があります（たとえば、少なくとも構文/コンパイルエラーのためにコミットしてから、完全に元に戻す必要があります。アイデアが機能しなかった、またはメッセージが嘘であるため）。 まだ新鮮なうちに夕食の仕事をやめる前に、毎朝/午後に必ずコミットする必要がありますか？悪いVCS習慣を持つことで私が見逃しているものは何ですか？

36 version-control  solo-development 

チームでは、ソース管理としてGitを使用しています。ほとんど独立しているが重複するコード領域がいくつかあります。最近、ソース管理を使用するためのワークフローとアプローチについて議論してきました。機能ブランチワークフローの使用を促進するときに出てくる不満の1つは、人々がしばしば複雑なマージ競合に遭遇し、それが誤って解決されることです。複雑なことで、私は「解決方法については明らかではない」という意味です。これを踏まえて、「プルリベース」ベースのワークフローなど、他のワークフローがより積極的に使用されています。 機能分岐アプローチの支持者として、私は実際に苦情を受け取っていません。はい、ローカルの機能ブランチをマスターまたはどこからでも最新の状態に維持する必要がありますが、それが唯一の本当の問題です。マージが常に複雑で、二次的な影響がある場合、それはGitの問題ではなく、チームワークの問題であると考えています。 これを考えるのは正しいですか？複雑なマージの競合は、良いものか悪いものかの兆候ですか？

35 version-control  git  teamwork 

私たちは、プロジェクトのドキュメント作成プロセスをGoogleドキュメントから自己ホスト型のGitリポジトリのセットに移行しようとしています。 テキストドキュメントはGitに十分対応しています。通常、高度な書式設定は必要ないので、複雑な場合にLaTeXを埋め込むオプションを使用して、すべてをたとえばマルチマークダウンに変換します。 しかし、スプレッドシートはまったく別の話です...バージョン管理システムにやさしい（そして、できれば、Markdownと同じくらい人間が読める）spreadsheed（-like）形式はありますか？ 「フレンドリーなフォーマット」：Gitはフォーマットでうまく機能し（XML では機能しません）、人間が読めるdiffを生成します（外部ツールを含む追加の設定はOKです）。 明らかに、Markdownフレーバーを使用すると静的テーブルを作成できますが、次のようなものを使用できるようにしたいと思いSUM()ます...（CSVにも同じ問題があることに注意してください。）いいね 更新：Linux向けの回答のみ、お願いします。MS Officeのものはありません。

35 version-control  documentation  tools  linux 

私は、私のビジネスのソース管理を管理するために、sourceforge、bitbucket、またはgithubの使用を検討しています。私はプロジェクトを開いており、gccなどのプロジェクトに参加しています。しかし、私は自分の生活のためにクローズドソースのソフトウェアを開発するビジネスも持っています。 for索好きな目からソフトウェアを安全に保つという点で、sourceforge、github、またはbitbucketはどれほど信頼できますか？データ損失防止に関して、ホスティングはどの程度安定していますか？そこに誰もがそのような服装でビジネスロジックに基づいていますか？ホスティングソリューションのいくつかを調査した人はいますか？

32 version-control  github  project-hosting  code-security  bitbucket 

プログラマーチームが80年代から90年代前半にソフトウェア開発をどのように管理していたかを知りたいです。すべてのソースコードは、全員が作業した1台のマシンに単純に保存されていたのか、ソースがフロッピーを介して手動でコピーされ、手動でマージされたのか、またはネットワーク（CVSなど）で実際にリビジョン管理システムを使用したのか今？または、おそらくオフラインCVSのようなものが使用されていましたか？ 今日では誰もがソース管理に依存しています。それは簡単です。しかし、80年代には、コンピューターネットワークのセットアップはそれほど簡単ではなく、ベストプラクティスのようなものがまだ発見されていました... 70年代と60年代のプログラミングはかなり異なっていたので、リビジョン管理は不要でした。しかし、80年代と90年代に人々がコードを書くためにコンピューターを使用し始め、アプリケーションのサイズと範囲が拡大し始めたので、当時は人々がどのように管理していたのでしょうか。 また、これはプラットフォーム間でどのように異なりますか？AppleとCommodore 64とAmigaとMS-DOSとWindowsとAtariの比較 注：私は主に、大きなUNIXマシンではなく、その日のマイクロコンピューターでのプログラミングについて話しています。

31 version-control  history