Gitを学ぶことができない開発者に対して私は何ができますか？
環境
私の8人のエンジニアのチームは現在、次の大きなことのために（Subversionから）Gitに移行しています。 Gitを入手するのが非常に難しいと感じている「経験豊富な」エンジニアが少数います。ユーザーマニュアル、トレーニングアクティビティ、ホワイトボードセッションを提供したにもかかわらず、同じように簡単な質問をされます。数日ですべてを拾った2人のジュニアコンサルタントがいて、それが問題に光を当てました。これはGitに限定されたパターンではありませんが、結果として表示されるようになりました。
質問
学べない、または学べないエンジニア、特に私たちがここにいる年功序列のレベルのスタッフには、特に好意を感じません。しかし、私はチームに成功して素晴らしい製品を作ってほしいです。私たちは一元化されたGit Flowモデルを使用しており、すべての新しい用語がそれらを混乱させているように感じます。
これらの従業員がGitを学ぶのを助けるために私ができることはありますか？
Sourcetreeは、チーム全体で使用されているクライアントです。
それらにおもちゃを与えなさい。
Gitは難しいです。特に、別のパラダイムでソース管理を行っている場合。初めてgitで作業しようとしたときに、ビルドを壊しました。とても妄想的で、すべてが完了するまでチェックインしたくありませんでした。フォルダにバージョンを隠していた。それから私は最終的にそれを乗り越えるために必要なものを理解しました：
安全な場所が必要でした。
それが発生すると、私は意図的に問題を引き起こしていたので、それらを修正する方法をすべて安全な場所で学ぶことができました。中断しても使用できるパターンを開発しましたが、それでも良好な状態に戻ります。やがて、人々はgitの助けを求めて私を訪ねてきました。時間をかけておもちゃで遊んだからです。
それらをディープエンドに投げ込むだけで、何とか浮かぶのはラッキーです。
平均的な開発者は、多くのgitの利点を必要としません。これは分散型ソース管理システムですが、ほとんどのチームは、プッシュアンドプルを行うための中央の正規リポジトリとともに使用します。
チームが必要とするコアコマンドは次のとおりです。
- リモートから変更をプルしてマージし、結果の競合を処理します（リベースの可能性があります）
- リモートへのコミットおよびプッシュコミット（またはレビュー後にステージングリポジトリ/ブランチにプッシュして変更をメインに取り込む）
- サポート：何か間違ったことをした後の混乱を修正。
より高度なユーザーが必要とするものは
- ローカルコミットを処理する
- 支店を管理する
Gitに慣れていない人やgitを使いたくない人のために、いくつかの簡単なエイリアスコマンドを設定してそれらを実行し、すべてが正しいことを確認します（新しいファイルの追加、削除されたファイルのリポジトリからの削除など）。
これらが十分に文書化され、まともな証拠であることを確認してください。
これは xkcdコミック の脈絡にあります。コマンドを覚えておいて、専門家に頼んだときに混乱しないようにしてください。
Git UIを使用してもらいます。
TortoiseSVNの経験がある場合、 TortoiseGit（Windowsのみ）はほぼ同じように動作します。それ以外の場合、 SourceTree（Windows + Mac）は素晴らしいです-開発者以外の複数のQAがあり、簡単に習得できましたSourceTreeのおかげでGitの複雑なタスク。
この回答は、上級プログラマーにgitに興味を持ってもらう方法を説明するものであり、gitを最も速く学ぶ方法についてではありません。そのために、優れた git book すばらしい、またはチュートリアル（=> Google）はいくつでも。この回答に適したリンクは Gitは純粋に機能的なデータ構造です または特に短い gitによるデータの保存方法 です。
私はこれについてかなり暗い見方をしていると思います。私はまさにあなたの立場にいます-私はgitオタクであり、チームをsvnから遠ざけようと変革したいと考えています。私の場合、自分自身の認識を積極的に変え、人々を受け入れることは、「幸せを強いられる」ことはできません。人々はコンピュータではなく、プログラムするのは信じられないほど難しいです。試してみて満足しています。私がやっていることと、仕事でやりたくないことをかなりやわらかく見せてくれました。
新しいものが関わったときにやる気を出し始める人もいれば、やる気が出てくる人もいます。これはgitとは関係ありませんが、gitの場合は特に、「svnが問題ないのに、なぜそれを使用する必要があるのか」という影響があります。大きな心理的障壁です。
また、実際にgitをグロッキングするには、抽象データ構造への強い関心が必要です。信じられないかもしれませんが、私の経験では、まったく興味がなく、単純な配列よりも複雑な要素に飽き飽きしているプログラマーがいます。あなたは彼らが彼らがしている仕事をしなければならないかどうかを前後に議論することができますが、それはそれが何であるかです。
人々がそれに興味がないなら、彼らはそれを理解しません。簡潔でシンプル。利害関係がないことが学校の成績が悪い主な理由であり、知性が欠落していないことを私は賭けます。
とは言っても、知識の積み上げに基づいて、私が適用するカリキュラムは次のようになります。それは私にはうまくいきませんでしたが、あなたはそれをあなた自身のものを転がすためのインスピレーションとして取るかもしれません。
GUI
次のアプローチでは、必ずしもアクション（git add in hello worldリポジトリ...）のGUIサポートは必要ありませんが、リポジトリを視覚化するためのGUIがあると非常に役立ちます。開始。どちらを使用するかを決定できない場合は、gitkを最後の手段として使用してください。皆さんが何らかのビジュアルエディターを使用している場合は、そのgit GUIコンポーネントを見つけてください。
（静的）データ構造が重要です
まず、内部データタイプ（ブロブ、ツリー、コミット、注釈付きタグ、この段階では最後は何も関係ない）とその構造について説明します。あなたはホワイトボード/鉛筆でそれを簡単に行うことができます。ツリーは変更することができないため、簡単に描くことができます。文字通り、常に何かを追加することができます。新しく作成されたローカルリポジトリで再生セッションを実行し、git cat-fileを使用して実際のオブジェクトを調べて、それらが実際に広告されているのと同じくらい簡単であることを示すことができます。
彼らがそれを理解するのを助けることができれば
- ...歴史には文字通り3種類のみのオブジェクトがあり、それらはすべて非常に単純で、ほとんど自明ではありません。
- ...ほとんどの
gitサブコマンドは、これらのオブジェクトを何らかの方法で "マッサージ"し、操作はほぼ自明です（基本的には1つしかありません：新しいコミットをどこかに追加します）。 - ...すべてが簡単にできますseen
lsとgit cat-fileを使用して、目の前に...
それから彼らは実際にリポジトリにあるものの精神的な翻訳があります。この時点で、先輩maysvnの内部は不可解な魔法であることを覚えておいてください（svnリポジトリ内のロックや、「再統合」ブランチなどで問題が発生したことはありませんか）。そしてこれmay少しやる気にさせるだけです。
特にsvnに慣れている人々の1つの問題は、1つのコミット（アクションではなくオブジェクト）が常にisディレクトリツリー全体であるという考えに慣れることです。 svnでは、人々は個々のファイルをコミットするために使用されます。それは根本的に異なるアプローチです。また、静的オブジェクトとアクションの両方に同じ「コミット」という用語が使用されているという事実も役に立ちません。
svnのもう1つの問題は、svnがツリーではなく線形履歴を使用することです。これもまた、まったく異なります。これが、これらの違いを指摘する時ですたくさん。
構造の観点から説明されたアクション
gitリポジトリがどのような部分で構成されているかを理解したら、次はそれらを表示しますexactly個々のgitサブコマンドがそれらに関してどのように機能するか。
私はadd、commitについて、ローカルの作業ディレクトリおよびステージと組み合わせて話しています（作業ディレクトリがステージング領域と同じではなく、同じではないことを彼らが理解していることを確認してください）リポジトリとして）。
これらのコマンドが単にツリーを成長させることを理解した場合（これも、この段階では、タイプので構成されます-ブロブ、ツリー、コミット、コミットだけではありません）、最初に行うことができますgit Pushおよびgit pull（早送りモードの場合！）は、gitが文字通りオブジェクトをプッシュしているだけであり、ハッシュがreally contentのみであることを示します。ハッシュ。ファイルシステムのコピーコマンドなどを使用して、このデータを簡単にコピーできます。
明らかに、これらのコマンドの必須ではないオプションから遠ざけてください。ここでgit add hello.txtについて話します。
枝
分岐はsvnの人々にとっては特に難しいことに注意してください。 svnモデルはmuch視覚化が簡単です。基本的に視覚化するものは何もないため、単純に表示できます。 gitモデルはそれほど多くありません。ブランチとタグはどこかを指し示す「付箋」にすぎず、静的で不変の履歴に関しては実際には「存在しない」ことを最初から認識していることを確認してください。
次に、簡単な例の後に例を実行して、実際に何ができるかを示します。あなた自身はgitに慣れているようですので、そこに動機を見つけるのに問題はないはずです。彼らが常にこれが木がどのように成長するかという観点からこれを見るようにしてください。
ダウンしている場合は、git pullが実際にgit fetch && git mergeであることを説明できます。すべてのリポジトリに実際に含まれる方法まったく同じオブジェクト（git fetchは、gitオブジェクトディレクトリ内でscpを使用してコンテンツをコピーするのとほとんど同じです）など。
おそらく、この時点までに彼らの関心を呼び覚ますために到達していない場合は、あなたも同様にあきらめることができますが、彼らがこれまでのところうまくいくことができれば、彼らはすべての精神的ツールを自由に利用できます。恐怖はもう関係していません。残り（gitワークフロー...）は、下り坂になるはずです。
最後の言葉
これは大変な努力のように思えますが、実際はそうです。これを「このプロジェクトに必要」として販売しないでください。「これは、個人の開発に役立ち、その後のすべてのやり取りであなたを助けます」。これにはlotの時間が必要であり、時間はお金です。経営陣がこれを受け入れていない場合、それだけの価値はないかもしれません。たぶん上司と話し合ってください。
理解できないように見える開発者に教えることをやめたいと思ったが、将来的には絶対にgitを使用する必要がある場合は、すべての対話をgitコマンドで置き換えることを検討してください。スクリプトまたはGUIを使用して、gitの詳細をすべて削除します。スクリプトにすべてのエラー制御などを注ぎ、それを機能させるようにしてください。
これを紹介したいと思います Joel Spolskyによるブログエントリ 。
これらのジュニア開発者がすぐにそれを取り上げる理由は、一般的にバージョン管理がどのように機能するかについて、事前に決められた概念がないか、少なくとも、それほど深く浸透したメンタルモデルではないためです。そのため、彼らは白紙の状態でやって来ます。より上級のプログラマーは、すでに知っている概念を適用しようとしている可能性が高く、その結果失敗しています。
これに加えて、私がそれを言いたくないほど。誰が実際にユーザーマニュアルを読むのですか？通常、基本的な使用法を説明するのは非常に苦手です。マニュアルの gitコミットページ を見て、その概念に慣れていない人に導入されている新しい用語やフレーズの数を検討してください。良い紹介がなければ、私はその場でGitを使用することをあきらめていたでしょう。
私の個人的なアドバイスは、コマンドの説明を始めることです：
- git add <ファイル>
- git commit
- git pull
- git push
- gitステータス
論理的にマージの競合について次に説明する必要があります。なぜなら、人々がコードをコミットする方法を学んだら、それが間違いなく最初の問題になるからです。
通常、人々が学習にもっと時間を費やす必要がある状況が発生します（元に戻す、タグ付け、競合のマージ、ブランチ、リベース、フック）が、必要になる前にこれをすべて説明しようとしても、問題を抱えている人を助けません流れ。
締めくくるだけです：私の個人的な経験から、新しいテクニック、概念、ツールを探すのにそれほど多くの時間を費やさない人もいるでしょう。これは、彼らが悪いプログラマや悪い人々であるという意味ではありませんが、彼らは通常、より狭いスキルセットを持っています。
最初にGit用語を取り上げていたときに、stackoverflowが非常に役立つことがわかりました。これらの質問のような質問は私にとって非常に役に立ちました（主に簡潔であるため）、それを使用した最初の数週間はタブで開いたままにしました。たぶん、いくつかの答えを太字で印刷しますか？特に最初の図。
「git commit」と「git push」の違いは何ですか？
「git pull」と「git fetch」の違いは何ですか？
また、トランクの視覚的表現は驚くほど便利であることがわかりましたが、そのトランクはSourceTreeですでにカバーしています。
余談ですが、このビットはおそらくコメントに含まれていますが、担当者がいません。私は質問で述べたジュニアコンサルタントの1人です。私が始める前に、ソースコントロールシステムが何であるかについていくつかの考えを持っていて、文字通りSVNを2回突くと、Gusdorは私に値する以上の信用を与えてくれました。チーム全体が高品質の専門的なGitトレーニング、おもちゃ、遊ぶ時間を持っていました。問題はグスドルの指示ではありません。ブックマークを付けて詳細を確認できるように、これに対する優れた代替ソリューションがあることを願っています。
SVNでソース管理を行う方法を学んだ場合、Gitは大きな再考です。そこで開発した習慣の多く（SVNのベストプラクティスであった可能性があります）は、gitを使用するときに誤った見方をします。これは主に、gitの分岐モデルが根本的に異なるためです。ブランチに対してfoldersを利用せず、分散ユースケースをより適切にサポートするように設計されているため、非線形にすることも可能です。 SVNの習慣を学び直して、gitを使用する方法を理解するには時間がかかります想定。
シンプルに始める
あなたはブランチ管理の標準としてGitflowを選択したと言います。これはあなたの最大の間違いとして私を襲います。
引用するには Gitflowは有害と見なされます ：
使用されるこれらのすべてのブランチは、GitFlowがそれらがどのように相互作用するかを記述する複雑なルールの精巧なセットを持つことを強います。無形の歴史と相まって、これらのルールは、GitFlowの日常的な使用を開発者にとって非常に困難にします。
このような複雑なルールのウェブを設定すると、どうなるでしょうか。そうです-人々は間違いを犯し、誤ってそれらを壊します。 GitFlowの場合、これは常に発生します。これは、私が観察した最も一般的な失敗の完全なリストではありません。これらは常に、時には毎日、しばしば同じ開発者によって繰り返されます。彼らは、ほとんどの場合、他のソフトウェア分野で非常に優れています。
開発者は、この標準の非常に複雑なことに圧倒されている可能性があります。私は個人的にはそれが何の利益もないと思います、そして上記の記事は同じ議論をします。しかし、それは別の議論です。客観的には、しかし、それは多くの手動管理を伴うかなり重い標準であり、多くの認知的努力を必要とします。
もっと簡単に始める必要があります。現在、分岐標準について心配する必要はありません。最初にgitの使用に慣れさせるに焦点を当てます。あなたは本当に始めるために本当にいくつかの操作が必要です：
- クローン
- 引く
- ブランチ
- マージ
- コミット
- 押す
- 方法に関する知識
.gitignore機能 - 多分タグ
はい、あなたの歴史は最初は少し乱雑に見えるかもしれません。これは大丈夫です。今は心配しないでください。入手するだけgitを使用。
徐々に知識を増やす
ここから、少し高度な使用法について徐々に説明することができます。
- 壮大なスタッシュコマンドを教える
- 先ほど行ったローカルコミットを破棄したいときに、リセットを使用する方法を説明します。
- 修正方法を教える
- 不必要なマージコミットを回避するためにリベースする方法を彼らに教える
- プッシュする前にコミットを整理するためにインタラクティブにリベースする方法を彼らに教える
- ハッシュ、タグ、ブランチからチェックアウトする方法を教えます
特に、彼らのコードをリポジトリに取り込むためのより明確な方法を彼らに示す機会を利用していることを確認するだけでなく、トレーニング活動でこれについても教えてください。何をすべきかわからないときにアプローチできるグルを1つか2つ持っていると、とても役に立ちます。 Slackのようなものがある場合は、専用のチャネルを作成し、そこで質問したり答えたりするように人々を促してください。
Then分岐標準を選択
会社の大部分がgitを使用する能力を身につけたら、then分岐標準を見ることができます。事前に1つを選択することは、いくつかの理由で非常に悪い考えです。
- ツールの十分な知識がないため、標準が会社のユースケースで適切に機能するかどうかを確認できません
- 彼らは代替標準を提供することができなくなります
- 彼らはツールと標準の両方を同時に学ぶ必要があります
- 選択した標準がgitを使用できる唯一の方法であると想定する人もいます
- 彼らは、標準が良いよりも害を及ぼしている稀なEdgeケースを特定することができません。
山からGitワークフローを引き継ぐべきではありません。あなたのチームはそれについてインプットを持ち、それがうまく行っているかどうかについてあなたにフィードバックを与えることができる必要があります。彼らはまだ基礎を理解していない場合、これを行うことはできません。 every 1人の開発者がこのような深い知識を持っている必要はありませんが、本当にそれを理解している複数の人が必要です。そして、大多数が少なくともgitで有能であることが必要です。そうすれば、彼らはRailsにある程度とどまるのに十分な知識を持っています。
以下に、チームが検討できるGitflowの代替案をいくつか示します。
それらとGitflowを見て、ユースケースと比較検討し、適切なものを選択してください。
本を購入する
正直に言って、私はあなたが説明する収容所に真っ直ぐ落ちた。 SourceSafeとClearCaseの背景から来ました。最初は、上司が何度かGitを歩いていたにもかかわらず、Gitは私には完全に不可解でした。
私を助けたのは、何が起こっているのかを明確に説明した本でしたが、さらに重要なのは、Gitが以前に使用したどのソース管理システムとも根本的に異なっているかです。今、私は他の選択肢よりもGitを好みます。
残念ながら、そのときに読んだ本を思い出すことはできませんが、どの本を読んだ（またはそれらを指し示した）ものでも、それがどのように異なっているか、どのように異なるマインドセットが必要であるかに焦点を当てていることを確認してください。
本の推薦のための最もよい推測は次のとおりです：
Scott ChaconによるPro Git（簡単にするためのAmazonリンク...好きな人から購入： https://www.Amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 ）
注：Gitのリファレンスブックを購入するしないでください。それはまったく役に立ちません。
私はgitを（TFSから）いるところに紹介するのを楽しんでいるので、あなたの質問は私にタイムリーです。
Peopleware では、本全体の基礎となる論文は次のとおりです。
私たちの仕事の主な問題はそれほどではありません技術的as社会学自然の中で。
私たちのものは技術的な問題ではないので、これを取り上げます。 git、少し鈍いですが、極端に愚かでない限り、おそらくあなたや私の上級開発者の能力を超えていません*。
技術的なマシンではなく、開発者の視点から見てみましょう。
あなたは彼らに、彼らが（おそらく）習得しているソース管理システムの使用を、彼らが持っていないものに止めるように求めています。 gitの専門家にgitの使用を中止してsvnに移動するよう依頼するのと少し似ていますか？ svnは正常に機能し、彼女が本当に気に入っている部分がありgitで本当に難しいのはsvn。
これがおそらく、後輩が上手に取り組んだ理由です。多分、彼らはsvnのこつをつかんでおらず、gitはそれを捨てるチャンスです^。
高齢者は機会費用に警戒しています-彼らがgitを学んだ場合、彼らはそうではありません：
- React/Angular/Swift/Blockchain/Kotlinの学習（彼らが感じている他のことすべきであるが学習している）。
- DIY /ホイットリング/セーリング/詩/グロッケンシュピール/他に何でも、実際にやりたい。
- 子供/親戚/友達/大切な人と過ごす時間。
この「大きな新しいこと」を提供する-期限、予算などがあります。おそらく彼らはそれについて心配しています。
「上記のすべてを実行する必要がありますが、すでにソース管理があるのに、なぜ
gitを使用する必要があるのですか？」
彼らが得意なものから、初めてのときに率直にぎこちなく、開発方法を完全に見直す必要がある別のものに切り替える理由を彼らに与えた理由は何ですか。 git機能の利点について説明しましたか？
プルリクエスト？細かいチェックイン？分散ソース？フォーク？
彼らはこれらの理由を持っていますか？一元化されたソース管理マインドセットを使用している場合、これらは大規模な構造変更です。技術的な変更だけでなく文化的な変更もあり、文化を変更するのがいかに難しいかを理解しています。
したがって、基本的には、開発者に何をするよう求めているのかを考え、それが正しい理由であることを確認してください。 svnは愚かで古くて誰も使用しなくなったからといってやりたいだけなのに、あなたのように思わず他人にその日を知らせたいという人に売り込むのは難しいです。 。チームとプロジェクトにとって意味のある用語でメリットを説明する必要があります。 gitに苦労する価値があると彼らに同意してもらうことができれば、彼らが技術を習得することを心配する必要はなく、設定したワークフローに同意するだけです。
幸運を。
*技術的なことに関しては、ほとんどの開発者が愚かではないことを覚えておくことを強くお勧めします。他の説明がなくなるまで理由としてそれを捨ててください。
^そして、より雇用しやすくなります。これは、特に私たちの業界で流行しているエイジズムを考えると、高齢者があまり考えないかもしれないことです。
私の経験から、一部の人はgitを理解しなくても快適に使用できます。彼らは基本的なチュートリアルを見つけ、基本的なコマンドを拾い上げて、彼らは行ってもいいです。それはおそらくあなたのジュニアコンサルタントがそれに合うところです。私はあなたが本当に数日でGitを学ぶことができるとは思わない！
他の人々はそれを行うことができません、彼らはgitが何をしているのかを理解する必要があり、それにはもっと時間がかかります。私はそのカテゴリーにいました。 .gitディレクトリの内容をいじってみると、とても役に立ちました。このとき、クリックが始まりました。また、技術リーダーとの一対一のセッションも役立ちました。
チュートリアルは1対1で行うことができます。これは、学習方法が異なり、さまざまな部分について混乱する可能性があるためです。1対1のセッションでは、見やすく、解決しやすくなっています。 gitがブランチを追跡する方法を理解していないという事実に本当に悩まされている場合は、.gitディレクトリの内容などを表示します。
これはソフトウェアエンジニアリングの問題ではなく、心理学の問題です。 Algorithms to Live By: The Computer Science of Humand Decisionsを参照したいと思います。その中で著者は探検/搾取のトレードオフのトピックに入ります。人間は通常、探査の段階を経てから、探求したものを利用（使用）する段階を経ます。一定の間隔で何かを最適に使用するためにこれが当てはまる理由には、いくつかの確かな数学的理論があります。
これは年齢や経験にも及びます。人間は自分の生活を時間の間隔として捉え、特定の探査段階の後、知識を使い始めるのが最適です。彼らは、年長の参加者に、彼らが好きな有名人、あるいは家族の誰かに会いたいかどうか尋ねられた研究を引用した。彼らは通常、家族を選びましたが、若い人は有名人を選びました。しかし、彼らが20歳未満かどうかをどのように判断するかを想像するように求められたとき、高齢者も日常的に有名人を選びました。これは、人々が彼らがすでに知っていることを利用することよりも探求から少ないと信じているとき、人々が彼らのソーシャルネットワークの構築を止めることを示唆しています。
あなたの上級エンジニアはおそらく年をとっています、彼らはおそらくいくつかのバージョン管理システムを経験しました。 SVNはおそらく、これまでに使用した中で最高のものです（少なくとも、私が使用した古いバージョン管理システムを見ると、SVNがそれらすべてに勝っています）。
彼らの最適な戦略は、SVNを利用することです。これは、彼らが調査を行い、これが現在利用している最良のものであることがわかったためです。
これは基本的な人間の心理学であり、あなたが戦っている何十万年もの進化の最適化です。
あなたはそれらを示す必要がありますa）彼らが彼らの前でどれだけのキャリアを持っているか、彼らが彼ら自身が見える間隔について異なる視点から考えるために準備するためにそしてb）彼らに尋ねる彼らが何をすべきか素晴らしく、SVNに欠けているものがあると思います。何百ものgitの利点をレイアウトできますが、SVNが最高である理由はすでに明らかになっています。あなたはその議論の鎧の隙間を見つけ、gitがこれらの問題を解決できるかどうかを確認する必要があります。そうすれば、彼らは納得するでしょう。
Gitを使用するためのツールやGUIを提供しないでください。それは物事を混乱させるだけです。 Gitはコマンドラインで実行するように考えられているので、これはおそらく学習する場所になるはずです。どのGUIにも独自の用語と特徴があり、単純なものに固執する場合があります。
次に、GitがSVNよりも優れている問題のいくつかを確認します。あなたのチームにそれを学ぶようにするには、彼らに動機付けをして、なぜgitが優れているのかを理解する必要があります。
- ネットワークに接続していないときにコミットする機能
- 自分のブランチを作って遊ぶ能力
- 相互に送信でき、引き続きトラックをマージできるパッチ
- 痛みのないチェリーピッキング。
- 変更のリベース
- git spliceでバグを見つける
ここ数年でSVNは進歩していると思いますが、SVNはかつては苦痛の世界を引き起こすものでした。開発者は、この新しいツールがいくつかの派手なものではなく、彼らの仕事に確かな利点を持っていることを知っている場合、彼らはそれを後回しにする可能性が高いかもしれません。
学ぶことは新しいことであり、混乱を招くほどの類似点がありますが、2017年のDCVSは、すべての開発者にとって非常に重要なスキルです。
心配しないように言う
Gitでは、作業がコミットされると、失うことはほとんど不可能です。あなたが簡単に失うことができる唯一の仕事は、まだコミットされていない仕事です。
方法を示すgit reflog機能します。彼らはそれを使用する方法を知っている必要はありません。彼らはそれがそこにあることを知る必要があるだけなので、何かがうまくいかなかった場合に彼らは彼らの仕事を取り戻す助けを得ることができます。
次に、この1つの単純なルールを彼らに印象づけてください。彼らはいつでも（リモートからでも）コミットを取り消すことができます。
GUIを使用しない
GUIを使用すると、すぐに開始できますが、Gitを実際に理解することはできません。さらに、Git GUIを使用している場合、コミットされた作業がnot「失うことはほぼ不可能」であることがわかりました。 GUIがマージ時にチェックリストを表示するなどの恐ろしいことを行ってから、ユーザーがアイテムのチェックを外した場合、警告とその記録なしで履歴からそのファイルを消去します。 GUIは、単にコマンドラインGitを学ぶよりもはるかに悪いです。
ペアプログラムコードのコミット
学習git add -A に続く git commit難しいことではありませんが、特にリモートに対してマージ（またはリベース）する場合は、支援が必要です。だれでもいつでもサポートを求めることを歓迎します。コマンドを入力してメモを取る間、待機します。時間の経過とともに、彼らは助けなしで対処できる状況の数を徐々に増やしていきます。
Gitはすでに安全です
上記の誰かが「安全な場所で遊ぶ」ことについて話しました。しかし、Git isは安全な場所です。仕事を失うのが簡単な通常の日常的なケースは2つだけです。
- コミットされていないコード
- GUIの使用
彼らが早い段階で頻繁にコミットすること、そしてしないでください GUIで間違ったパスを開始することを確認してください。そうすれば、他のソース管理よりもコードでGitを信頼できることがすぐにわかります。過去のシステム。
Gitless を参照することをお勧めします。これはgitのラッパーであり、基本的なワークフローを大幅に簡略化します（ステージング領域を気にする必要はありません。ブランチは独自のファイルの作業用コピーを保持します。git rebaseの単純な使用はgl Fuseで処理されます。 。）コラボレーションのために基盤となるgitリポジトリを維持している間、または異常なことを行う必要がある場合。また、メッセージは少し初心者にやさしいです。また、コマンドは、何らかの理由でgitlessを使用せずにシステムを使用する必要がある場合に、gitが踏み台として機能するのに十分近くなっています。
Gitのコマンドラインの基本的な使い方をドキュメント化してみました。私自身（PerforceとSource Safeの使用経験がある）と、古い「関連するフォルダをZipで圧縮する」というパラダイムを好むプログラマにとっては、どちらも混乱を招きました。不透明なツールが私の作業ディレクトリの内容を変更すること、そして特定の変更を私の作業ディレクトリに組み込むためにツールとしばしば議論する必要があることは気になることでした。
代わりに、2種類の間接参照を使用します。
私はGitKrakenを使用して、ブランチの視覚的な履歴と、コマンドラインステートメントを非表示にするGUIを提供しています。 GitKrakenは、「Origin」リモートリポジトリとgitが私のローカル作業ディレクトリと考えるものとの間の相互作用を処理します。
また、gitが私のローカル作業ディレクトリであると考えているものとは別の「実際の」ローカル作業ディレクトリも保持しています。私はこれら2つの作業ディレクトリを手動で同期します。これにより、作業ディレクトリの変更が意図したとおりであることがはるかに快適になります。
これらの従業員がGitを学ぶのを助けるために私ができることはありますか？
問題はGitであり、他の問題ではないと確信していますか？コメントから私が得たのは、経営陣が上級貢献者から賛同を得ることなく何かを変更することを決定し、その変更を後押しするように後輩に彼らに働きかけているということです。それは失敗の良い出発点のようです。 Gitの複雑さは問題ではありません。問題は、彼らが必要と感じていない変更が彼らに強制されることです。
したがって、Gitを教える方法に焦点を合わせないでください。ただし、足を引きずるスイッチの利点を理解していない場合に限ります。 Gitが現在抱えている問題の解決策であることを説明します。 Gitが彼らにまだ必要と感じていないものをどのように提供できるかではなく、Gitが他の人々の問題にソリューションを提供する方法ではなく、Gitが彼らが現在戦っている問題をどのように解決するかではありません。その後、Gitを教えることは問題ではありません。
多くの場合、ブランチの問題を解決するために会社でGitが使用されます。はい、それはSubversionよりもブランチの方が優れていますが、魔法はありません。
経験豊富な開発者が多くの企業で働いている可能性が非常に高いです。
- 経営陣は相反する要求を決定する意思がないため、ブランチを作成しました
- 構成スイッチではなく、顧客ごとにブランチを使用した。
- 経営陣はすべての顧客に同じバージョンのソフトウェアにアップグレードする意思がないため、顧客ごとにバグ修正ブランチを用意する必要があった
- 等。
したがって、ツールが分岐に適していると誰かが言うとすぐに、私の心は私に言います。
経営陣は会社の進路を決定するのではなく、101の異なるリリースのソフトウェアをテストする必要があることに加えて、自分の作業を101の異なるブランチにマージしなければならず、人生を無駄にしたいと思っています。
また、2人が同じファイルで同時に作業するという概念は「良い」ものであり、適切に実行されたプロジェクトを経験した人には受け入れられないため、Gitをそうするためのツールとして宣伝することは、経験を積む可能性が低いあなたが好きな開発者。
履歴の50％以上が論理的に公開されるべきではないマージであり、コードが開発者を離れるとすぐに意味がなくなるため、Gitで履歴を見るたびにコードが変更された理由を確認することは非常に困難です。機械。
しかし、私はどこかで働きたいです：
- 信頼されたサーバーでコンパイルされ、ユニットテストされるまで、コードは中央システムに入りません。
- コードレビューを追跡する簡単な方法があります
- 私が「取得」するときはいつでも、コードは常にコンパイルして動作します
- 誰かと競争したり、オフィスに迷い込んでビルドを壊したりせずに変更をプッシュできる場所。
実際の問題を解決し、Gitがソリューションの一部である場合は、経験豊富な開発者が賛同しますが、「マジックマージ」を実行できるクールなおもちゃであるという理由だけでGitを好きになると期待しないでください。
したがって、開発者がローカルGitから中央Gitにプッシュできる場所はどこでも間違っています。制御された自動プロセスは、開発者から変更を取得し、それらをテストした後、マージをチェックすることで中央Gitを更新し、すべてをフラット化します。長期的に関心のないブランチなど。
Kiln（ http://www.fogcreek.com/fogbugz/devhub ）または「プルリクエスト」ワークフローを使用するGitHubでも、経験豊富な開発者が満足できると期待しています、例えば低レベルから始めないでください、改善されたプロセスから始めてください。