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

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

5
ブランチをソロ開発者として使用する利点は何ですか？
最初に、ソロ開発者としてのVCSについて多くの質問が寄せられていることを知っていますが、それらはあまりにも広範であることが多いです。これは分岐のみに関係しますが、依然として重複としてマークされています...想定される重複は、あまりにも広範で、特に分岐に関係しない別の質問の別の重複としてマークされています。それが私の質問のユニークな方法です。 ブランチを単独の開発者として使用する利点がある場合、それは何ですか？ソロ開発のコンテキストでも推奨されることがよくありますが、見る限りでは、開発に「マスター」トランクを使用し、作業用のリリース準備コードに分岐する以外に、どのように見えるのかわかりません開発プロセス全体を過度に複雑にすることなく、分岐の力を活用できます（たとえば、新しい機能を区分化するために）。
17
コミットがリグレッションを引き起こしたことを誰かに伝える必要がありますか？
退行を追跡して修正すると（つまり、以前は動作していたコードの動作を停止させていたバグ）、バージョン管理により、それを破った変更をコミットしたユーザーを完全に検索できます。 これをする価値はありますか？これをコミットした人に指摘することは建設的ですか？ミスの性質（変更したコードの基本的な誤解に対する単純な不注意の規模）は、それが良いアイデアであるかどうかを変えますか？ 彼らに伝えるのが良い考えであるなら、攻撃を引き起こしたり、彼らを守らせたりせずにそれをする良い方法は何ですか？ 議論のために、バグはCIサーバーの自動テストで検出できないほど微妙であると仮定します。
10
コミット間の待機時間が長すぎる場合はどうすればよいですか？
私はいたずらだった...あまりにも多くの「カウボーイコーディング」、十分なコミット。さて、ここで私は多大なコミットをしています。はい、ずっとコミットしていたはずですが、今は遅すぎます。 何が良いですか？ 私が変更したすべてのものをリストする1つの非常に大きなコミットを行う ファイルには複数の修正、変更、追加のメソッド名などがあるため、コンパイルできない可能性のある小さなコミットに分割してみてください 適切なコミットのためだけにファイルの部分的な復元を行ってから、新しい変更を元に戻します。 注：現時点では、このプロジェクトに取り組んでいる唯一のプログラマーです。少なくともより多くのプログラマを雇うまで、これらのコミットコメントのいずれかを見るのは私だけです。 ところで：私はSVNとSubclipseを使用しています。これらの変更を行う前に、新しいブランチを作成しました。 詳細：そもそもどうやってこの状況に陥ったのかということに関して、別の質問をしました。アプリケーションの接着剤を書き換える準備をする方法
12
コミット履歴を使用して、開発者に重要な情報を伝える必要がありますか？
最新バージョンからのサードパーティSDKのロールバックに関する会議で、開発者がコミット履歴で最新バージョンを使用すべきではないというフラグをすでに立てていることが確認されました。 一部の開発者は、これは悪い習慣であり、代わりにソースファイル（つまり// Don't upgrade SDK Version x.y.z, see ticket 1234）またはプロジェクトレベルのREADMEファイルのいずれかに記載する必要があると主張しました。他の人は、コミット履歴はプロジェクトのドキュメントの一部であるため、私たち全員がとにかくそれを読んでいるはずなので、そのような情報の許容できる場所であると主張しました。 重要な情報を他の開発者に伝えるためにコミット履歴を使用する必要がありますか、またはそのような情報をプロジェクトREADMEや関連するソースファイルのコメントなどの別の場所に複製する必要がありますか？
11
個人（1人）プロジェクトのgit。やりすぎ？
私は、Subversionとgitの2つのバージョン管理システムを知っています。現在のところ、Subversionは私が唯一の開発者である個人プロジェクトに使用され、gitはオープンソースプロジェクトや、他の人もプロジェクトで作業すると信じているプロジェクトに使用されます。これは主に、gitの驚くべき分岐機能とマージ機能が原因です。誰もが自分のブランチで作業できます。とても便利な。 今、私は個人プロジェクトにSubversionを使用しています。gitはほとんど意味がないと思うからです。それは少しやり過ぎのようです。私が唯一の開発者であるときに（通常はホームサーバー上で）集中化されていれば問題ありません。とにかく定期的にバックアップを取ります。私は自分のブランチを作る能力を必要としません。メインブランチは私のブランチです。はい、SVNは分岐を簡単にサポートしますが、それより強力なサポートは意味がありません。マージはそれで苦痛になるか、少なくとも私の小さな経験からです。 個人的なプロジェクトでgitを使用する正当な理由はありますか、それとも単に過剰に過ぎますか？
6
なぜgitはリビジョン番号ではなくハッシュを使用するのですか？
なぜgitはリビジョン番号よりもハッシュを好むのかといつも思っていました。リビジョン番号ははるかに明確で簡単に参照できます（私の意見では）：リビジョン1200を見てもらうか、92ba93eをコミットするように誰かに言うことには違いがあります！（1つの例を挙げます）。 それでは、この設計には理由がありますか？
22
ソースコードのコミットにコメントを追加するように、仲間の開発者にWANTを説得するにはどうすればよいですか？
Subversion（私たちが仕事で使用しているもの）は、コミットに関するコメントを要求するように設定できることを知っていますが、これを単純にオンにする力はありません。私はことを知っている私の唯一のメモリジョガーとして、急速にコミットの背後にある理由を理解するならば、それは、便利ですので、私のコミットをコメントした理由があります。ただし、これは私が常に受け取る2つの応答に対抗するには十分ではないようです。 時間がかかりすぎて、変更をレポに入れたいだけです。 差分を見るだけで十分です。 単にJIRA課題IDを入力することの価値と、それがどのように自動的に課題に結び付けられるかを示していますが、まだサイコロはありません。 最悪なのは、電話をかけることができる人が同じキャンプにいることです。気にする必要はなく、差分を見ることに問題ありません。 私はそれが正しいことだと知っていますが、どうすれば彼らに光を見せることができますか？仲間の開発者を納得させることができなくても、ビジネスのためにそれが正しいことだと経営者に納得させるにはどうすればよいですか？
12
バージョン管理を使用しているときに、すべてのコードファイルに「変更ログ」を含めることは重要ですか？
バージョン管理システムにより、コードのいたるところに「変更ログ」を貼る必要がなくなるという印象を受けました。私は頻繁に変更ログの継続的な使用を見てきました。これには、ファイルへの変更のためにブロックされた大きなセクションを含むストアドプロシージャの開始時の大きな長いブロックが含まれます。 // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 そして： // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> 私に説明されたように、この理由は、VCSログをふるいにかけるのに時間がかかりすぎて、誰が何をなぜ変更したかを見つけようとしている間、コードファイル自体に関連する上部または近くにそれを持っているからです誰が何をいつ変更したかを簡単に確認できます。私はその点を見ていますが、冗長であり、「VCSを適切に使用する方法が本当にわからないので、そのようなことは一切気にしません。 どう思いますか？コメントとログの両方を使用していますか？ただのログ？John Smithが1週間前にXYZをチェックするようにメソッドを変更したコードブロックの上に表示されると、Diffツールでログを検索してコードファイルを比較する代わりに、コーディングが簡単になりますか？ 編集：SVNを使用しますが、基本的にはリポジトリとしてのみ。ブランチ、マージ、ログ+ストレージ以外はありません。
28
優秀なプログラマーがバージョン管理を使用したことがないということはありえますか？[閉まっている]
私は、困難な状況を解決するのに役立つ専門のプログラマを探しています。 これまでのインタビューは驚くほど残念でした。これまでの最良の候補者は、バージョン管理ソフトウェアを使用したことがない経験豊富なプログラマーです。 問題自体はそれほど深刻ではないかもしれません。なぜなら、それは短時間で学習できるものだからです。 しかし、より深い側面があり、私を心配しています： バージョン管理を必要とせずに10〜15年間、積極的にソフトウェアを開発する方法を教えてください。 追跡の問題の解決策を探していないという事実自体が、プログラミングに対する間違った態度の兆候を変えていますか？
10
悪いコードを書くことを余儀なくされています。どうすれば顔を保存できますか？[閉まっている]
私は若い開発者ですが、私の仕事は本当にひどいPHPコードで作業することを余儀なくされます（あなたが見た最悪のPHPコードについて考えてください;そしてコードを2倍悪いと考えてください）。私は通常、バグを修正し、新しい機能を追加するためにコードベースと戦います。時々、私は物事をできるだけ早く動作させるように命じられます。 この製品は以前はオープンソースでしたが、将来オープンソースになる可能性があると心配しています。誰か（特に潜在的な雇用者）が私のチェンジセットの次に私の名前を見つけることができたら、私は恥ずかしいでしょう。良い名前を守るために何ができますか？ これが関連するかどうかはわかりませんが、上司も同僚もコードが悪いことを認めたくないと付け加えますが、そのために彼らを責めることはできません-彼らの多くはこれが彼らです最初の仕事。
8
発見してパッチを適用したバグを記録する必要がありますか？
これは一般的な状況だと思います：いくつかのコードをテストし、バグを発見し、それを修正し、バグ修正をリポジトリにコミットします。多くの人がこのプロジェクトに取り組んでいると仮定して、まずバグレポートを作成し、自分に割り当てて、コミットメッセージで参照する必要があります（たとえば、「バグ#XYZを修正します。バグはXおよびYによるものです。 Q and R "）？または、バグレポートをスキップして、「BのときにAを引き起こしたバグを修正しました。バグはXおよびYによるものでした。QおよびRで修正しました」などのメッセージでコミットできます。 より良いプラクティスと考えられるものは何ですか？
9
ドキュメントとプロジェクト管理にGitを使用する必要がありますか？コードは別のリポジトリに配置する必要がありますか？
グループプロジェクトのGitリポジトリを起動しています。コードと同じGitリポジトリにドキュメントを保存するのは理にかなっています -これはgitリビジョンフローの性質と矛盾するようです。 ここに私の質問の要約があります： コードとドキュメントの両方が同じリポジトリにチェックインされている場合、Gitリビジョンスタイルは混乱するでしょうか？これでの経験？ Gitはドキュメントのリビジョン管理に適していますか？ 私はありません一般的にはリビジョン管理システムは、またはマニュアルのために使用すべきではないかどうかを尋ねる-それがなければなりません。 これまでのフィードバックに感謝します！
7
多くのプロジェクトが「git merge」よりも「git rebase」を好むのはなぜですか？
DVCSを使用する利点の1つは、edit-commit-mergeワークフローです（多くの場合、CVCSによって施行されるedit-merge-commitを超える）。マージに関係なく、固有の各変更をリポジトリに記録できるようにすることで、DAGがプロジェクトの真の血統を正確に反映するようになります。 なぜこれほど多くのWebサイトが「マージコミットを回避する」ことについて話しているのですか？事前コミットまたはマージ後のリベースをマージすると、リグレッションの分離、過去の変更の取り消しなどが難しくなりませんか？ 明確化のポイント： DVCSのデフォルトの動作があるコミットをマージ作成します。なぜそんなに多くの場所が、これらのマージコミットを隠す線形の開発履歴を見たいという願望について語っているのでしょうか？
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.