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

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

6
新しいプロジェクトのマスターへのコミットをいつ停止する必要がありますか?
新しいプロジェクトを開始するときはいつでも、「安定した」何かを得るまでマスターに直接コミットすることから始めて、ブランチで作業を開始するのが通常理にかなっています。 少なくとも、これは私が通常行う方法です。2番目のコミットからすぐにブランチを開始する方法はありますか?このようにするのは理にかなっていますか?明らかに、「初期コミット」は常にマスターになりますが、その後、いつ新しい機能のブランチを作成するのが適切なタイミングであるかがわかりますか?

8
Git-マスターで直接作業することから生じる問題は何ですか?
gitブランチモデルに関する多くのアドバイスを見てきましたが、最も一般的な意見は、masterブランチで直接変更を加えることは悪い考えだと思われます。 同僚の1人がmasterブランチ上で直接変更を行うことを非常に喜んでおり、いくつかの会話にもかかわらず、彼らはこれを変更する可能性は低いようです。 現時点では、マスターに直接取り組むのは悪い習慣である同僚を納得させることはできませんが、私は彼の働き方と矛盾することを理解し、いつ再訪する必要があるかを知りたいですこの問題。

6
複雑なマージにどのようにアプローチしますか
ここに取引があります。私は新しい会社に入社し、ほとんど一年間触れられていないブランチの仕事を終えるように頼まれました。一方、マスターブランチは安定したペースで成長しています。masterブランチからのすべての変更をfeatureブランチにマージして、そこから作業を継続したいのが理想ですが、どのようにこれにアプローチするのかはよくわかりません。 ブランチの両側で重要な変更を保持しながら、このマージを安全に実行するにはどうすればよいですか?

6
TDDとバージョン管理
現在、TDDについて学び、個人プロジェクトでTDDを実践しようとしています。また、これらのプロジェクトの多くでバージョン管理を広範囲に使用しました。私は、特にコミットを小さく保つという格言に関しては、典型的なワークフローにおけるこれら2つのツールの相互作用に興味があります。ここに思い浮かぶいくつかの例があります: 新しいプロジェクトを開始し、まだ存在しないクラスを作成する簡単なテストを作成します。テストがコンパイルされない場合でも、クラスを作成する前にテストをコミットする必要がありますか?または、コミットする前にテストをコンパイルするために必要な最小限のコードをスタブアウトする必要がありますか? バグを見つけ、テストを作成して再作成します。失敗したテストをコミットするか、バグ修正を実装してからコミットする必要がありますか? これらは、すぐに思い浮かぶ2つの例です。回答に追加の例を提供してください。 編集: 両方の例で、テストを書いた直後にテストをパスするコードを書くと仮定しました。別の状況も発生する可能性があります。私は、コミットせずに数時間TDDを使用してプロジェクトに取り組んでいます。最終的にコミットするとき、作業を小さなチャンクに分割します。(Gitは、1つのファイルの一部の変更のみをコミットしたい場合でも、これを比較的簡単にします。) これは、私の質問は、いつコミットするかということと同じくらいコミットすることに関することを意味します。

7
ビルドがほとんど常に壊れているときに効率を維持する方法
私は同じソースコードを共有し、継続的に統合されている中規模のチームで働いていますが、私たち全員が同じブランチで作業しなければならないため、ビルドはほとんど常に壊れています。 また、壊れたビルドを軽減するために最近導入されたルールもあります。これは、ビルド中は誰もチェックインできないことを示しています。 そうは言っても、1日の間に誰もがチェックインできる10〜15分のウィンドウを持っています。 チームが成長するにつれて、チェックインの機会の窓はさらに小さくなります。そのため、開発者は変更をローカルに蓄積する必要があり、その結果、変更セットが大きくなり、変更が何も破壊しないことを保証するのがさらに難しくなります。悪循環を見ることができます。 このような環境で私が効果的に仕事を続けられるようにするために何をお勧めできますか。また、私はマネージャーではなく開発者であり、プロセスや他の人の行動をあまり変更できないことに注意してください。

6
プログラミング学生にとって、どのDVCS(gitまたはhg)が簡単ですか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5年前に閉鎖されました。 ちょっとした文脈:私は大学3年生です。学生は4人のチームに分かれています。ほとんどの人はWindowsで作業しています(Linuxを使用している私のような少数の人を除く)。学校のカリキュラムの一環として、まもなく本物のクライアント向けのプロジェクトに取り掛かりますが、私と別のチームは、コードを相互に共有するのにどの方法が最適か疑問に思っています。 私は3年間パートタイムで働いており、さまざまなプロジェクトでgitとmercurialの両方を使用した経験が豊富なので、どちらのシステムを使用しても問題はありません。しかし、私のチームメートは誰もバージョン管理システムを使用したことがありません。SVNを使用しようとしたが、大きな問題があり、他の何かを試してみたいと思う別のチームもいるので、彼らは私の意見を求めました。 私の考え:Mercurial + TortoiseHgはWindowsの下でより良く統合されていると聞いたことがありますが、匿名の頭の概念が説明しても混乱させるのではないかと思っています。一方で、初心者にとってはgitブランチの方が理解しやすい(各プログラマーの作業が明確に分離されている)が、Windowsではうまく機能しないことがわかりました。

8
クローズドソースの高リスクプロジェクトの管理方法
現在、J2EE Webサイトの開発を計画しており、私を支援するために1人の開発者と1人のWebデザイナーを連れてきたいと思っています。このプロジェクトは、ニッチ市場内の金融アプリです。 ソースを閉じたままにする予定です。しかし、私の従業員は、コードベースを簡単にコピーして使用したり、サードパーティに販売したりするのを恐れています。アプリの開発には4〜6か月、おそらくそれ以上かかります。アプリが公開された後、私は従業員を追加することができます。 しかし、どのようにソースを自分自身に保持しますか。企業がソースを保護するために使用する手法はありますか? 開発マシンでUSBドライブとDVDライターを無効にすることは考えていますが、データをアップロードしたり、コードを電子メールに添付したりすることは可能です。 私の質問は不完全です。しかし、私の状況にあったプログラマーはアドバイスをお願いします。これについてどうすればいいですか?チームの構築、コードの機密保持など。 必要に応じて、従業員と秘密保持契約を結ぶことを楽しみにしています。(関連するタグを追加してください) 更新 すべての答えをありがとう。確かに、今ではすべてのUSBポートとDVDライターを無効にするわけではありません。しかし、私はアクティビティをログに記録する必要があると思います(どのように正確に行う必要がありますか?)既存のコードに参加して実行するスカルパーには警戒しています。会ったことはありませんが、警戒するように勧められています。私は秘密の条項を含めますが、これはほとんど資金がないスタートアップであり、この分野でより大きなプレーヤーがいる非常に競争力のあるビジネスニッチであるため、スカルパーを検出または追跡できるとは思えません。 個人的に知らないときに、信頼できる人をどのように雇うのですか。彼らの履歴書は役に立ちますが、そうでなければ信頼は時間とともにのみ発達します。 しかし、最終的に彼らがコードで逃げたとしても、販売が行われた後に重要なのはサービスです。ですから、長期的にはあまり心配していません。

4
バージョン管理にgithub、ブランチ、自動リリースを使用する方法は?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 今まで、Git / Githubの基本的な概念のほとんどを理解していましたが、全体像を理解するのはまだ困難です。 これらは私がこれまでに何とか作業を始めたものです。 コミットをプッシュする ブランチで作業する Githubを継続的な統合システムであるTravis CIと統合する Travis CIを介して、マスターへのコミットごとに自動的にビルドし、リリースをGithubのリリースとしてZIPとしてリリースします。 しかし、私はこれまでにプロジェクトのアルファ版またはベータ版にしか取り組んでいなかったため、実際にバージョン付きリリースを見たことはありません。 したがって、バージョン管理、個別のバージョンの維持、バージョンの修正プログラムなどについて詳しく知りたいと思います。 次のことが起こるようにするにはどうすればよいですか: 私のプロジェクトの異なるバージョン、たとえばバージョン1.1.0と2.0.0を持っている バージョンの修正プログラムをプッシュしたり、バージョンを1.1.1や2.0.1に変更したりすることができます。 継続的統合システムがコミット時にそのバージョンを自動的にビルドし、成功した場合は、その特定のバージョンのリリースを公開します。 私は次のオプションの間で疑っています: バージョンごとにタグを使用する必要がありますか?もしそうなら、継続的インテグレーションシステムはどのようにしてリリースを自動的にビルドできますか? バージョンごとにブランチを作成する必要がありますか?もしそうなら、それはたくさんのブランチを作成しませんか(1.1や2.0ブランチのように、もちろんホットフィックスはそのブランチに行きます) バージョン番号はどのように指定しますか?バージョン番号を指定する構成ファイルを用意しても大丈夫ですか、それとももっと賢い方法がありますか?この場合、それが重要であれば、Javaプロジェクトになります。

6
最新のバージョン管理システムの利点の定量化[終了]
閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 私は、大規模な金融企業環境でチームリーダー/開発者として3年間の大半を担当しました。生産リリースプロセスは、Clearcaseを中心に展開するため、悪夢です。すべてのリリースを実行し、そこから取得したコードのみを本番環境に許可する変更管理グループがあります。 参加したときに最初にしたことの1つは、Gitでチームを設定することでした。誰もが、Clearcaseはひどく、日々のソース管理の問題を処理するには実用的でないことに同意しました。そこで、ローカルマシンに一種の「非公式」リポジトリをセットアップし、リリース時間前後にgitとClearcaseリポジトリを同期するスクリプトを作成しました。 このことは他のチームにも広まり、いくつかのチームが同じプロセスを採用しています。日々の活動にはgitを「非公式」に使用し、リリースにはClearcaseを使用して「公式に」使用します。私は、Gitの問題については、やる気になりました。 そのため、今週、インフラストラクチャの変更を担当するSVPとの会議を開催し、Gitのメリットを彼女に説明してもらいたいと考えています。明らかに、Clearcaseでの頻繁な暴言が彼女に届いたようです。彼女が私の主張を受け入れれば、私の雇用主がこの忌まわしいものを取り除くのを手伝うことに真剣に取り組むでしょう。 経営者との私の経験は、a)すべてについて非常に簡潔な説明を望んでいること、b)ドルの数字を含む事実のみに関心があることを教えてくれます。 開発者には、Clearcase(またはClearcaseを介した他のバージョン管理システム)を介したGitのメリットを説明できますが、技術的背景のない技術幹部にこれを行う方法について空白を書いています(彼女はMBAを取得し、地理学で学部を卒業しました)。 私が彼女に対して行った議論は、技術的な意味不明なもののように聞こえるか、個人的な好みを伝道していると感じています。 私が見つけようとしているのは、開発者がGitまたはあらゆる最新のソース管理システムでより効果的に作業することを示す具体的な事実です。 他のチームが内部でGitを使用し始めたという事実は意味のある兆候であると思いますが、個人的な好みとしては却下される可能性があるため、まだ十分ではありません。 私が本当に必要なのは、「このプロセスは20年間機能していましたが、なぜ変更する必要があるのですか?」引数。

4
ライブラリの異なるバージョンをどのようにバージョン管理下に置きますか?タグを使用していますか?または枝?または別の方法?
私は最近、自分のコードをバージョン管理下に置き始めました(私が働いているラボではSVNで、自分のコードはgithubで(明らかにgitで))。バージョン管理を使用する前に、私はこのようなことをしていました。バージョン番号の付いた多くのフォルダーの中に、ライブラリーの名前のフォルダーがありました。新しいバージョンで作業を開始するたびに、最後のバージョンのコピーを作成し、名前を新しいバージョンに変更して実装を開始します。 ただし、フォルダがバージョン管理下に置かれている場合、これはかなり冗長に思えます。冗長性は別として、誰かが最新バージョンを入手したい場合、彼import/ 彼女たちがちょうどあればすべてのバージョンをダウンロードするでしょうclone。 現在、バージョン管理を使用してこれを行う多くの方法を見ていますが、私はそれが初めてなので、どちらがより保守可能かはわかりません。 方法1:タグを使用する 私がタグを正しく理解していれば、メインブランチがあります。取得した変更をコミットし、バージョンでタグ付けします。次に、作業コピーを取得したい場合は、特定のタグが付いたコピーを取得します。(間違っている場合は修正してください) 方法2:分岐バージョン この方法では、メインブランチは開発ブランチになります。時々、安定したバージョンがv1.2.0作成されるとしましょう(たとえば)、そのバージョンのブランチを作成し、コミットしません。そうすれば、特定のバージョンをダウンロードする場合、そのブランチからコードを取得できます。私はあなたがそれにコミットすることは決してないと言ったが、バグ修正を行い、古いバージョンのブランチにコミットして古いバージョンを実行し続けることが可能かもしれない。現在のバージョンがある場合たとえばv2.0、しかし、使用したい人がいるv1.2、あなたはから別のブランチを取得することができv1.2、すなわち、v1.2.1およびバグ修正をコミット、またはちょうど同じバージョンを保持v1.2し、単にバグ修正をコミットします。 したがって、ブランチは次のようになります。 v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / -------------------------------------- dev このようにして、マイナーバージョンアップデートごとにブランチを作成できます。(上のグラフでは、v1.2.1とv1.2.2、またはv2.0.0のリリース後に作成されたため、v1.2.0とv2.0.0の間の開発の一部ではないことに注意してください。古いバージョンのサポートと考えてください) 方法3:分岐開発 この方法は前の方法の反対です。メインブランチは最新の安定バージョンです。新しいバージョンで作業しているときは常に、(開発用の)ブランチを作成し、コードで作業し、安定しているときにメインブランチとマージします。 この場合、ブランチは次のようになります。 ________ ____ ________________ _____ dev / \/ \/ \/ ---------------------------------- latest_version おそらくこれはタグと組み合わせて行う必要がありますか? 質問! とにかく、私の質問はあなたの経験に基づいて、これらの方法のどれがより実用的であると証明しますか?そこに知られている最良の方法はありますか(おそらく私は自分自身を理解していなかった)?これらのことは一般的にどのように行われますか?

9
エンタープライズ環境でのGitの使用[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 Gitは優れたバージョン管理システムです。優れたGUIサポートがないという事実を除外すると、本当に優れた高速です。しかし、Clearcaseのようなソース管理は、企業顧客を大規模にサポートしています。企業は、ソース管理サーバーとライセンス認証に多額の投資をしています。 最近、Googleのような大企業のほとんどは、他のバージョン管理システムよりもGitを採用しています。しかし、この会社には強力なオープンソースグループがあり、ツールの開発とサポートを一貫して提供しています(独自のGitのカスタムバージョンを持っている場合もあります)。同時に、大企業はオープンソースプロジェクトを採用し、それらに関連性を持たせることを本当に気にしていません。 Gitはエンタープライズ環境、特にWindowsプラットフォームで本当に信頼できるツールですか? Gitはオープンソース製品であるため、Gitのサポートは問題です。 ソリューションとサポートを提供する会社はありますか?サーバーのコストは、クリアケースなどの他のバージョン管理と比較してどうですか?

5
すべての開発がブランチ上にあるときにリファクタリングする方法は?
私の会社では、すべての開発(バグ修正と新機能)は別々のブランチで行われています。完了したら、QAに送信し、QAがそのブランチでテストします。QAが青信号を出したら、メインブランチにマージします。これには、1日から1年かかることがあります。 ブランチでリファクタリングを絞り込もうとすると、どれくらいの期間「アウト」されるかわからないので、マージして元に戻すと多くの競合が発生する可能性があります。 たとえば、作業中の機能がこの関数を頻繁に使用しているため、関数の名前を変更したいとします。名前が実際には目的に合わないことがわかりました(これも単なる例です)。そこで、この関数のすべての使用法を見つけて、それらをすべて新しい名前に変更すると、すべてが完全に機能するため、QAに送信します。 その間、新しい開発が行われており、名前が変更された関数は、メインから分岐されているブランチのいずれにも存在しません。私の問題が再び統合されると、それらはすべて壊れてしまいます。 これに対処する方法はありますか? 経営陣がリファクタリングのみの問題を承認するようなことはないので、他の作業に絞り込まなければなりません。mainで直接開発することはできません。なぜなら、すべての変更はQAを通過する必要があり、mainを壊したジャークになりたくないので、彼は少しの非本質的なリファクタリングを行うことができるからです。

6
あまりにも多くのオーバーヘッドなしでコーディングの進行を意味のあるコミットに分割する
修正または機能の作業をしているとき、数秒でその場で改善できる他の小さな問題に出くわすことがあります。すぐにそれらを行い、完成した機能/修正をコミットすると、コミットには複数のことが含まれます。たとえば"add feature X and code clean up"または"fix bug X and improved logging"。これを2つのコミットに分割することをお勧めします。同じファイルで2つの変更が発生した場合、1つのファイルを追加してコミットし、もう1つのファイルを追加してから再度コミットすることはできません。したがって、次の3つのオプションが表示されます。 何かに取り組んでいる間、無関係なものを故意に見落とします。 2つの変更を加えてファイルをコピーし、元に戻し、1つの変更を含めてコミットし、もう1つの変更を含めて再度コミットします。 関係のない小さなことは変更せずに、todoリストに追加して後で実行します。 次の理由により、3つのオプションのすべてが本当に好きではありません。 小さな問題を解決しないと、コードの品質が低下する可能性があります。そして、多くの努力をせずに何かを改善する機会を意識的に逃した場合、私は気分が悪いです。 これにより、手作業が増え、エラーが発生しやすくなります。 これはあまり手間がかからないTodoには問題ありませんが、ToDoリストに小さなアイテムを追加して後で再訪することは、すぐに修正するよりもはるかに時間がかかります。 そのような状況にどのように対処しますか?

7
プロトタイピングのためにGPLライブラリを一時的に使用し、将来のコードをクローズドソースにすることはできますか?
私はソフトウェアシステムのプロトタイプを作成しています。これは(少なくとも最初は)クローズドソースになります。 時間を節約するために、GPLv3でライセンスされているライブラリを使用する(つまり静的にリンクする)ことを考えているので、設計をすばやくテストできます。この段階でソフトウェアを配布した場合、ソースコードも一緒に配布する必要があります。 そうしないが、システムが動作することを確認し、配布する前にGPLライブラリを自分のコードに置き換えたらどうなりますか?結果はGPLによって「汚染」されますか? 私は、GitライブラリーをGitの履歴に保持するかどうかが、違いを生む可能性があると感じています。

5
オープンソースプロジェクトの外部依存関係をどのように処理しますか?
オープンソースプロジェクトを作成し、Google CodeまたはGitHubを使用していて、Luaなどのライブラリを使用したい場合、どのようにすればよいですか? 依存関係をリポジトリに含める必要がありますか? 依存関係は、プロジェクトの他の部分と同じビルドスクリプト内からビルドする必要がありますか、それとも別のビルドスクリプトからビルドする必要がありますか? ライブラリをコンパイルする前にインストールする必要はありません。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.