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

GitはオープンソースのDVCS(分散バージョン管理システム)です

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

10
私はSubversionオタクです。Mercurial、Git、またはその他のDVCSを検討する必要があるのですか?
分散バージョン管理システム(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に行きます。

20
SVNはGitよりも優れていますか?[閉まっている]
プログラマーツールをめぐる議論の大半は、個人的な選択(ユーザーによる)またはデザイン重視、つまり特定のユースケースに応じたデザインの最適化(ツールビルダーによる)に留まることは間違いありません。テキストエディターはおそらく最も有名な例です-職場では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が優れていること、など-私はこのことから描いた結論は、私がどのようなデータを持っていないということです 私の推測では、そのような反例が存在するため、この質問です。

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

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

14
新しい開発者はブランチのマージについていくことができません
私は新しい開発者です-これが私の最初のプログラミング職です。 私の問題はこれです:私たちは使用しますgit-私はブランチからブランチを切り取り、develop割り当てられたマイナータスクの作業を開始します。私は経験が浅いので、とても遅いです。ブランチをdevelop他のブランチにマージする準備が整うまでに、多くの変更を行って競合を解決するのは圧倒的です(実際、作業を破棄してタスクをやり直すのは簡単なようですが、もちろん持続可能なソリューションではありません) )。 どうすればこれを克服できますか?「コーディングが上手」以外の方法を使用できますか?私は来週、これを上司に報告するつもりです。


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

6
プルリクエストに対してgitコミットをスカッシュするのはなぜですか?
プルリクエストを行うすべての深刻なGithubリポジトリが、コミットを1つのコミットにまとめるように要求するのはなぜですか? gitログがあると思ったので、すべての履歴を調べて、どこでどのような変更が発生したかを正確に確認できますが、それを潰すと履歴から引き出され、すべてが1つのコミットにまとめられます。ポイントは? これは「早期にコミットし、頻繁にコミットする」というマントラにも反するようです。

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

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

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

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

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

11
誰もがマスターで作業しているときにgitの痛みを最小限に抑えるにはどうすればよいですか?
約10人のドキュメントチームが最近SVNからGitに移行しました。SVNでは、誰もがマスターに取り組んでいました。これは私がずっと嫌っていたモデルですが、その変化をもたらすことはできませんでした。Gitへの移行の一環として、それを修正することに同意しましたが、まだそれを行うことはできません(任意のブランチからのビルドを許可するビルドの変更を待機しています)。一方、誰もがマスターに取り組んでいます。はい、私はこれがひどいことを知っています、信じてください。 SVNを使用していたときよりも多くのしゃっくりが見られますが、その一部はGitの2段階モデル​​(ローカルおよびリモート)に起因しています。コミットすることはできてもプッシュできない場合や、保留中のローカル変更と競合してプルする場合があります。昨日、誰かがマージを間違えて最近の変更をなんとかしました-マージが間違っていました。(彼は彼が何をしたかを正確に伝えることができませんでした。彼はGUIを使用しているため、シェルの履歴を調べることはできません。) 最も熟練したGitユーザーとして(読みます:以前に使用しましたが、非常に複雑なものではありません)、私はポリシーを設定し、ツールを教え、混乱をクリーンアップします。ブランチでの開発に切り替えることができるようになるまで、ツールを使用して、共有されたアクティブなマスターのエラーが発生しにくいようにする方法にどのような変更を加えることができますか? チームはWindowsでTortoise Gitを使用しています。以前Tortoise SVNを使用していたため、Tortoise Gitを使用しています。(私は個人的にCygwinの下のコマンドラインをいくつかの操作に使用していますが、チームはGUIが必要であることを明確にしました。これを使用します。) Tortoise Gitには「Commit&Push」という単一の操作があり、常にそれを行うように指示しました。しかし、それはアトミックではありません-コミット(結局ローカル)はうまく機能するが、プッシュは(競合やネットワークの問題などのために)うまくいかないことがあります。その場合、あいまいなエラーが発生します。私は、彼らが持っている場合のBitbucketはコミットログをチェックするためにそれらを言ったいかなる彼らがプッシュする、それが表示されない場合、コミット最近の疑問をして。(そして、それが問題である場合は競合を解決するか、何をすべきかわからない場合は助けを求めます。) チームはすでに「早期かつ頻繁にプルする」という良い習慣を持っています。しかし、プルは競合を引き起こす可能性があるようですが、これは新しいと思いますか?新しくない場合は、SVNよりはるかに頻繁です。Gitがプルする方法(マージではなくリベース)を変更できると聞いたことがありますが、そこでのトレードオフ(または環境でそれを行う方法)について十分に理解していません。 サーバーはBitBucketです(Githubではありません)。私はリポジトリを完全に管理できますが、より一般的にはサーバー上で管理しません。いずれも変更できません。 ソースファイルはXMLです。グラフィックファイルもあります。これは、マージできないことを誰もが知っていますが、衝突はほとんどありません。マージの競合は、グラフィックではなくXMLファイルから発生します。 Gitの使用にどのような変更を加えると、チームで共有マスターがよりスムーズになり、レビュー済みのテスト検証済みのプルリクエストで機能ブランチを使用できるようになりますか?
123 git  bitbucket 

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