22

私たちは 90 年代に VSS で立ち往生しているので (痛い)、上司に新しいソース管理システムとして Git を勧めたいのですが、ツールとサードパーティのサポートはまだ十分ですか?

具体的には、TortoiseSVN に似た GUI フロントエンド、まともなビジュアル差分/マージ サポート、および電子メール コミット通知、IDE やビルド システムなどのサード パーティからの一般的なサポートなどについて話しています。

これはプログラマーによって使用されますが、私たちのチームにはこの種のものが本当に必要です。コマンドライン アプリといくつかのオンライン チュートリアルだけで、すべての人が新しいツールや新しいソース管理パラダイム (分散型) に行き詰まったままにしたくありません。これは一歩後退だろう。

ではどう思いますか... Git の準備はできていますか? Git にはどのような適切なツールが存在し、どのサードパーティ開発アプリがそれをサポートしていますか?

編集:私の最初の質問はかなり曖昧だったので、Git の利用可能なツールとサードパーティのサポートのリストを具体的に尋ねるように更新しています。たぶん、コミュニティ wiki の投稿とそのリストを入手できるかもしれません。

また、「転覆を使用する」が適切な答えであるとは考えていません。オフライン編集以外にも、分散ソース管理システムを使用する理由は他にもあります。プライベート ブランチや安価なブランチもその 1 つです。

4

13 に答える 13

28

チームによります。あなたが技術に精通したチームの一員であるなら、git は素晴らしいものです (多くの場合、それ以上のものです)。しかし、コマンド ラインに慣れていない人がいる場合は、問題が発生する可能性があります ( tortoisegitはまだ初期段階にあり、私が遭遇した他のすべての GUI は、率直に言って、ひどいものです)。

あまり技術に詳しくない人 (デザイナー、上層部のマネージャーなど) とやり取りする場合は、Subversion のようなものを使用します。TortoiseSVNは素晴らしい (そしてかなり使いやすい) もので、svn は git が持っているすばらしい機能の 80% を持っています。

于 2009-01-04T03:45:09.877 に答える
25

はるかに簡単な売り込み (そして私が成功した売り込み) は、TortoiseSVN のような優れたツールをすべての人に提供する、中央の Subversion リポジトリをセットアップすることです。その後、開発者git-svnは完全な Git 環境を Subversion クライアントとして使用できます。

これは、特定の変更がコミットされているか、コミットされていないかを誰もが知っている中央リポジトリがまだあるため、非常にうまく機能します。次に、エッジでは、必要なツール (Git) を使用して仕事を完了できます。

于 2009-01-04T05:04:46.567 に答える
8

私の会社では git を使用していますが、ビジュアル ツールに対するあなたの要件に基づいて、私はノーと言います。tortoisegit が登場しますが、まだ完成していません。GitX や GitNub などのツールは OS X で優れていますが、説明しているすべてを完全にカバーしているわけではありません。

ただし、時間をかけてください。Git は非常に速いペースで進化しており、その成長のおかげでビジュアル ツールの需要が高まっています。

おそらく遭遇するであろう最大の問題は、パラダイムシフトです。これはマスターするのが最も簡単なことではなく、Git とそのより分散された (私はそれらを分散 SCM と呼ぶのはあまり好きではありませんが) 性質に慣れるにつれて、チームの一部の人にとってはイライラするでしょう。

そうは言っても、Git の使用は素晴らしいものであり、私の会社でもあります。別の会社が参加するのを楽しみにしています。

于 2009-01-04T03:50:15.593 に答える
3

gitのグラフィカル ツールに関して言えば、これまで使用した唯一の便利なツールは gitk (リビジョン ツリーを視覚化します) であり、過去半年間 git を使用してきました。 、TortoiseGitはまだ非常に初期段階にあり、解決すべき問題がいくつかあります。

職場では、3 つの異なる DVCS (つまり、git、mercurial (hg)、およびbazaar ) を評価しており、満員の夜に会社の他のメンバーにそれらを紹介しました。Mercurial は最も肯定的な反応を受けており、Tortoiseの亜種があります。

同じことをすることをお勧めします。git に代わるもの (mercurial や bazaar など) を提示できる人を見つけて、会社でDVCSについて一緒にプレゼンテーションを行ってください。上司に話すよりも、DVCS の素晴らしさを同僚に伝える方が重要です。したがって、彼らがそのようなツールに触れて、自分でそれを味わった方が、より教育的です.

私たちがそれを提示したとき、私たちは人々がバージョン管理をしていないことも想定していたので、checkin-checkout と commit-merge などの基本的な概念と、人々がバージョン管理を行う理由を簡単に説明しました。基本的にはバージョン管理に関する Eric Sink の記事に似ていましたが、最低限の必要事項だけを削除しました。

あなたは VSS から行くので (そして申し訳ありません)、 SVNを見たいと思うかもしれません。しかし、分散型アプローチと集中型アプローチの唯一の違いは、ピア ツー ピアのようなネットワークを介してコードを共有することの複雑さです。

于 2009-01-04T08:04:54.910 に答える
3

VSS から Subversion への移行は、すでに素晴らしいアップグレードになるでしょう。Subversion は、アトミック コミット、優れた GUI、IDE との統合、優れた Windows エクスペリエンス、変更セットの概念、信頼性の高いリポジトリなどの優れた機能を提供します。道具。

分散型 VCS に興味がある場合は、git、hg、bzr を検討する必要があります。Windows がサポートする限り、hg と bzr は git よりも進んでいます。ただし、メインの git への変更を元にマージする Windows 用の移植されたコマンド ライン バージョンの git (msysgit) があります。また、Git コミュニティは急速に成長しているため、Windows エクスペリエンスが向上することを期待しています。

Git は、サーバーが CVS / SVN であり、個々の開発者が git-svn を使用してローカルで作業し、ローカル ブランチを管理できるハイブリッド シナリオをサポートしています。この種の設定により、両方の長所が得られます。ただし、git-svn は、Perl SVN ライブラリに依存しているため、Windows では不安定です。このシナリオでは、開発者がブランチを共有するなど、git の優れた機能を使用するのは簡単ではありません。

プロジェクトがオープン ソースではないことを考えると、Subversion は必要なすべての機能を提供する可能性が高いと思います。Git が必要な Windows のユーザビリティ バーに達したら、SVN リポジトリを Git にインポートできます。

あなたの会社が分岐とマージに重きを置いていない限り、私は SVN を選びます。それ以外の場合は、DVCS を綿密に検討する必要があります。

私はオープン ソース プロジェクトに取り組んできました。リポジトリは CVS に保存され、その後 SVN に移行され、その後 Git に移行されました。すべてのステップが大幅なアップグレードでした。SVN から Git への移行の主な動機は、貢献者が自分のブランチを維持し、最新の状態に保ち、開発者にプッシュし、開発者が最小限の労力で簡単に適用できるようにすることでした。

于 2009-01-04T07:38:03.480 に答える
2

典型的な規模のほとんどの企業は、分散型ソース管理を本当に必要としていますか?

Git は、チェックインの有効性がメリットと信頼の網によって決定される、世界中の人々が非常に異なる時期にプロジェクトで共同作業しているオープン ソース プロジェクトに適しています。

たとえば、コミットに QA 分析または構成マネージャーの承認および/または文書化が必要な会社、またはバグ レポートのリビジョン番号と照合する必要がある会社では、Git などの分散制御は本当に意味がないと提出します。パラダイムシフトが保証されていないという意味で。既存の CM プロセスにまだうまく適合していない (社会問題)。既存のツール、サードパーティなどとうまく統合できないこと。また、Windows のサポートが不十分であること。

良くないというわけではありません。それがほとんどの企業環境に適したツールであると信じるには、私はかなり懐疑的です. 洞察力を得るために、他の回答のいくつかを楽しみにしています。

于 2009-01-04T06:34:19.147 に答える
2

Windows のデフォルトの git GUI はひどいもので、再スキャン ループでスタックする傾向があります。私は現在、コマンド ライン クライアントを使用していますが、vi を使用してログ エントリを作成できる限り、これで問題ないようです。github を使い始めたばかりです。これは問題ありませんが、ナビゲーションがお粗末です。

個人的には、ほとんどすべての作業で Subversion と Apache を使用しています。Subversion はうまく機能し、十分に文書化されており、セットアップが簡単で無料です。

于 2009-01-04T05:48:56.180 に答える
1

私が最初にGitに触れたとき、私の最初の反応は「私はそれをGitしない」でした。私は多くの強力なツールを見ましたが、それらはあまり直感的ではありませんでした。Gitの使用に慣れてきたとき、私が本当に気に入った機能は、すばやく安くて簡単なブランチだけであることに気付きました。

Gitに同梱されているGTKを含め、いくつかのグラフィカルフロントエンドを試しました。私はそれらがコマンドライン操作よりも混乱していることに気づきました。

会社がSubversionに慣れていて、DVCSに変更する必要がある場合は、Mercurialを試してください。Subversionのユーザーは、すぐにくつろげます。ただし、ブランチがどうあるべきかというMercurialのアイデアに頭を悩ませることができる人はほとんどいません。そもそも、足でDVCSを使用してどのような種類のシュートを行うか（ローカルでコミットし、プッシュする前に他の人にプッシュ/プルできることを除いて）メインリポジトリへ）。

私は毎日SubversionとMercurialを使用していますが、これは私のすべてのプロジェクトに非常に適しています。Gitの分岐機能と以前のリビジョンを編集する機能が必要でない限り、SubversionまたはHGが最善の策になると思います。私はGitをDVCSに初めて触れる人としてはお勧めしませんが、私の意見と経験だけをお勧めします。

于 2009-01-10T02:25:53.460 に答える
1

私は GIT の新参者です。数週間使用した後、コマンド ライン プロンプトのコツをつかめば、本当に素晴らしいと言わざるを得ません。

「Git の準備はできていますか?」という質問に答えるには => そうだと思います (コマンドラインの学習曲線を除く)。

あなたとあなたのチーム/会社は、「git の準備はできていますか?」と自問する必要があると思います。使い始めると、指先で明らかに多くのパワーが得られます。

git を学ぶための最初のステップは次のとおりです。

于 2009-01-04T08:52:15.157 に答える
1

Mercurial 用の TortoiseHg についての Spoike の言及に続いて、Bazaar 用の Windows スタンドアロン ダウンロードには、最近では TortoiseBzr が含まれていますが、実験的なものとしてマークされています。

かなり前に試してみたところ、不安定でしたが、それ以来大幅に改善されている可能性があります (特に、公式の Bazaar リリースにパッケージ化する意思がある場合)。

あなたが本当にカメのようなインターフェイスを備えた分散型バージョン管理を求めているなら、私は両方を試して、それらがどのように公正であるかを見ていきます。

E.

于 2009-01-05T00:43:47.293 に答える
0

もちろん、Git の準備はできていると思います。プロジェクトのスケジュールに時間があることを確認して、人々が切り替えたときにそれに慣れるようにしてください...

于 2009-01-18T18:33:58.467 に答える
0

ほとんどのサードパーティ アプリケーション (Eclipse 以外) 内で Git のサポートはまだありますか? 私が見たものの多くではありません。

Git が SVN を完全に置き換えることはおそらくないでしょう。それらは十分に異なっているため、しばらくの間はそれぞれの役割を持つ可能性があります。とにかく、全体的な質問に答えると、いいえ、ビジネスの世界でのゴールデンタイムの準備ができていません. 場合によっては (すべての場合ではないかもしれませんが) いつの日かになるかもしれませんが、もちろん、まだあまりにも新しいものです。賛同を得るためにプレゼンテーションを行うようにアドバイスされたという事実だけでも危険信号です。最近、開発者のところに行って SVN に移行したいと言ったとしても、すぐに理解できないのは岩の下に住んでいる人たちだけであり、誰が彼らのことを気にかけているのでしょうか?

また、新しいものほど良いとは限りません。この種のパラダイム シフトが改善として確認されるまでには時間がかかります。時間の経過に伴う Maven への反発を見てください。あなたの仕事と評判が危機に瀕している場合ではなく、実証済みのソリューションからすぐに飛び出してはいけません。少なくとも SVN のような製品では、新しいものではなく、時間の経過とともに確実に証明されているという事実があります。また、問題があったとしても、ほとんどの開発者からのデフォルトの回答であるため、推奨事項にあまり厳しく質問することはできません。業界標準に切り替えることは、新しい非標準のものに切り替えるよりも難しいアドバイスです。

あなたが聞きたかった答えではありませんが (あなたは既に決断を下しているようです)、メリット (ブランチは避けるべきものであり、奨励するものではありません) が本当にリスクを上回るかどうかを自問してください。

于 2010-04-10T07:16:48.787 に答える
0

GITに関する非常に優れたポッド キャストがあります。

于 2009-01-04T08:20:40.337 に答える