タグ付けされた質問 「scm」

私は政府機関で働いています。ここで使用されている技術とソフトウェアの開発方法は非常に古いものです。 大量のストレージスペースがありますが、ここでの作業のほとんどを自動化するために使用されるアプリケーションを保持および維持するための適切なスペースはありません。 この機関では、GITやSVNなどのSCMソフトウェアを使用できません。 コードの品質を維持し、後でアプリに新しい機能を追加できるようにするための最良のアプローチは何でしょうか？ コードを壊さずに行った変更を記憶するにはどうすればよいですか？ 編集：私は言及するのを忘れました、彼らはそれぞれのコンピュータのためのネットワークドライブを持っています、そしてどういうわけかこれらのネットワークドライブは定期的にバックアップを作成または保存します。ただし、作業を保存し、既存のコードを壊さずに新しい機能を追加できるようにする独自の計画を作成しない場合、SCMソリューションに勝る大きな利点はありません。 編集：多くの人々がポータブルGitを提案したので、私はより多くの情報を追加する必要があります。Visual SVNサーバーをインストールしようとしましたが、インストールする管理者権限がないため失敗しました。また、通常のGitシェルをダウンロードしようとしましたが、ファイアウォールまたはネットワーク設定により、Gitダウンロードページにアクセスできませんでした。ポータブルGitをGmailであるメールに送信してみました。Googleはパッケージ内のexeファイルを検出しましたが、それでも仕事用コンピューターにポータブルGitバージョンをダウンロードできませんでした。もう1つ言及しなければならないのは、教育機関のコンピューターに適用されるネットワークポリシーでは、USBストレージデバイスの使用が許可されていないことです。USBポートを使用して、スマートフォンを充電したり、小型スピーカーなどの一部の機器に電力を供給したりできます。また、一部の人々が言及したように、インターネットさえ許可されていないコンピューターがあります。

110 git  code-quality  svn  scm 

私はいたずらだった...あまりにも多くの「カウボーイコーディング」、十分なコミット。さて、ここで私は多大なコミットをしています。はい、ずっとコミットしていたはずですが、今は遅すぎます。 何が良いですか？ 私が変更したすべてのものをリストする1つの非常に大きなコミットを行う ファイルには複数の修正、変更、追加のメソッド名などがあるため、コンパイルできない可能性のある小さなコミットに分割してみてください 適切なコミットのためだけにファイルの部分的な復元を行ってから、新しい変更を元に戻します。 注：現時点では、このプロジェクトに取り組んでいる唯一のプログラマーです。少なくともより多くのプログラマを雇うまで、これらのコミットコメントのいずれかを見るのは私だけです。 ところで：私はSVNとSubclipseを使用しています。これらの変更を行う前に、新しいブランチを作成しました。 詳細：そもそもどうやってこの状況に陥ったのかということに関して、別の質問をしました。アプリケーションの接着剤を書き換える準備をする方法

100 version-control  development-process  scm  cowboy-coding 

最近まで、私の開発ワークフローは次のとおりでした。 製品所有者から機能を入手する ブランチを作成します（機能が1日以上の場合） ブランチに実装する メインブランチからブランチへの変更をマージします（後方マージ中の競合を減らすため） ブランチをメインブランチにマージする マージに問題があることもありましたが、一般的には気に入っています。 しかし、最近、継続的な統合や継続的な配信などを実践するのが難しくなるため、ブランチを作成しないというアイデアの信者が増えています。 Git、Mercurialなど 質問は、最近のブランチを使用する必要がありますか？

84 continuous-integration  branching  scm 

最近、分岐とマージとSCMについてのMSDNの記事に出くわしました：分岐とマージプライマー-Chris Birmele。 記事では、「ビッグバンマージ」はマージアンチパターンであると述べています。 Big Bang Merge —開発作業の最後までブランチのマージを延期し、すべてのブランチを同時にマージしようとします。 これは、私の会社が生産されているすべての開発ブランチで行っていることに非常に似ていることに気付きました。 私は非常に小さな会社で働いており、1人が最終審査とトランクマージの権限を持っています。5人の開発者（私を含む）がいて、それぞれに個別のタスク/バグ/プロジェクトが割り当てられ、それぞれ現在のトランク（subversion）から分岐し、分岐で開発作業を実行し、結果をテストし、ドキュメントを作成します。必要に応じて、他の開発者とピアレビューとフィードバックループを実行し、プロジェクト管理ソフトウェアでレビュー+マージのためにブランチを送信します。 トランクリポジトリの唯一の権限である私のボスは、ブランチのレビューのすべてを実際に可能な限りレビューを行う単一の時点まで延期し、一部のブランチは拡張/修正のためにスローバックされます。ブランチはすぐにトランクにマージされ、一部のブランチは競合などのためにスローバックされます。 10〜20のアクティブなブランチを最終レビューキューに入れてトランクにマージすることは珍しくありません。 また、2つのブランチが同じトランクから作成されたものの、同じコードを変更したため、最終レビューとマージの段階で競合を頻繁に解決する必要があります。通常、これを回避するには、トランクから分岐し直して変更を再適用し、競合を解決してから、レビューのために新しいブランチを送信します（poor mans rebase）。 私が持っているいくつかの直接的な質問は次のとおりです。 「ビッグバンマージ」と呼ばれる非常にアンチパターンを示していますか？ このマージプロセスの結果に見られる問題の一部はありますか？ 上司のボトルネックを増やすことなく、このマージプロセスを改善するにはどうすればよいですか？ 編集：私の上司がトランクリポジトリに対する彼のグリップを緩めるか、他の開発者がトランクにマージできるようにすることを疑います。彼の理由は定かではありませんが、私はこのトピックを取り上げるつもりはありません。なぜなら、それは以前に取り上げられており、かなり早く撃downされたからです。彼らは私たちを信じていないだけだと思いますが、とにかくすべてが追跡されているので意味がありません。 この状況に関する他の洞察は歓迎されます。

28 svn  anti-patterns  merging  scm 

私は多くのバージョン管理システムを知っています：CVS、SVN、TFSなど... 私は最初の「リビジョン管理/バージョン管理システム」をグーグルで調べましたが、さまざまな矛盾する答えがありました。 ソース管理が発明されたのはいつですか？誰が発明したのですか？それは何と呼ばれていましたか？

20 version-control  history  scm 

開発運用とソフトウェア構成管理の違いは何ですか？ 私にとっては、DevOpsとSoftware Configuration Managementの両方に焦点が当てられている限り、同じように思えます。 開発インフラストラクチャの確立-バージョン管理、ビルド管理、展開管理、依存関係管理、継続的な統合と配信などを担当します。 開発者環境を整理するためのベストプラクティスを使用する。 開発プロセスの品質保証 -開発の有効性のメトリックを収集し、開発プロセスのボトルネックの除去に取り組んでいます（単体テストの実行、単体テストのカバレッジの評価、検査の実行など） インフラストラクチャ管理 -ターゲットプラットフォームとその詳細。 リリース管理 -リリースが時間内に顧客/クライアントに配信されたことを確認します。 たぶん私は何かが欠けていますか？このリンクは、「ソフトウェア構成管理」という用語の使用が優先されることを示しています。しかし、それでも、リストされた範囲の活動を説明するために、どのような組み合わせの言葉を使用しますか：開発操作またはソフトウェア構成管理？

15 terminology  organization  scm 

私たちはプロジェクトを行っていますが、プロジェクト間で多くのコードを再利用し、共通のコードを含むライブラリをたくさん持っています。新しいプロジェクトを実装するにつれて、一般的なコードを抽出してライブラリに追加する方法が増えています。ライブラリは互いに依存し、プロジェクトはライブラリに依存します。各プロジェクト、およびそのプロジェクトで使用されるすべてのライブラリは、参照しているすべてのライブラリの同じバージョンを使用する必要があります。ソフトウェアをリリースする場合、バグを修正する必要があり、長年、場合によっては数十年にわたって新しい機能を追加する必要があるかもしれません。約12のライブラリがあり、変更は多くの場合2つ以上にまたがり、複数のチームが複数のプロジェクトを並行して作業し、これらすべてのライブラリに同時に変更を加えます。 最近、gitに切り替えて、各ライブラリおよび各プロジェクトのリポジトリを設定しました。stashを共通のリポジトリとして使用し、機能ブランチで新しい作業を行い、プルリクエストを作成し、レビュー後にのみそれらをマージします。 プロジェクトで対処しなければならない問題の多くは、いくつかのライブラリとプロジェクト固有のコードを変更する必要があります。多くの場合、ライブラリインターフェイスの変更が含まれますが、その一部には互換性がありません。（これが怪しいと思うなら、私たちはハードウェアとインターフェイスし、特定のハードウェアを汎用インターフェイスの後ろに隠します。他のベンダーのハードウェアを統合するたびに、現在のインターフェイスが予期しなかったケースに遭遇するため、それらを改良する必要があります。）たとえば、プロジェクトを想像しP1たライブラリを使用してL1、L2とL3。L1また、使用していますL2とL3、とL2用途L3にも。依存関係グラフは次のようになります。 <-------L1<--+ P1 <----+ ^ | <-+ | | | | +--L2 | | ^ | | | | +-----L3---+ ここで、このプロジェクトの機能に変更が必要でP1ありL3、のインターフェースを変更することを想像してくださいL3。これらのライブラリを参照するプロジェクトP2をP3ミックスに追加します。それらをすべて新しいインターフェイスに切り替え、すべてのテストを実行し、新しいソフトウェアを展開する余裕はありません。それでは、代替手段は何ですか？ 新しいインターフェースを実装する L3 プルリクエストをL3してレビューを待ちます 変更をマージする の新しいリリースを作成する L3 の新しいリリースをP1参照することで機能の作業を開始し、機能のブランチにL3機能を実装しますP1 プルリクエストを行い、これをレビューして、マージします （私はちょうど私がスイッチに忘れたことに気づいたL1とL2新しいリリースに。そしてそれはと並行して行われる必要があるので、私も、どこでこれを固執するかわかりませんP1...） これは、この機能を実装するための退屈でエラーが発生しやすい非常に長いプロセスであり、独立したレビューが必要であり（レビューがはるかに困難になります）、スケーリングがまったく行われず、私たちがビジネスを停止する可能性がありますプロセスが行き詰まってしまい、何もできなくなります。 しかし、あまり多くのオーバーヘッドなしで新しいプロジェクトに新しい機能を実装できるプロセスを作成するために、どのように分岐とタグ付けを使用するのでしょうか？

11 git  branching  dependencies  scm  tagging