使用した後のgitの長所と短所は何ですか？
私は現在SVNを使用しており、過去にCVSとVSSを使用しました。私の本ではSVNが現在のお気に入りですが、gitについてはよく耳にします。 gitを使用したことのある人の中で、あなたの経験から得られる長所と短所は何ですか？
私はgitの経験がたくさんありませんが：
長所：
- 本当に速いです
- ローカルコミットロック
- 新しいリポジトリをすばやく開始する（構成などなし）
- githubは使いやすいです
（私は、ローカルリポジトリを持ち、パブリックリポジトリにプッシュできることを除いて、まだ分散側を「必要」とはしていません。）
短所：
- Windowsのサポートはまだ遅れていると思います-そして通常のコマンドプロンプトからそれを使用することはできません
- IDEとExplorerの統合の欠如
- 小豆の本の線に沿って 良い紹介文 を見つけるのに少し時間がかかりました。
- 変更されたファイルを「追加」すると、その時点でのみコンテンツが追加されます（したがって、コミットおよびのステージングとして表示される可能性があります）。別の
git addが必要です）把握するのに時間がかかりました
コマンドの数
Svnやhgなどの最新のVCSは素晴らしく便利なツールですが、gitは工作機械でいっぱいのショップです。これは、賛否両論を同時に説明します。 svnには30個のコマンドがありますが（「svnhelp」によると）、gitは130個のmanページを出荷し、それぞれが1つのコマンドを説明しています。この理由の1つは、gitが、ほとんどのユーザーがコマンドラインツールとして必要とする低レベルの関数を公開していることです。しかし、これらの低レベルのコマンドがなくても、gitは非常に強力なツールを数多く出荷しており、私が知っている他のVCSにはありません（ git-bisect 、 git-filter-branch 、 git-cherry または git-reset 例）。これらのツールを手元に置いておくと非常に役立ちますが、初心者が必要なコマンドと知っておく必要のあるコマンドとそうでないコマンドを理解するのは非常に困難です。
開発モデル
同様のトピックは、gitが非常に異なる操作モードをサポートするのに十分強力であるということです。これは、ベストプラクティスがgitに組み込まれていないため、実際には「ベストプラクティス」ドキュメントがないため、初心者にとっては困難です。だからあなたはあなたが
- マージを使用して、作業ディレクトリとの競合を回避してください
- アップストリームHEADにリベースされるプライベートブランチを使用する
- アップストリームブランチを使用する
- 定期的に合流するもの（トビウオ）
- 終了時にマージ
- 1つのプロジェクトメンテナ、ツリーメンテナ、サブシステムメンテナ、ドライバメンテナ、およびコントリビューターのツリーを使用し、各レベルで下のレベルからパッチをプルします（Linuxカーネル）
ローカルリポジトリがあるので、作業中のプロジェクトとはまったく異なる操作モードを使用して、変更セットをプッシュ/公開する前に調整することもできます。
変更のパス
視点によっては賛否両論と見なされるもう1つの点は、gitの操作は、集中型VCSの場合よりも複雑であり、他のほとんどの分散型VCSの場合はさらに複雑です。
集中型VCSを使用すると、通常はコミットを実行するだけで、行った変更はリポジトリに移動します。 gitでは、変更は最終的な宛先に到達する前に非常に多くのステップを経ることがあります。一般的な手順は次のとおりです（括弧内の一般的な手順ではありません）。
- 作業ディレクトリ（編集）
- インデックス別名ステージングエリア（git add）
- ローカルリポジトリ（git commit）
- （その他のローカルブランチ）（git rebase、git Cherry-pick、git merge）
- （サブメンテナーのリポジトリ）（git Push、git pull、mail）
- アップストリームリポジトリ（git Push、git pull、mail）
インデックスをスキップできるので、少なくとも2つのステップが必要ですが、通常はそれ以上のステップがあります。これには、何をしているのかをより深く理解し、より多くのコマンドを入力する必要があります。一方、これにより、これらの各ステップを制御できます。あなたはできる
- どのジャンク/ラインがコミットに入るのか、どれがコミットしないのかを決定します
- どのローカルブランチにどのパッチが必要かを決定します
- 公開するパッチを決定する
- パッチを公開する前に、パッチを作り直し、押しつぶし、修正し、分割し、並べ替えます
- 信頼できる人を自分で決めて、パッチを受け入れる
- プロジェクトの一部を信頼できる他のメンテナに委任します。
このすべての力と決定により、初心者がgitを使い始めるのが難しくなります。マスターすると、コードを大幅に制御できます。
書き込みアクセス
分散VCSの主な利点の1つは、コントリビューターがVCSの恩恵を受けるために書き込みアクセスを必要としないことです。読み取りアクセス権を持つすべての人は、リポジトリのクローンを作成し、必要に応じてブランチを作成し、プットパッチセットのスタックを開始できます。書き込みアクセスなしでcvsを操作するのは本当に苦痛です。gitを使用すると、パッチを取得する方法に大きな違いはありません。これは技術的な利点であるだけでなく、この初心者が本当に書き込みアクセスを取得する必要があるかどうかの複雑な議論を節約します。
プロ：
- 高速-非常に高速です。
- 新しいリポジトリの作成は、SVNと比較して非常に簡単です
- 完全なリポジトリは1つの.gitフォルダーに含まれています-コードのすべてのフォルダーに.SVNフォルダーが追加されるわけではありません（大したことではありませんが、私はそれが好きです）
- 分岐が簡単です
- GitHub！
短所：
- リポジトリの一部（1つのフォルダまたは1つのファイルなど）をチェックアウトできません
- 空のフォルダを追跡しません
- 悪いWindowsサポート（私はあまり気になりません-私はLinuxを使用しています）
- Git用の優れたGUIツールはまだ見つかりません（SVNにはKDESVNを使用しています）。 CLIに慣れている場合は、大きな問題ではありません。
多くの人がこれを否定しますが、ソースコード管理ツールの選択はあなたの働き方に影響を与えます。私は、Gitを発見するまで、Subversionで多くの作業を行っていました。私は主にSubversionでの分岐を避けました。それを避けられないときはいつでも、ローカルミラーを設定することを好みました（svkを使用）。 SubversionとGitの両方で分岐は簡単に実行できますが、マージ（およびリベース！）を楽しくするのはGitだけです。マージの時間に関しては、Subversionは常に王室の苦痛でした。
私がGitについて本当に気に入っている2番目のことは（すでに述べたすべての点を除いて）、次のコミットを保持するステージング領域である「インデックス」と、変更されたファイルの単一のチャンクのみを追加する可能性です。
Windowsのサポートはひどいので、私は Mercurial に移動しました。これも同様に優れたDVCSです。
DVCSの利点は、たとえば、オフィスのサーバーにリポジトリがあり、サイトで作業している場合に明らかになります。サーバーオフィスにアクセスせずにローカルでコミットできること（および必要に応じてこのロールバック）は素晴らしいことです！
長所： GitがXより優れている理由
Gitでの作業は、他のバージョン管理システムでの作業とは大きく異なります。
ローカルリポジトリを持つことは非常に重要です。これは、誰も邪魔することなく、バージョン管理システムの全機能を使用できることを意味します（これは、gitでは多くのことです）。プロジェクトに物議を醸す問題がある場合は、ブランチを作成し、パッチを積み上げて磨くことで、個人的に取り組むことができます。そうすれば、アイロンがけされたパッチセットで戻ってくることができます。ただし、「通常の操作」でも、パッチを公開する前にクリーンアップできればはるかに優れています。実際、「一日の終わり」のスナップショットだけでなく、正常なパッチがある場合は、デバッグがはるかに簡単になります。
より大きなパッチのセットをコミットする前に、通常、パッチを並べ替えて、新しいコードのバグ修正を直接パッチに押し込みます。したがって、パッチは私が間違いを犯したことがないように見えます。その後、私のプライベートブランチはHEADに基づいてリベースされ、プッシュされます。履歴が乱雑になるだけなので、通常はマージを使用しません。
要するに：それはあなたの歴史をきれいに保つことを可能にします。
これにより、作業に対する見方が大きく異なります。これにより、現在の状態を、単なるログではなく、意図的にそこに置いた履歴を作成する単一のパッチの追加として表示できます。パッチセットは、アプリケーションを構築するためのレンガであり、必要に応じて適切な場所に移動します。
Gitの前に使用した他のバージョン管理システムや、リベースとローカルブランチおよびコミットをサポートしていないバージョン管理システムに自発的に戻ることは決してありません。
ブランチの作成がデフォルトであり、追加のオプションではないため、gitでのマージははるかに簡単です。したがって、何かをマージする必要がある場合は、それをコミットしてから、2つのブランチ（既存のブランチと、最後のチェックイン用にgitが自動的に作成した新しいブランチ）をマージします。
また、gitを使用する場合は、常にリポジトリ全体を使用できます。オフラインでチェックインし、後でマージすることができます（マージははるかに簡単であるため）。
欠点は、GITがWindowsのUSBドライブではほとんど使用できないことです。 Windowsはこれらのキャッシュを無効にし、GITは何百万もの小さなファイルを処理します。また、IDEサポートはまだ不足しています。後者が本当に問題であるかどうかはわかりません。GITに付属のUIはかなりいいです。
また、既存のファイルを常に「追加」しなければならないこと[編集]と膨大な量の機能に100％満足しているわけではありません。初心者にとって、それらは圧倒的であり、特定のオプション/コマンドを使用する理由がよくわからないことがよくあります。つまり、CVSには20個のコマンドが付属しています。 GITには73が付属しており、それぞれに多くのオプションがあります（そして、それは配管コマンドを数えていません...）。
その他の考慮事項：
長所：
- 柔軟性：1つの真のワークフローを強制しません
- バージョン管理がマイナーなタスクになるほど高速
- 軽量のブランチ、簡単なマージおよびステージング領域により、パーソナライズされたワークフローが可能になります
- より強力な
- 非常にコンパクトなレポ
短所：
- 組み込みのアクセス制御はありません
- バイナリファイル用の弱いツール。リポジトリ内のバイナリファイルへの変更を圧縮せず、バイナリファイルを保存すると、Windowsでの行末の自動処理が妨げられます。
- より柔軟で強力なため、習得が難しい場合があります。常にCVS/SVNセマンティクスに従うとは限らず、ファイルを中心に編成されていません。
最新バージョンのGitは、Windowのコマンドプロンプトで直接機能します。これが私が使用する方法です。このプロセスは私にとって今ではかなり簡単です。
また、Gitを外付けハードドライブとジャンプドライブにインストールしています。新しいコンピューターでは、Gitのツールを含めるようにパスを一時的に設定するスクリプトを実行します。その後、開発を続けることができます！
すばらしい質問です。私はかなり長い間SVNを使用していて、かなり快適に感じています。しかし、さまざまなオープンソースプロジェクトからソースコードを取得するには、Gitを数回使用する必要がありました。それでも私はそれについて本当に学ぶために時間をかけていません。その価値はありますか？
また、Subversionとして通常のVCSよりも分散バージョン管理を使用する利点は何ですか？.
スキートにはそれらのほとんどがありますが、：
プロ：
- 分岐！ 1つのブランチで複数の処理を行うよりも、別々のブランチで機能のチャンクを処理し、それらをバージョン管理できる方がはるかに優れています。そして、分岐が好きだと決めたら、SVNと比較してgitがいかに簡単に分岐できるかを気に入る必要があります
長所：
- 上記のすべて
短所：
windowsでのautocrlfの奇妙な動作
ファイルまたはdirinsodeリポジトリを移動/名前変更してコミット履歴を保持することはできません（git mvファイルをリポジトリから削除し、名前を変更して再度リポジトリに追加するため、すべての履歴が失われます）