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

アクションに使用される単語の意味を見つけることができなかったため、gitを理解するのは難しいと感じています。辞書で「ステージ」の意味を確認しましたが、ソース管理の概念に関連する意味はありませんでした。 gitのコンテキストで「ステージ」とはどういう意味ですか？

316 git  version-control 

分散バージョン管理システム（DVCS）の利点を理解しようとしています。 Subversion Re-educationとMartin Fowlerによるこの記事は非常に有用であることがわかりました。 Mercurialおよびその他のDVCSは、変更セットとローカルコミットを使用してコードを処理する新しい方法を促進します。それは地獄と他のコラボレーションの問題をマージすることを防ぎます 私は継続的な統合を実践しているので、これに影響されることはありません。プライベートブランチで単独で作業することは、実験しない限りオプションではありません。メジャーバージョンごとにブランチを使用し、トランクからマージされたバグを修正します。 Mercurialを使用すると、副官を持つことができます これはLinuxのような非常に大規模なプロジェクトに役立つ可能性があることは理解していますが、小規模で高度に協力的なチーム（5〜7人）には価値がありません。 Mercurialはより高速で、ディスクスペースが少なくて済み、完全なローカルコピーにより、ログと差分の操作がより高速になります。 私が取り組んでいる非常に大規模なプロジェクトであっても、SVNの速度やスペースの問題に気づかなかったので、私もこれには関心がありません。 元SVNオタクからの個人的な経験や意見を求めています。特に、変更セットの概念と、測定した全体的なパフォーマンスの向上に関して。 更新（1月12日）：今、試してみる価値があると確信しています。 更新（6月12日）：Mercurialにキスし、気に入った。彼の桜の地元のコミットメントの味。試しにMercurialにキスしました。SVNサーバーがそれを気にしないことを願っています。それはとても間違っていた。とてもいい感じがしました。今夜恋しているわけじゃない。 最終更新（7月29日）：Eric Controlの次の例であるVersion Control by Exampleをレビューする特権がありました。彼は私を納得させました。Mercurialに行きます。

300 version-control  git  mercurial  dvcs  svn 

プログラマーツールをめぐる議論の大半は、個人的な選択（ユーザーによる）またはデザイン重視、つまり特定のユースケースに応じたデザインの最適化（ツールビルダーによる）に留まることは間違いありません。テキストエディターはおそらく最も有名な例です-職場ではWindowsで動作し、自宅ではMacでHaskellでコードを作成するコーダー、クロスプラットフォームおよびコンパイラー統合を重視するため、TextMateではなくEmacsを選択します。 新しく導入された技術が、現存するオプションよりも明らかに優れていることはあまりありません。 これは実際、バージョン管理システム（VCS）、特に集中型 VCS（CVSおよびSVN）対分散 VCS（GitおよびMercurial）の場合ですか？ SVNを約5年間使用しましたが、現在、SVNは私が働いている場所で使用されています。3年弱前、すべての個人プロジェクトでGit（およびGitHub）に切り替えました。 Subversionに対するGitの多くの利点（および集中型VCS上の分散の利点の大部分を抽象化する）を考えることはできますが、1つの逆の例、つまり関連するタスクと通常のプログラマーで生じるいくつかのタスクを考えることはできませんワークフロー）そのSubversionはGitよりも優れています。 だけではないGitが優れていること、など-私はこのことから描いた結論は、私がどのようなデータを持っていないということです 私の推測では、そのような反例が存在するため、この質問です。

293 tools  git  version-control 

私は過去2つの会社でGitをバージョン管理に使用しました。私が聞いたところでは、企業の約90％が他のバージョン管理システムよりもGitを使用しているようです。 Gitの最大のセールスポイントの1つは、Gitが分散化されていることです。つまり、すべてのリポジトリが同等です。中央リポジトリ/真実の源はありません。これはLinus Torvaldsが擁護した機能でした。 しかし、すべての企業がSVNやCVSを使用するのと同じように、Gitを集中的に使用しているようです。サーバー（通常はGitHub）には、常に中央リポジトリがあり、人々はそこからプルし、プッシュします。Gitを本来の目的である分散化された方法で使用している人、つまり他の同僚のリポジトリを適切に押したり引いたりしている人を見たことはありません（確かに限られた経験）。 私の質問は： Gitの分散ワークフローを実際に使用しないのはなぜですか？ 分散した方法で機能する能力は、最新のバージョン管理にとっても重要ですか？ 編集 私は元の質問で正しい口調に出会えなかったことに気付きました。分散バージョン管理システム（DVCS）が明らかに優れているのに、なぜ誰もが中央集権的に機能するのかと私が尋ねているように聞こえました。実際には、私が言いたいことは、DVCSには何のメリットもありません。しかし、実世界は私の見解に同意しているように見えますが、私はしばしば人々がその優位性を説くのを聞きます。

289 version-control  git 

gitほとんどのプロジェクトをモジュール化した環境では、リポジトリごとに1つのプロジェクト、またはリポジトリ設計の問題ごとに複数のプロジェクトに直面しています。モジュール化されたプロジェクトを考えてみましょう。 myProject/ +-- gui +-- core +-- api +-- implA +-- implB 現在、リポジトリごとに1つのプロジェクトがあります。それは自由を与えます release 個々のコンポーネント tag 個々のコンポーネント しかしbranch、多くの場合、分岐にapiはの同等の分岐が必要coreであり、おそらく他のコンポーネントも必要であるため、コンポーネントにとっても面倒です。 releaseコンポーネントを個別にしたい場合でも、リポジトリ設計ごとに複数のプロジェクトを利用することで、同様の柔軟性を得ることができます。 どのような経験があり、これらの問題にどのように/なぜ対処しましたか？

223 java  programming-practices  version-control  git  maven 

私は、ユーザーがTwitter、GoogleなどのOAuth資格情報を使用してログインできるようにするWebサイトに取り組んでいます。これを行うには、これらのさまざまなプロバイダーに登録し、所有している極秘APIキーを取得する必要がありますさまざまな身体部分からの誓約で保護する。キーがギャンクされると、パーツがヤンクされます。 APIキーは実行時に認証要求を実行するために使用されるため、ソースと共に移動する必要があります。私の場合、キーはアプリケーション内の構成ファイルまたはコード内に存在する必要があります。単一のマシンからビルドして公開する場合、それは問題ではありません。ただし、ソース管理をミックスに組み込むと、事態はさらに複雑になります。 私は安っぽい野郎なので、クラウド内のTFSやGitHubなどの無料のソース管理サービスを使用することを好みます。これにより、若干の難問が残ります。 APIキーがコード内にあり、コードが公開リポジトリで利用可能な場合、どうすれば体を傷つけずに保持できますか？ これを処理する方法はいくつか考えられますが、満足できるものはありません。 コードからすべての個人情報を削除し、展開後に編集することができます。これは実装するのが非常に苦痛であり（多くの方法を詳しく説明しません）、オプションではありません。 暗号化できました。しかし、私はそれを解読しなければならないので、ソースを持っている人は誰でもそれを行う方法を見つけ出すことができました。無意味。 私は個人的なソース管理にお金を払うことができました。LOL j / kはお金を使いますか？お願いします。 言語機能を使用して、機密情報をソースの他の部分から分離し、ソース管理から保護することができます。これは私が今やっていることですが、誤ってシークレットファイルをチェックインすると簡単に失敗する可能性があります。 開発、デバッグ、展開を通じてスムーズに動作し、同様に確実に動作するプライベートを世界と共有しないことを保証する方法を本当に探しています（snapchatを除く）。これは完全に非現実的です。 それでは、現実的に何ができますか？ 技術的な詳細：VS2012、C＃4.5、ソース管理はTFサービスまたはGitHubのいずれかになります。現在、部分クラスを使用して、ソース管理に追加されない別の.csファイルで機密キーを分割します。GitHubには、.gitignoreを使用して部分的なクラスファイルがチェックインされないようにすることができるという利点があると思いますが、以前はそれを台無しにしました。「ああ、よくある問題、これがあなたのやり方です」を望んでいますが、私は「それができる限り吸わない」ために解決する必要があるかもしれません：/

217 project-management  version-control  development-process  api 

バージョン管理としてGitとGithubを使用する分散チームの場合、画像もgitリポジトリに保存する必要がありますか？ ほとんどの場合、画像は変更されません。それらを含むフォルダーは、画像が追加されるとサイズが大きくなります。懸念事項は、大きな画像の組み合わせ、またはそれらの多くだけで、画像フォルダが時間とともに大きくなる可能性があることです。 これはベストプラクティスと見なされますか？分散チームが簡単にアクセスできるプロジェクトで必要なバイナリファイルを共有するために、他にどのような方法がありますか？

201 version-control  git  github 

gitを学んでいますが、2段階のコミットプロセスがあることに気付きました。 git add <files> git commit 最初のステップでは、リビジョンを「ステージング領域」または「インデックス」と呼ばれるものに配置します。 私が興味を持っているのは、この設計上の決定が行われる理由と、その利点は何ですか？ また、gitユーザーとしてこれを行うか、単に使用しgit commit -aますか？ この機能を持っていないbzr（Bazaar）から来たので、これを尋ねます。

174 version-control  git  workflows 

これは実際には技術的な質問ではありませんが、ソース管理とベストプラクティスに関する他の質問がいくつかあります。 私が働いている会社（匿名のまま）は、ネットワーク共有を使用してソースコードとリリースされたコードをホストしています。開発者または管理者は、ソースコードがリリースされているか、どのバージョンであるかなどに応じて、ソースコードを適切なフォルダーに手動で移動する責任があります。ファイル名とバージョン、および変更内容を記録する場所の周りにさまざまなスプレッドシートが点在しており、一部のチームは各ファイルの先頭に異なるバージョンの詳細も記載しています。各チーム（2〜3チーム）は、社内でこれを異なる方法で行うようです。あなたが想像できるように、それは組織化された混乱です-「正しい人々」は彼らの物がどこにあるかを知っているので組織化されていますが、それはすべて異なっていて、それはいつでも何をすべきかを覚えている人々に依存しているため混乱です。 私はしばらくの間、ある種の管理されたソース管理を推進し​​ようとしてきましたが、社内で十分なサポートを得ることができないようです。私の主な議論は次のとおりです。 私たちは現在脆弱です。いつでも誰かが私たちがしなければならない多くのリリースアクションの1つを行うのを忘れることができます。これは、バージョン全体が正しく保存されないことを意味します。必要に応じて、バージョンをつなぎ合わせるのに数時間または数日かかる場合があります バグ修正と一緒に新機能を開発しており、一部の作業がまだ完了していないため、多くの場合、どちらか一方のリリースを遅らせる必要があります。また、バグ修正だけが必要な場合でも、新しい機能を含むバージョンを使用するようにお客様に強制する必要があります。 複数の開発者が同じプロジェクトを同時に使用しているため、Visual Studioで問題が発生しています（同じファイルではありませんが、依然として問題が発生しています） 開発者は15人しかいませんが、私たちはすべて異なる方法で作業を行っています。私たち全員が従わなければならない標準的な全社的なアプローチをとる方が良いと思いませんか？ 私の質問は： このサイズのグループにソース管理がないのは正常ですか？ 私はこれまで、ソースコントロールを持っていないための唯一の漠然とした理由が与えられている-あなたが示唆している何の理由の可能性のために有効ではない 上記の情報与えられ、ソースコントロールを実装しますか？ 任意のより多くの理由があるため、私は私の兵器庫に追加できるソースコントロールは？ 私は主に私がなぜそんなに抵抗したのか感じてもらいたいので、正直に答えてください。 私は、最もバランスのとれたアプローチを取り、3つの質問すべてに答えたと思う人に答えます。 前もって感謝します

152 version-control  project-management  management  release-management 

現在、Pro Gitを読んでGitの使用方法を学んでいます。今、私は分岐とタグについて学んでいます。私の質問は、いつブランチを使用する必要があり、いつタグを使用する必要があるかです。 たとえば、プロジェクトのバージョン1.1のブランチを作成するとします。このバージョンを終了してリリースしたら、ブランチを残してリリースバージョンをマークする必要がありますか？または、タグを追加する必要がありますか？タグを追加する場合、バージョンブランチを削除する必要があります（マスターまたは他のブランチにマージされていると仮定します）。

141 programming-practices  version-control  git  branching 

現在、共有リポジトリにPHPアプリケーションのマスターブランチが1つあります。当社のソフトウェアの加入者であるクライアントは500人を超えており、そのほとんどが異なる目的のために、それぞれ個別のブランチにカスタマイズされています。カスタマイズは、異なるテキストフィールド名、まったく新しい機能またはモジュール、またはデータベース内の新しいテーブル/列にすることができます。 私たちが直面する課題は、これらの数百のカスタマイズされたブランチを維持し、クライアントに配布する際に、時々新しい機能を提供し、マスターブランチを更新し、更新するためにマスターブランチの変更をカスタムブランチにプッシュすることですそれらを最新バージョンに。 残念ながら、これによりカスタムコードで多くの競合が発生することが多く、すべての競合を解決するためにすべてのブランチを何時間も費やしています。これは非常に非効率的であり、これらの競合を解決する際に間違いは珍しくありません。 クライアントブランチをマスターブランチに合わせて最新の状態に保ち、マージ中の労力を軽減するより効率的な方法を探しています。

140 version-control  git  github  versioning  branching 

私の組織はSVNからGitへの移行を検討しています。移動に対する1つの議論は次のとおりです。 バージョン管理はどのように行いますか？ NetBeansプラットフォームに基づいたSDKディストリビューションがあります。SVNリビジョンは単純な番号であるため、それらを使用してプラグインとSDKビルドのバージョン番号を拡張できます。Gitに移行するとき、これをどのように処理しますか？ 可能な解決策： Hudsonのビルド番号を使用する（問題：Hudsonを確認して、実際のGitバージョンと関連付ける必要があります） 夜間および安定のためにバージョンを手動でアップグレードする（問題：学習曲線、ヒューマンエラー） 他の誰かが同様の問題に遭遇してそれを解決した場合、私たちはどのように聞いてみたいです。

131 version-control  git  svn  builds  versioning 

近年、Gitをめぐる誇大宣伝が大いに盛り上がりました。誰もがGitについて知っていますが、代替案については誰も知りません。 Mercurialのような他のものは見過ごされているようです。どちらも2005年にリリースされ、同様の機能を提供します。さらに、Mercurialは一般に使いやすく、より直感的で、長い間UIが優れていると考えられています。したがって、これは、特に分散バージョン管理が初めての人にとって、人気のある代替手段であると想定できます。しかし、かなり成功したGitとは異なり、ほとんどの人には知られていないようです。 この投稿のポイントは、この現象をよりよく理解しようとすることです。 どうしてGitはケーキのすべての部分を手に入れたのですか？彼らはどういうわけかより良いマーケティングを使用しましたか？それは、そのコミュニティがもっと... ahem ...「verbose」だからでしょうか？「Linus」の名前のせいですか？それはそのオタク的なイメージのためですか？ あなたの意見は何ですか？

124 version-control  git  mercurial 

私のオフィスは、ブランチの分割とマージをどのように処理するかを理解しようとしており、大きな問題に直面しています。 私たちの問題は、長期的なサイドブランチにあります-マスターから分かれるサイドブランチで数人の人々が働いている種類で、数ヶ月間開発し、マイルストーンに到達すると2つを同期します。 今、私見、これを処理するための自然な方法は、単一のコミットにサイドブランチをつぶすことです。master前進し続けます。当然のことです- master過去数か月の並列開発を過去にさかのぼってダンプしているわけではありません。そして、もし誰かがサイドブランチの歴史のためにより良い解像度を必要とするなら、もちろん、それはすべてまだそこにあります-それはただではなくmaster、サイドブランチにあります。 問題は次のとおりです。私はコマンドラインのみを使用していますが、残りのチームはGUISを使用しています。そして、GUISには他のブランチからの履歴を表示するための合理的なオプションがないことを発見しました。したがって、「この開発はブランチから押しつぶされた」と言って、スカッシュコミットに到達した場合XYZ、何が入っているかを確認するのは非常に苦痛XYZです。 SourceTreeでは、私が見つけることができる限り、それは大きな頭痛の種です：でmaster、からの履歴を見たいmaster+devFeature場合は、チェックmaster+devFeatureアウトする必要があります（異なるすべてのファイルに触れる）、または適切な場所が見つかるまで、リポジトリのすべてのブランチを並行して表示するログをスクロールします。そして、あなたがどこにいるのかを理解してください。 私のチームメイトは、開発の歴史にあまりアクセスできないことを望んでいません。したがって、彼らは、これらの大きくて長い開発側ブランチを、常にマージコミットでマージしたいと考えています。マスターブランチからすぐにアクセスできない履歴は必要ありません。 私はその考えが嫌いです。それは、並行した開発の歴史が無限に行き来できないことを意味します。しかし、私たちがどのような選択肢を持っているのか見ていません。そして、私はかなり困惑しています。これは、優れたブランチ管理について私が知っているほとんどすべてをブロックしているようであり、解決策が見つからない場合は、常にフラストレーションが溜まります。 ここには、サイドブランチを絶えずマージコミットでマスターにマージする以外のオプションがありますか？または、マージコミットを常に使用するのが私が恐れているほど悪くないという理由はありますか？

119 version-control  git  development-process 

プロジェクトがソース管理に最初にコミットするのに十分であるかどうかはわかりません。プロジェクトが「フレームワーク完了」になるまでコミットを延期する傾向があり、それ以降は主に機能をコミットします。（これには大きすぎるコアフレームワークを持つほどの個人的なプロジェクトは行っていません。）これがベストプラクティスではないと感じていますが、何が間違っているのかわかりません。 たとえば、1つのコードファイルで構成されるプロジェクトがあるとします。約10行のボイラープレートコードと、プロジェクトを非常に基本的な機能（1つまたは2つの機能）で動作させるために100行かかります。最初にチェックインする必要があります： 空のファイル？ 定型コード？ 最初の機能は？ 他のポイントで？ また、特定の時点でチェックインする理由は何ですか？

118 project-management  version-control  development-process