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

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

1
誰かのプルリクエストを編集するためのエチケット
私はGitHubにリポジトリを所有しており、誰かが1回のコミットでプルリクエストを送信しました。私は彼のソリューションを部分的に実装したいだけで、ユーザーが行ったコード変更の約半分を使用します。この状況ではどうすればよいですか？ 彼のバージョンのブランチを作成し、元のバージョンから2番目のコミットに保存する「古い」コードをコピーして貼り付けます。これにより、コミット間の差分が実際より大きくなり、のようなものがスローされgit blameます。 彼のコミットから保持したいコードをコピーして、新しい別のコミットに貼り付けます。これは、彼がコードへの貴重な貢献に対してクレジットを受け取らないことを意味します。 上記と同じように、彼のコードの一部を新しいコミットにコピーしますが、コミットの作成者を私ではなく彼に変更します。彼は技術的にはコミットされた正確なコードを書いていないので、これが眉をひそめているかどうかはわかりません。しかし、少なくとも彼は使用されている行の属性を取得します。
7
バージョン管理の使用方法
この質問は、Software Engineering Stack Exchangeで回答できるため、Stack Overflowから移行されました。 8年前に移行され ました。 私はlocalhostのphpでWebサイトを開発しています。そのモジュールが完成したら、それをクラウドにアップロードして、友人がアルファテストを行えるようにします。 開発を続けると、多くのファイルがあり、どのファイルを編集または変更したかなどを把握できなくなります。これらすべてを管理する「バージョン管理」として何かを聞いたことがありますが、どのように機能するかはわかりません。 だから、私の質問は次のとおりです。すべての編集/変更/新しいファイルを追跡し、Webサイトの開発中にファイルを管理する簡単な方法/サービス/アプリケーションはありますか。モジュールを使い終えたらすぐに、クラウドにアップロードしたいと思います（Amazon Cloud Serviceを使用しています）。新しいファイルに何かが起こった場合、古いファイルに戻りたいと思うかもしれません。たぶん、1、2回クリックするだけで、最後にアップロードしてから編集または変更したファイルが表示されますか？
4
ソロ開発者にDVCSを使用する利点はありますか？
今、私は自分のサーバー上で視覚的なsvnを使用し、私のマシン上でankhsvn / tortoiseを使用しています。それは十分に機能し、変更する必要はありませんが、DVCSを使用することの利点を確認できる場合は、試してみてください。 ただし、他の人なしでそれを使用しても意味や違いがない場合は、気にしません。 繰り返しになりますが、あなたが唯一の開発者であるときにDVCSを使用する利点はありますか？
8
バージョン管理のコードはどのように保存する必要がありますか？
バージョン管理のコードはどのように保存する必要がありますか？ 開発者に優しい？プログラマーは、多くの変更を行うことなく、エディターから最新のものをすぐに実行できるようになりますか？（dev DB..etcを指す構成ファイルなど） または それは生産に適しているべきですか？ソースは本番環境に簡単に展開できる方法である必要があり、開発者が最新版を取得する場合、開発ニーズに従って変更を実行する必要があります。
11
コードベースの別の部分で作業中にバグを修正する
これは少なくとも一度は私に起こりました。私はコードベースのある部分に取り組んでおり、別の部分に小さなバグを見つけました。そのバグは、私が現在やろうとしていることを完了するのを妨げます。バグの修正は、単一のステートメントを変更するのと同じくらい簡単です。 その状況で何をしますか？ バグを修正し、現在の作業と一緒にコミットします 現在の作業を別の場所に保存し、別のコミットでバグを修正してから作業を続行してください[1] あなたがすることになっていることを続けて、コードをコミットします（たとえそれが ビルドを壊します いくつかのテストに失敗します）、バグを修正します（そして ビルド 別のコミットでテストに合格する） [1]実際には、これは、元のリポジトリを他の場所に複製し、バグを修正し、変更をコミット/プッシュし、作業中のリポジトリにコミットをプルし、変更をマージし、作業を続行することを意味します。 編集：私は本当に意味を反映するために3番を変更しました。
2
MavenのGitリポジトリを構成する最良の方法
Gitでプロジェクトを構成する方法について、いくつかのアドバイスが必要です。Javaを使用し、Mavenはビルドツールです。Mavenは、最終的にすべてのプロジェクトに共通の祖先があると想定しています。Mavenは、Apache Foundationがプロジェクトをセットアップする方法が正確にセットアップされていない場合、本当のドラマクイーンになることもあります（リリースプラグインを使用している人は、おそらく私が話していることを知っています）。 プラグインのバージョンとビルド構成（リポジトリ構成、ビルドするアーティファクト、命名規則、プラグインバージョンなど）を制御する最上位の親pomが必要です。Mavenは、すべてのITプロジェクトをそのメインプロジェクトのサブフォルダーに入れたいと考えています。これは、組織の1つの大規模なGitリポジトリを意味します。 これは非常に騒がしい環境になります。関連のないプロジェクトに取り組んでいる2つのチームがある場合、それらは常に他のチームからマージをプルする必要があります。理想的には、プロジェクトごとに1つのリポジトリが必要です。 しかし、そのような種類は、サブプロジェクトがサブフォルダーであることを要求する Mavenの非常に階層的なモデルと衝突します。 人々がこれら2つのモデルをどのように調整したかについて、いくつかのアドバイスが必要です。
3
バージョン管理のコミットを読み取るマネージャー
マネージャーは、すべてのプロジェクトでGitのコミットを監視しています。通常、これは問題ではありません。バージョン管理は、特に後の監査と分析（問題が発生した場合）のために、発生しているすべての作業のログを提供するという事実が大好きです。 ただし、マネージャーは、タスク管理システムで「スタイル修正」またはチケット番号を参照しないコミットメッセージを読み取るコミットを見たときに、人々が何に取り組んでいるかを尋ねるいくつかのコメントを作成しました。 これに社会的または技術的な解決策はありますか？ 詳細情報：これはメンテナンスプロジェクトであるため、「Aを実行し、次にB、次にC、次にDを実行し、最後にXを実装しなければならない」タスクが多数発生します。 詳細：マネージャーにフラグを立てた特定のコミットメッセージは、「X、Y、Zへのより良い方法を含む」に近く、単純なスタイル修正ではなく、リファクタリングメッセージです。
6
他の人がコードベースにすばやくコミットしている間に、どのようにコードベースをリファクタリングできますか？
私は最終的にはオープンソースになるプライベートプロジェクトに参加しています。私たちには、アプリを構築するための技術に十分な才能がある少数のチームメンバーがいますが、クリーンで美しい、最も重要な長期保守可能なコードを書くことができる専任の開発者はいません。 コードベースのリファクタリングを開始しましたが、定期的に連絡を取り合っていない別の国にいるチームの誰かがこのまったく別のものを更新する可能性があるため、少し扱いに​​くいです。 解決策の1つは、迅速に通信するか、より良いPMプラクティスを採用することですが、まだそれほど大きくはありません。コードをクリーンアップして、彼が更新したものにうまくマージしたいだけです。ブランチを使用することは適切な計画でしょうか？ベストエフォートマージですか？他に何か？
17
コミットメッセージを書く必要があるのはなぜですか？
コミットメッセージを書く必要があるのはなぜですか？私はしたくないし、私は毎回その愚かだと思う。 名前のないGUIフロントエンドを使用すると、強制的に実行されます。コマンドラインでVCSを使用している場合でも、他の人が毎回それをしていると聞きます。 1日に数回コミットし、機能を終了していない場合、何を書いていますか？私は何度もコミットした後にメッセージを書くだけで、ミニタグの時か、実際のタグを行う時だと感じています。 私は正しいですか、何かが欠けていますか？また、私は分散システムを使用しています
5
単独プロジェクトで継続的統合ツールが提供する利点は何ですか？
ソロプロジェクトを行う場合-CIツールを使用してリポジトリからビルドしますか？私はチーム環境でハドソンとクルーズコントロールを使用しました。誰かがチェックインしたらすぐにビルドすることが不可欠です。 バージョン管理の価値はまだ明らかだと思いますが、ローカルマシンでビルドしたばかりで、誰もコミットしていないように、コミットするたびにビルドする必要がありますか？
5
リリースフィーバー中に効率的なコードレビューを行う方法
リリースの締め切りは明日です。同僚はこのリリースに不可欠なタスクをやっと完了しました。プロジェクトマネージャーは肩越しに立ち向かい、最終的にビルドを作成するように促しました。重大なものではありませんが、明日リリースされなければ、手放せないものです。そして、事態を悪化させるには、できるだけ早く終了するために必要な自分の仕事があります。それで、あなたは何をしますか？プレッシャーにも関わらず異議を申し立てますか、それともこれを滑らせますか？ 私が見つけた1つの方法は、このコミットを別のブランチに一時的にマージし、後で確認できるようにすることです。問題が表面的なものであり、コードレビューを待っている唯一の問題である場合に機能します。しかし、これを処理するより効率的な方法はありますか？たとえば、コードレビューとテストのみを1人で行うことをお勧めしますか？
3
小さなチームにバージョン管理分岐ポリシーを導入する
私は最近会社で始めた請負業者です。 チームは3人の開発者であり、2人の下級から中級レベルの開発者で構成されており、同じレベルの別の開発者が間もなく開始され、私（6年xp）です。両方の既存の開発者にとって、それは大学/大学からの最初の仕事であり、彼らは以前に自分の仕事を監督する上級開発者を持ったことがありません。 明示的なバージョン管理ポリシーはありません。開発者はすべての開発をトランクで行い、開発マシンから直接本番環境に展開します。既存のチームは分岐に精通していません。 これをすべて変更し、CI、TDDテスト/ステージング/プロダクションサーバーなどを導入し、これを補完するバージョン管理ポリシーを導入します。 ソース管理システムはTFSであり、これまで使用したことはありません。1つの巨大なリポジトリとして構成されています。 私はそれらのいくつかの指針を書き留めましたが、チームの経験を念頭に置いて、追加/修正する必要がある他のものはありますか？ バージョン管理ポリシー 開発はトランクで行われます 変更に1週間以上かかると推定される場合は、ブランチで行う必要があります。トランクからブランチへの定期的なマージを行い、2つの同期がとれないようにします。 本番コード用に作成されたリリースブランチ。そのブランチには、安定したコードのみが含まれている必要があります。スプリントごとに1回、トランクから更新される1つのリリースブランチを作成するか、週ごとに個別のリリースブランチを作成することができます。 本番コードに影響する緊急のバグ修正を行う必要がある場合は、リリースブランチで行われ、トランクにマージされます。 1つのリリースブランチ戦略を採用する場合、トランクはスプリントの終わりに向かってスプリントごとに1回リリースブランチにマージされます。 リリース戦略ごとに個別のブランチを採用する場合、トランクはリリースブランチにマージされません。 一部のシナリオでは、分岐が多すぎる場合、異なる分岐でバグを2回修正する必要があります。短いスプリントをしている場合、これはあまり頻繁に起こるべきではありません。 3台のサーバーを使用する予定です。リポジトリ内の最新のコードを常に実行しているテスト環境。リリース候補コードおよびUATをステージング/テストするための最新のリリース候補を実行しているステージング環境、および運用環境。 私がこれを行うことを計画している理由は、これまでクライアントは内部ソフトウェアのみを実行していたためです。最新のプロジェクトは注目度の高いメディアクライアント向けであり、私は、チームが現在行っているものよりも専門的な開発モデルを採用する必要があると感じています。 たとえば、現時点では、ユーザーはバグレポートを使用してチームに電話をかけることができます。開発者はバグを見つけて修正し、自分のマシンで簡単な目玉テストを実行してから、実稼働環境に直接展開します。自動テストなどはありません。 後知恵では、機能ブランチはあまりにも遠いステップだと思うので、削除します。 したがって、本質的には、a）まったく分岐しない）b）リリースブランチとトランク、およびc）リリースとトランクごとのリリースブランチになります。 私は後者に傾いていました。私の最初の考えは、リリース候補と別々のサーバー（UAT / Production）で同時に稼働するリリースの両方を同時に持つことですが、事実上、トランクはいつでもリリース候補であるため、リリースは非常識に傾いています。私が考えたのは、利害関係者に開発コードを見せたくない場合は、別のリリース候補ブランチが必要になるかもしれないが、YAGNIとその他すべて.....
5
どのバージョン管理システムがすべての側面を管理できますか？[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 数ヶ月前、私はSubversionとGITを掘り下げましたが、がっかりしました。ソースコードは正常に処理されますが、他の側面は処理されません。たとえば、バージョン管理下のWebサイトでは、ファイル/ディレクトリの所有権、ファイル/ディレクトリの読み取り/書き込みアクセス、アクセス制御リスト、タイムスタンプ、データベースコンテンツを管理する必要があります。および外部リンク。1か月前のバックアップからリロードするのと同じくらい完璧な復帰を実行できるバージョン管理システムはありますか？
4
ラダーロジックプログラムのソース管理のための現実的で便利なソリューションはありますか
プログラマブルロジックコントローラー（PLC）のラダーロジック（LL）プログラムのバージョン管理は、実質的に存在しないようです。LLは視覚言語であり、バイナリファイルに保存される傾向があるため、またはソースコード管理がプロセス制御エンジニアリングサークルで「キャッチ」されていないためか、または今夜のGoogle-Fuが弱い可能性があります。 そのようなシステムのバージョン管理のための現実的で便利なソリューションを知っていますか？ 定義： 現実的=プログラムへの変更はユーザーによって追跡され、復帰およびマージの対象となります 有用=システムは視覚的なLLデザイナーと統合され、単一のPLCメーカーのLLに限定されず、とんでもない金額がかかりませんか？ 注：SVNやMercurialなどを使用してバイナリファイルを追跡している人の話を聞いたことがありますが、diff / merge機能で読みやすい違いが表示されるとは思いません。 補遺： 最初は、Allen-Bradley PLCのみをサポートする必要がありました。現在、シーメンスとMicroLogix PLCもあります。実行可能なソリューションを探しています...
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.