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

（簡単にするために）クライアントとサーバーを備えたアプリケーションがあると仮定しましょう。1つのリポジトリを両方または別々のリポジトリのペアに使用することをお勧めしますか？ それらを混合すると、おそらく相関する変更を追跡し、相関するブランチを維持しやすくなります（つまり、プロトコルの進化）。

15 version-control 

同僚と私は、複数の意見を持っている問題に遭遇しました。 現在、すべてのcronジョブを保持しているgitリポジトリがあります。約20のcronがあり、それらはすべて小さなpythonスクリプトであり、いくつかのアクティビティに不可欠であるという事実を除き、実際には関連していません。すべてのスクリプトの要件fabric.pyを展開するrequirements.txtファイルと管理するファイルを使用しています。 私たちの問題は、基本的に、これらのスクリプトをすべて1つのgitリポジトリに保持するのか、それとも独自のリポジトリに分離する必要があるのか​​、ということです。それらを1つのリポジトリに保持することで、1つのサーバーに簡単に展開できます。すべてのスクリプトに1つのcronファイルを使用できます。 ただし、20個のcronジョブは論理的に関連していないため、これは間違っていると感じています。さらに、requirements.txtすべてのスクリプトに1つのファイルを使用する場合、特定のスクリプトの依存関係を把握するのは困難であり、それらはすべて同じバージョンのパッケージを使用する必要があります。 すべてのスクリプトを独自のリポジトリに分離することもできますが、これにより20の異なるリポジトリが作成され、それらを覚えて処理する必要があります。これらのスクリプトのほとんどはそれほど大きくなく、その解決策は行き過ぎているようです。 関連する質問は、すべてのcronジョブに1つの大きなcrontabファイルを使用しますか、それとも個別のファイルを使用しますか？それぞれが独自のものを持っている場合、あるcrontabのインストールは他の19の上書きをどのように回避しますか？これはまた、20種類のcronファイルを追跡する必要があるため、苦痛のように思えます。 要するに、私たちの主な質問と問題は、それらをすべて1つのリポジトリとして密接にバンドルしたままにするのか、それとも独自のrequirements.txtとfabfile.pyを使用して独自のリポジトリに分けるのですか？私たちは、おそらくいくつかの本当に簡単な解決策も検討しているように感じます。この問題に対処する簡単な方法はありますか？

15 python  version-control  git 

私のチームは、バージョン管理としてクリアケースを使用しています。私が取り組んでいるプロジェクトは、7〜8年前には開始されていません。プロジェクトの存続期間中、バグ修正サービスパックなどのリリースがいくつかありました。問題はバグ追跡システムを使用して追跡され、バグ修正に取り組むほとんどの人は、START /日付、作成者、バグIDなどを含むENDブロック これは非常に無関係で、コードが乱雑になり、保守が不安になります。これらは、チェックインコメント/ラベルなどの一部である必要があり、作業製品の追加のライフサイクル情報を保持できます。 従うべきベストプラクティスは何ですか？ コードのレビューアの何人かは、バグと修正についてのコメントを外に出して、彼らの人生を楽にすることを主張します。私の理解では、ファイルをビューにマッピングしてファイルをレビューし、ブランチの変更ログを取得してレビューする必要があります。レビュー用に更新されたコードを送信する際のベストプラクティスを入手できれば助かります。

15 version-control 

過去数年にわたって、私はいくつかの異なるバージョン管理システムを使用してきました。私にとって、それらの間の基本的な違いの1つは、ファイルを個別にバージョン化するか（各ファイルには独自のバージョン番号と履歴がある）、リポジトリ全体（「コミット」またはバージョンがリポジトリ全体のスナップショットを表す）である。 一部の「ファイルごと」バージョン管理システム： CVS ClearCase Visual SourceSafe 一部の「全体リポジトリ」バージョン管理システム： SVN ギット マーキュリアル 私の経験では、ファイルごとのバージョン管理システムは問題を引き起こすだけであり、正しく使用するにはより多くの構成とメンテナンスが必要です（たとえば、ClearCaseの「構成仕様」）。同僚が無関係なファイルを変更し、理想的には孤立した開発ラインを壊すという多くの事例がありました。 これらのファイルごとのバージョン管理システムの利点は何ですか？「全体リポジトリ」バージョン管理システムには、ファイルごとのバージョン管理システムにはない問題がありますか？

15 version-control 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私はローカルでいくつかのプロトタイピングを行っていますが、ソース管理を維持したいのですが（バックアップと復元の目的で）、必ずしもオープンソースとして公開したり、他の人が閲覧できるようにオンラインで公開したりする必要はありません。 ローカル開発にはどのソース管理システムを推奨しますか？私のシナリオのセットアップやウォークスルーは大歓迎です。 を探しています： 簡単なセットアップと管理。これは私のローカルマシンなので、Windows OSに制約されており、環境設定の変更と必要な学習曲線の量を最小限に抑えたいと思っています。ユーザーは1人だけなので、アクセス権などを設定したくありません。 リソースのオーバーヘッドが低いため、開発者のマシンでローカルにホストしたいので、CPUを使い果たしたくありません。大量のデータを保存する予定もありません。 おなじみ。以前にSVNクライアントを使用したことがあります。Visual Studioの統合は便利です。 ポータブル。外部ドライブまたは別のマシンに移動する必要がある場合。 自由。はい、私はそれがすべて欲しいのですが、お金を払う必要はありません。

15 version-control  development-environment 

私は会社のプロジェクトマネージャーです。私は、CVSとして知られる標準のよく知られたバージョン管理システムを使用して、いくつかの開発者チームと協力しています。継続的な統合と自動化されたビルドを実装して、ビルドの破損や運用サーバーへの不正な展開の問題を防ぐことができるようにしたいと思います。 私は自分でこれを設定できると確信していますが、次の2つの理由でこれを自分で行いたくありません。 時間がありません。私には、マーケティング、開発に参加していないチームメンバーとのその他の利害関係者とのコミュニケーション、顧客とのコミュニケーション、プロジェクト計画などの責任があります。 最も重要なことは、私はプロジェクトマネージャーです。私の目的は、開発チームを細かく管理することではなく、リーダーシップを提供することです。 開発チームでこれをセットアップすることに情熱を持っている人を見つけるためにできることは何ですか？Java、Spring、およびGoogle App Engineの知識が必要であることを考慮して、開発者はこのタスクに適していますか？変化が懸念される変化を促進するためのヒントは何ですか？

15 version-control  continuous-integration  change 

私のチームは現在、次のような非常に単純な分岐/展開プロセスを使用しています。 ┌────────┐ ┌────┐ ┌──────┐ Environments: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Builds: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Branches: │ …

14 version-control  git  development-process  deployment  development-environment 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新することがありますので、上のトピックソフトウェア工学スタックExchange用。 6年前に閉鎖されました。 codeigniterを使用して、平均的なPHPアプリケーションで4〜5人のプログラマーと協力する必要があります。私たちは1つの都市の5つの異なる場所にいて、すべてのプログラマーはあまり教育を受けていないので、ほとんどのバージョン管理システムを使用したことはないと思います。 このようなプロジェクトで共同作業するための、非常に簡単に入手できるプラットフォームをお勧めできますか？共有のDropboxフォルダーよりも少しだけ洗練されたものについて話しています。

14 php  version-control  svn  github  collaboration 

ライブアプリケーションを実行している1台のサーバーで、約5人の開発者からなる小さなチームでgitを正しく使用する最も簡単な方法は何でしょうか？

14 version-control  git 

奇妙なタイトル、はい、しかし、私は私が思うにカバーするために少し地面を持っています。 プライベートリポジトリを持つgithubに組織アカウントがあります。githubのネイティブな問題/プルリクエスト機能を使用したいと思います（プルリクエストは、基本的にコードレビューと機能の議論に関する限り正確です）。私たちは、ツール見つかったハブをすることによってディファンクトプル要求に既存の問題を変換し、自動的にそれをあなたの現在のブランチを関連付けることができるというクールなのはほとんどの機能があります。 組織内の各開発者が組織のリポジトリをフォークして、機能の作業/バグ修正などを行うのがベストプラクティスかどうか疑問に思っています。これは非常に堅実なワークフローのように見えます（基本的にはgithubのすべてのオープンソースプロジェクトが行うことです）が、問題を追跡し、組織のリポジトリである1つのソースから要求をプルできることを確認したいと思います。 そこで、いくつか質問があります。 この場合、開発者ごとのフォークのアプローチは適切ですか？それは少しやり過ぎのようです。直接プッシュアクセスを持たず、すべてのコードをレビューする必要がある開発者を紹介しない限り、すべての開発者にフォークが必要かどうかはわかりません。その場合、それらの開発者だけにそのようなポリシーを制定したいと思います。それで、どちらが良いですか？すべての開発者が単一のリポジトリにあるのか、それともみんなの分岐点なのか ハブツール、特にプルリクエスト機能の経験はありますか？開発者ごとにフォークを行う（または特権の低い開発者向け）場合、ハブのプルリクエスト機能は、上流のマスターリポジトリ（組織のリポジトリ？）からのプルリクエストを処理しますか、それとも異なる動作をしますか？ 編集 私は問題、フォーク、プルリクエストでいくつかのテストを行い、それを見つけました。組織のリポジトリに問題を作成した場合、組織からリポジトリを自分のgithubアカウントにフォークし、いくつかの変更を行って、フォークのマスターブランチにマージします。実行しようとするhub -i <issue #>と、エラーが発生しますUser is not authorized to modify the issue。したがって、明らかにそのワークフローは機能しません。

14 version-control  git  teamwork  github  workflows 

新しいプロジェクトを開始し、バージョン管理システムとしてSVN（Tortoiseを使用）を使用しています。同じシステムを使用してSQL Serverデータベースも維持できるかどうか疑問に思っていました。 テーブル/関数/ビュー/プロシージャ/トリガー/などをバージョン管理したいと思います。とにかくテストデータになるため、私のデータはそうではありません。これをどのように設定するのかよくわかりません。いくつかのオプションに出くわしましたが、足りないものがあったかどうか、そしてそれを実行するために役立つガイドや何かがあるかどうかを知りたいです。 Red Gateを見たことがありますが、無料のもの（または少なくとも非常に低価格）を探しています。私はいつでも自分で何かを書くことができることを知っていますが、私はそのことに時間を費やそうとはしていません。 私が遭遇したことの1つは、ScriptDB4Svnと呼ばれるオープンソースパッケージをまとめたことです。誰もこれを以前に使用しましたか？いいですか？必要なことはできますか？セットアップは簡単ですか？

14 version-control  svn  sql-server 

競合マーカーを検討してください。すなわち： <<<<<<< branch blah blah this ======= blah blah that >>>>>>> HEAD この質問を投稿する動機となった特定のケースでは、担当のチームメンバーがアップストリームからブランチへのマージを完了したばかりで、場合によっては、これらをコメントとして、今までの内容に関する一種のドキュメントとして残していました解決しました。彼はそれをコンパイルされた状態のままにして、テストに合格したので、あなたが思うほど悪くはありません。 本能的には、私は本当にこれに異議を唱えましたが、悪魔が自分自身を擁護しているので、なぜ彼がそれをしたのかがわかります： マージの結果として変更されたものを他のチーム開発者に強調するためです。 特定のコードに精通している人は、コメントが示す懸念に対処できるため、推測する必要がありません。 アップストリームマージは適切な痛みであり、すべてを適切かつ完全に解決するための時間を正当化するのが難しい可能性があるため、いくつかの半完全なFIXME通知が必要です。 私の反対は本能的でしたが、それを合理的に正当化するか、自分の立場をより賢く見たいと思います。誰かが私にいくつかの例や、誰かがこれをやっていると悪い時間を過ごした経験や、それが悪い習慣である理由を教えてもらえますか（または悪魔の擁護者を演じてそれをサポートすることができます）。 私自身の当面の懸念は、関係するファイルの1つを編集し、変更を取得し、実際の競合を取得したが、コメントされたファイルも取得した場合、明らかに迷惑になることでした。そうすれば、本当に非常に面倒なファイルになっていたでしょう。幸いなことにそれは起こりませんでした。

14 version-control  comments  coding-style 

私は.NET開発者であり、ソース管理ソフトウェアとしてTFS（チーム基盤サーバー）を何度も使用しています。TFSの優れた機能は次のとおりです。 Visual Studioとの良好な統合（だから私はほとんどすべてを視覚的に行う;コンソールコマンドはなし） 簡単なチェックアウト、チェックインプロセス 簡単なマージと競合解決 簡単な自動ビルド 分岐 ここで、Gitをオープンソースプロジェクトのバックボーン、リポジトリ、およびソース管理として使用したいと思います。私のプロジェクトは、C＃、JavaScript、またはMySQLを使用したPHP言語、またはストレージメカニズムとしてのSQL Serverデータベースです。 この目的でgithub.comのヘルプを使用し、そこでプロファイルを作成し、Git用のGUIをダウンロードしました。ここまではとても簡単でした。 しかし、私はこれ以上先を行くことにほとんど詰まっています。次のようないくつかの単純な（本当に単純な）操作を行いたいだけです。 Gitでプロジェクトを作成し、ラップトップのフォルダーにマッピングする ファイルとフォルダーのチェックアウト/チェックイン 競合の解決 それが今私がする必要があるすべてです。しかし、GUIはユーザーフレンドリーではないようです。GUIにはそのConnect To...ようなものがあり、プロジェクトのリストが表示されることを期待しています。1つを選択すると、TFSプロジェクトを探索するのと同じように、そのプロジェクトのファイルとフォルダーのリストが表示されますVisual Studioで。次に、ファイルを右クリックして、check-in...またはcheck-outそのようなものを選択できるようにします。 私は多くを期待していますか？TFSのようにGitを簡単に使用するにはどうすればよいですか？ここで何が欠けていますか？

14 version-control  git  github  team-foundation-server 

私は自分の部署にMercurialを紹介しました。私はそれが大好きですが、それは私の最初のバージョン管理の経験です。Web開発用にNetBeans PHPで使用しています。 社内のアプリケーションで作業する別の開発者は、Visual Source Safeの使用を好み、切り替えたくないと考えています。彼はVisual Studio環境で働いています。 他のすべての開発者は、これを除いてMercurialに買収しました。しかし、ほとんどの場合、私たちは皆独立して仕事をしています。 私はこの部門を正しい方向に動かそうとしています。Kilnのアカウントで全員を設定しました。Fogbugzを使用しているすべての人にも道を譲りたいと思っていました（現在、バグデータベースが維持されていないため） VSSを使用したことはありませんが、非常に悪いことを聞いています。 それが彼が好むものであるなら、彼にVSSの使用を続けることを許可するほうが良いでしょうか、それともMercurialで彼を乗せるのが最善の利益でしょうか？

14 project-management  version-control  team  visual-studio  mercurial 

リリースされたバイナリをバージョン管理下に保つにはどうすればよいですか？これにより、各リリース間で変更された内容を追跡できます。ソースリポジトリからリリースされたバイナリを分離するつもりです。リリースされたバイナリは、継続的インテグレーションソフトウェアから構築されるか、手動でコンパイルされます。

14 version-control  release-management