私のチームには、ソース管理システムに関する基本的なスキル以上の能力があると期待できますか？
私の会社は約3か月前にSubversionからGitに切り替えました。切り替えの数週間前に事前通知がありました。これまでにGit（または他のDVCS）を使用したことがないので、 Pro Git を読んで、少し時間をかけて自分のリポジトリをスピンアップして遊んだので、切り替えたときに、最小限の痛みで働き続けるため。現在、私はデフォルトで「Gitガイ」になっています。
いくつかの例外はありますが、私のチームのほとんどはまだGitがどのように機能するかを知りません。たとえば、彼らはまだブランチをソースコードの完全なコピーと考えており、リポジトリを複数のフォルダーに（ブランチごとに1つ）クローンすることさえしています。彼らは一般にGitを恐ろしいブラックボックスと見なします。
私たちの日常業務におけるソース管理の基本的な性質（Gitが提供するとんでもない量のパワーは言うまでもない）を考えると、私はそれで特定のレベルの習熟度を達成しない開発者は賠償責任。
私のチームは、Gitが内部でどのように機能するか、および最も基本的なプル/マージ/プッシュ操作を超えてそれをどのように使用するかについて少なくとも理解していることを期待する必要がありますか？それとも私はただ無から何かを作っているのですか？
プロフェッショナリズムは、たとえ彼らが新しくてなじみがない（または望まない）場合でも、開発者がチームの標準ツールに慣れるように自然に指示します。
しかし、あなたの投稿のいくつかのことは私に一時停止を与えます。
切り替えの数週間前に事前通知がありました。
何週間？ソース管理を入れ替えることは大変なことです。 monthsのような変化につながる通知があったはずです。
いくつかの例外はありますが、私のチームのほとんどはまだGitがどのように機能するのかわかりません。
それで、あなたの会社は、当時はほとんど理解されていなかったソース管理システムに切り替えましたか？
他のコンテキストがない限り、全体の動きはよく考え抜かれたようです（選択ではなく、動きです-私は巨大なgitファンです）。
私はGitを紹介してきましたが、当然抵抗がありました。これは新しいプロジェクト用だったので、現在2つのリポジトリを維持しています。
問題の一部は、使用していたSCMが機能しても、別のSCMに切り替えることのメリットを人々が理解できないことです。私たちがチームと一緒に1時間のセッションを数時間行ったときに、ユースケース私たちのプロジェクトからとGitがどのようにそれをより簡単にしたかを示すのに役立ちました。たとえば、私たちを助けたもの：
- 実験を促進するための地方支部
- バグを簡単に追跡できるGit bisect
- 他のユーザーに割り込むことなく頻繁にコミットする
- ブランチ間の高速切り替え
これらはそれぞれ、以前のSCMで遭遇した問題を解決したので、人々はGitをより高く評価することができました。
もう1つは、ほとんどの人がそうしないため、人々がそれについて本を読んだりすることを期待できないことです。多分彼らは仕事を成し遂げる必要がある、他の責任がある、またはいくつもの理由がある。
したがって、「Gitエキスパート」として、座って、人々がそれをできるだけ簡単に使用できるようにする必要があります。彼らはSCMシステムをいじるのではなく、コードを書くことを望んでいます。
GitのCLIは暗号化されており、些細な問題が（あなたと私には）人々の作業を妨げます。これが私たちのチームで起こったことです（これらはかなり有能な開発者です）：
- WindowsでSSHを使用したGitが一般的な問題でした。
- 人々はプルをマージしますが、プッシュをプッシュしません。したがって、グラフは非常に混乱する混乱になります
- Windowsでのパフォーマンスの問題により「git status」が15秒かかる
- 新しいブランチをプルする方法を理解できませんでした。彼らは「git checkout -b」を実行し、作業していたものから分岐します
- EclipseのEGitには、圧倒的なメニューがありました。結局、最初はコマンドラインを使うようにみんなに言った
- 前の項目に基づいて、git mergetoolのマージと設定
- 「git add」と「git commit」および「git Push」の違いについて混乱しています。
私たちはまだある程度の抵抗を得ますが、人々は間違いなくその利点を見ることができます。ガイダンスのために数人のGit担当者がいて、喜んで手助けすることが不可欠です。また、私はリセット/リベース/-修正/などのクールなことを教えるのを避けます。ほとんどの人はSVNのようにGitを使用するため、必要に応じてGitを発見させることをお勧めします。
Proficient vs. Git-mania
基本的な熟練度などの用語は、人によって意味が異なる場合があります。多くの人がgit-maniaを持っているようです（それに何か問題があるわけではありません）。私たちの多くは、ソース管理に関する私たち自身や他の人々のずさんなことに本当にひどくやられています。
なぜそれが重要なのか（とても重要）
誤用は1人だけでなくチーム全体の速度を低下させる可能性があるため、ソース管理ツールは重要です。 Gitの誤用は、SVN、CVS、およびその他のシステムの誤用よりも問題が少ないはずです。歴史的に、ファイルをロックするシステムの不注意な使用は特に問題があり、企業は個別のビルドチームを雇ったため、誰かが問題に直面したとき、ソース管理以外にほとんど何もせず、リポジトリの傷を治すことができる流暢な専門家がいました。これは、gitの背後にある情熱の一部を部分的に説明しています。
基本的な能力はどのようなものですか？
具体的な基準は次のとおりです。
ドキュメントを参照せずに：
- ファイルの追加、変更のコミット、更新のプッシュとプルができます。
- ステータスと改訂アクティビティを表示できます。
- エラーを発生させることなく、すばやく分岐してマージできます。
- チェックアウトを適切に使用できます。
- グループのコメント基準を満たすコミットコメントを作成します。
- 作業コピーとアーカイブの違いを比較します。
ドキュメント付き：
- ローカルリポジトリのユーザーと認証情報を追加します。
- ローカルリポジトリを初期化します。
- リモートリポジトリを管理します。
- 無視されたファイルを構成し、PKI公開/秘密鍵のペアを生成します。
- ファイルを移動および削除します。
- Bisectを使用して、特定のバグを引き起こした変更を見つけます。
Gitのしっかりとしたメンタルモデルと管理対象のコードは、間違いを防ぐために重要です。
高度な熟練度/専門知識のために何を追加しますか？
流暢な使用は、開発者およびおそらくチームの他のメンバーにとって不可欠です。 Gitのようなツールはオーバーヘッドがあり、ほぼ自動化できるレベルまで学習する必要があります。年間数千回繰り返されるgitコマンドを使用することで生じる時間と注意散漫を最小限に抑えることは、高い価値があります。
パワーユーザーであり、ほぼすべてのコマンドをほぼすべてのオプションで使用するチームのメンバーが常に存在します。私の推奨は、チームメンバーは、学習のROIがプロジェクトで他の何かを行う価値を下回るまでgit（および他のツール）を学習し続けることを奨励されることです。主な制限は、現在の割り当てられたバーンダウンアイテムと歩調を合わせることです。スプリント。
GITは仕事をするための公正なツールであり、その最大の問題の1つは、多くのGITエバンジェリストが、すべてのGITユーザーがそれがどのように機能するかについての細かい点を理解するボンネットの専門家になることを期待していることです。これがGITの最大の弱点です。これを使用するには、GITの仕組みを知る必要があります。 GITにはレシピはありません。GITの専門家であるか、GITを使用しないことが求められます。すべての開発者がGITの第一人者になりたいとは限らないため、組織が「goto」GITグル（または2つ）を必要とするPro-GITを読むのは素晴らしいことです。
チームはGITの使用方法を知る必要があります（実際には、ワークフローで使用するためにGITの一部を使用する方法だけを知っていれば十分です）。GITのしくみについて知る必要はありません。すべての開発者が、使用するすべてのツールについてあらゆる詳細を知っていることを期待することは有害です。ワークフローをサポートするレシピ本がない場合は、GITをデプロイしておらず、GITを開発者にダンプしています。
Gitを機能させる方法を知っている限り、GITがどのように機能するかをサルに与えません。
はい。
「会社」がどのツールを決定したかに関係なく、開発チームはツールを適切に使用する方法を学ぶためにある程度の時間を費やす必要があります。ツールを恐れたり、知らなかったりする開発者の集団ほど、生産性を損なうものはありません。彼らがそれを間違って使用したり、それに反対して取り組んだりすると、問題が発生し、男の人として、あなたは混乱を片付ける義務があります。
Gitは多くの人にとって難しい移行であるため、必須の着席トレーニングセッションが必要になる場合があります。これは、人々が抱えている多くの問題を解決するのに役立ちます。
私は個人的な設定でのみGitを使用しており、プロの設定ではありません。Gitが持つパワーと、より分散化されたソース管理のアイデアは好きですが、大きな問題があります。 Gitはリークの多い抽象化を備えており、単純なこと（たとえば、git add、git commit、次にgit Push）を実行するには複数のコマンドが必要です。また、一部のドキュメントには、rebaseコマンドの説明のように、不足している、または混乱しているものがあります...「更新されたアップストリームヘッドへのフォワードポートローカルコミット」。私はそれが何を意味するのかわかりません、そして私はあなたがコミットを動かしてそれで歴史を書き直すことができることを今知っていますが（別の厄介なこと...なぜあなたはこれをすることを許されるべきなのでしょうか？説明。私はあなたのチームの一部を読んでいると思います、そしてあなたが提供するいくつかのより多くのトレーニングは整然としていると思います。
トレーニングと理解は最小限の要件です。担当者は、チームがそれをどのように使用するかについての計画があったことを確認しておく必要があります。ガイドラインがなければ、新しいプログラミング言語を採用することはできません。確立された道路のルールが組み込まれている場合、ドライバーのトレーニングははるかに効果的です。
番号;私は以下を期待するのが妥当だと思います：
- 手を使わずに日常のタスク（コミット、プッシュ、プル、ブランチ、マージ、バイセクトなど）を実行します。
- 繰り返しの指示なしに非定型的なタスクを実行します。 （何度か繰り返してもかまいません。名前が実際に表示される前に、2〜3回会う必要があります。）
彼らが＃1を実行できない場合、ロールアウトのトレーニング部分はおそらく不十分でした。彼らが＃2を実行できない場合は、まず怒りすぎる前に、十分に明確に説明していることを確認してください。