状況

8人のエンジニアからなる私のチームは、次の大きな仕事のために（Subversionから）Gitに移行しています。Gitを手に入れるのが非常に難しいと感じている「経験豊富な」エンジニアが少数います。ユーザーマニュアル、トレーニング活動、ホワイトボードセッションを提供したにもかかわらず、私は同じ些細な質問をしました。数日のうちにすべてを拾い上げた2人のジュニアコンサルタントがいましたが、それが問題を明らかにしました。これはGitに限定されたパターンではありませんが、結果として目に見えるようになりました。

質問

学べない/学べないエンジニア、特にここにいる年功序列レベルのスタッフには特に好意的ではありません。ただし、チームが成功し、優れた製品を構築することを望んでいます。中央集中型のGit Flowモデルを使用していますが、すべての新しい用語がそれらを困惑させているように感じます。

これらの従業員がGitを学ぶのを支援するためにできることはありますか？

Sourcetreeは、チーム全体で使用されているクライアントです。

それらにおもちゃを与えます。

Gitは難しいです。特に、別のパラダイムでソース管理を行っている場合。初めてgitを使用しようとしたときに、ビルドを中断しました。私はとても妄想的になり、すべてが完了するまでチェックインしたくありませんでした。フォルダーにバージョンを隠していました。それから私はついにそれを乗り越えるために必要なものを見つけました：

プレイするには安全な場所が必要でした。

それができたら、意図的に問題を引き起こしていたので、すべてを安全な場所で修正する方法を学ぶことができました。中断しても使用できるパターンを開発し、それでも良好な状態に戻りました。やがて、人々はgitの助けを求めて私のところにやって来ました。それは、おもちゃで遊ぶのに時間がかかったからです。

奥深くに投げ込むだけなら、なんとか浮かぶことができます。

平均的な開発者は、多くのgitのグッズを必要としません。これは分散ソース管理システムですが、ほとんどのチームは、中央の標準的なレポジトリでそれを使用してプッシュおよびプルします。

チームが必要とするコアコマンドは次のとおりです。

• 変更をリモートからプルおよびマージし、結果の競合を処理します（潜在的にリベース）
• コミットし、コミットをリモートにプッシュします（または、ステージングリポジトリ/ブランチにプッシュして、レビュー後に変更をメインにプルします）
• サポート：何か間違ったことをした後の混乱を修正します。

より上級のユーザーが必要とするものは

• ローカルコミットを処理する
• 支店を管理する

gitに不慣れな人や、それを学びたくない人のために、いくつかの簡単なエイリアスコマンドを設定してそれらを実行し、すべてが正しいことを確認します（新しいファイルの追加、削除されたファイルのレポジトリからの削除など）

これらが十分に文書化されており、まともな証拠であることを確認してください。

これはxkcd comicの静脈であり、コマンドを暗記し、専門家に尋ねたときに物事があまりにもめちゃくちゃにならないことを願っています。

Git UIを使用してもらいます。

TortoiseSVNの経験がある場合、TortoiseGit （Windowsのみ）はほぼ同じように動作します。そうでなければ、SourceTree （Windows + Mac）は素晴らしいです-SourceTreeのおかげで、Gitで複雑なタスクを簡単にマスターできる複数の開発者以外のQAがいます。

この回答は、最速のgit方法を学ぶ方法ではなく、上級プログラマーに興味を持たせる方法に対処しようとしていますgit-そのためには、優れたgitブックは素晴らしい、または多くのチュートリアル（=> Google）です。この回答に適したリンクは、Gitが純粋に機能的なデータ構造であるか、特にgitがデータを保存する方法が短いことです。

私はこれについてかなり暗い見方をしているのではないかと心配しています。私はまさにあなたの靴を履いています-私はgitオタクで、チームを変革したいと思っていましたsvn。私の場合、それは私自身の認識を積極的に変え、人々を「幸福を強いる」ことはできないということを積極的に変えさせてくれました。人々はコンピューターではありません。プログラムするのは非常に難しいです。試してみたことにまだ満足しています。それは、私がやっていることと私がやりたくないことをやさしい方法で示しています。

新しいものが巻き込まれたときにやる気が出始める人もいれば、やる気のない人もいます。これはとは何の関係もありませんgitが、git具体的svnには、「うまくいけば、なぜそれを使用すべきなのか」という効果が常にあります。これは大きな心理的障壁です。

また、実際にグロッキングをgit行うには、抽象データ構造に強い関心が必要です。信じられないように聞こえるかもしれませんが、私の経験では、まったく関心がなく、単純な配列よりも複雑な要素に飽き飽きしているプログラマーがいます。あなたは彼らが彼らがしている仕事をしているべきかどうかを議論することができますが、それはそうです。

人々がそれに興味がなければ、彼らはそれを理解しません。簡潔でシンプル。学校の成績が悪いのは、無関心が知能を欠いていないことの主な理由だと思います。

とはいえ、ここでは、下から上への知識の蓄積に基づいて、私が適用するカリキュラムを作成します。私には役に立たなかったが、あなたはそれをインスピレーションとして自分自身を転がすと考えるかもしれない。

GUI

次のアプローチでは、必ずしもアクションのGUIサポート（git addhello worldリポジトリ内）が必要ではありませんが、リポジトリを視覚化するためのGUIを最初から用意しておくと非常に役立ちます。どちらを使用するか決められない場合はgitk、最後の手段としてください。皆さんが何らかのビジュアルエディターを使用している場合は、gitGUIコンポーネントを見つけてください。

（静的）データ構造が重要

まず、内部データ型（3つと1つだけです：ブロブ、ツリー、コミット、注釈付きタグ、この段階では最後はまったく関係ありません）とその構造について説明します。ホワイトボード/鉛筆で簡単にできます。ツリーは変更することはできないため、簡単に描画できます。文字通り、いつでも追加することができます。新しく作成したローカルリポジトリでプレイセッションを実行git cat-fileし、実際のオブジェクトを調べて、実際に宣伝されているように些細なものであることを示すことができます。

彼らがそれを理解するのを助けることができれば

• ...歴史には文字通り3種類のオブジェクトしかありませんが、それらはすべて非常にシンプルで、ほとんど些細なものであり、
• ...ほとんどのgitサブコマンドは、これらのオブジェクトを何らかの方法で「マッサージ」し、ほとんど取るに足らない操作（基本的には、1つだけ：新しいコミットをどこかに追加する）であり、
• ...すべてが容易にすることができます見て右とあなたの目の前にlsしてgit cat-file...

その後、リポジトリに実際にあるものの精神的な翻訳があります。この時点で、senioursが可能の内部がいることを覚えておいてくださいsvn（または「再統合」の枝や、と？これまでSVNリポジトリ内のロックに問題がありました）難解な魔法があり、これがあり、彼らに少しのやる気を引き出すだけ。

一つの問題は、特異的に使用人とsvn、常に1が（オブジェクトではなく、行動を）犯すという考えに慣れることですされ、全体のディレクトリツリー。ではsvn、個々のファイルをコミットするために人々が使用されます。これは根本的に異なるアプローチです。ああ、「コミット」という同じ用語が静的オブジェクトとアクションの両方に使用されているという事実も役に立たない。

他の問題は、ツリーではなく線形履歴svnをsvn使用することです。これもまた、大きく異なります。だから、今こそこれらの違いを多く指摘する時です。

構造の観点から説明されたアクション

gitリポジトリがどの部分から作られているかを理解したら、個々のサブコマンドがそれらの観点から何をするかを正確に示しますgit。

私は話していますadd、commitローカルの作業ディレクトリとステージ（彼らは作業ディレクトリがリポジトリと同じではありませんステージング領域と同じではないことを理解しておいてください）と一緒に、。

これらのコマンドが単純にツリーを成長させることを理解したら（この段階でも、ブロブ、ツリー、コミット、コミットだけでなく3つのタイプで構成されます）、最初git pushにgit pull（早送りモードで！ ）git文字通りオブジェクトをプッシュするだけであり、ハッシュは実際にはコンテンツハッシュのみであり、ファイルシステムコピーコマンドなどで簡単にコピーできることを示します。

明らかに、これらのコマンドの重要ではないオプションから遠ざけてgit add hello.txtください。

枝

分岐はsvn完全に異なるため、人々にとって特に難しいことに注意してください。svnモデルは非常に基本的に可視化することは何もないとして、視覚化しやすい-それは平面図です。gitモデルはあまりありません。ブランチとタグが単にどこかを指している「付箋」であり、静的で不変の履歴に関しては「存在しない」ことを最初から認識していることを確認してください。

次に、簡単な例の後に例を実行して、実際に何ができるかを示します。あなた自身が慣れているように見えるのでgit、そこに動機を見つけるのに問題はないはずです。ツリーがどのように成長するかという観点から、常にこれを見るようにしてください。

それらがダウンしている場合git pullは、実際にどのように説明することができますgit fetch && git merge。すべてのリポジトリが実際にまったく同じオブジェクトをどのように含んでいるか（gitオブジェクトディレクトリ内でのgit fetchコピーとほぼ同じですscp）など。

おそらく、この時間までに彼らの興味を起こさせるために到達していないなら、あなたはちょうどあきらめることができますが、彼らがこれまでのところうまくいくなら、彼らは自由にすべての精神的なツールを持っているので、ほとんどありません恐れはもう関係します。残り（gitワークフロー...）は、それから下り坂になるはずです。

最後の言葉

これは多くの努力のように聞こえますが、本当にそうです。これを「このプロジェクトに必要だ」と売るのではなく、「個人的に開発するのに役立ち、今後のやり取りのすべてに役立ちます」。これには多くの時間が必要であり、時は金なりです。これについて経営陣が受け入れていない場合、それだけの価値がないかもしれません。おそらく上司と話し合う必要があります。

一見理解できない開発者に教えることを断念したいgitが、今後絶対に使用しなければならない場合は、すべての相互作用をgitクックアップされたスクリプトまたはすべてのgit詳細を取り除いたGUIに置き換えることを検討してください。スクリプトにすべてのエラー制御などを注ぎ、それが機能するようにします。

Joel Spolskyによるこのブログエントリを参照したいと思います。

これらのジュニア開発者がすぐにそれを取り上げる理由は、一般にバージョン管理がどのように機能するかについての所定の概念を持たないか、少なくとも深く染み込んだ精神モデルがないためです。そのようなものとして、彼らはきれいな状態で入ります。あなたの上級プログラマーは、すでに知っている概念を適用しようとしている可能性が高く、その結果失敗しています。

これに加えて、私はそれを言うのが好きではありません。実際にユーザーマニュアルを読むのは誰ですか？通常、彼らは基本的な使い方を説明するのが非常に苦手です。マニュアルのgit commitページを見て、この概念に慣れていない人に新しい用語やフレーズがいくつ導入されているかを考えてください。良い紹介がなければ、Gitの使用をあきらめたでしょう。

私の個人的なアドバイスは、コマンドの説明を開始することです。

• git add <ファイル>
• git commit
• git pull
• git push
• git status

次に、論理的にマージの競合について説明する必要があります。コードをコミットする方法を学ぶと、それが間違いなく最初の問題になるからです。

通常、学習にもっと時間をかける必要がある状況（リバート、タグ、マージの競合、ブランチ、リベース、フック）が必要になる前に、これらすべてを説明しようとしても、問題を抱えている人は助けにはなりません流れ。

まとめます：私の個人的な経験から、一部の人々は単に新しいテクニック、概念、またはツールを探索するのにそれほど時間を費やさず、通常、遅いペースで紹介するものを拾う傾向があります。これは、彼らが悪いプログラマーや悪い人々であることを意味するものではありませんが、彼らは通常、より狭いスキルセットを持っています。

SVNでソース管理を行う方法を学んだ場合、Gitは大きな再考です。そこで開発した多くの習慣（SVNのベストプラクティスであった可能性があります）は、gitを使用するときに誤った方向に導きます。これは主に、gitの分岐モデルが根本的に異なるためです。ブランチのフォルダーを活用しません。また、分散ユースケースをより適切にサポートするように設計されているため、非線形にすることも可能です。これは、SVNの習慣を捨て去る、あなたがしているかを理解するためにいくつかの時間がかかるはずのgitを使用することを。

シンプルに始める

ブランチ管理の標準としてGitflowを選択したと言います。これはあなたの最大の間違いだと思います。

Gitflowが有害と見なされることを引用するには：

使用されるこれらのすべてのブランチは、GitFlowに、それらがどのように相互作用するかを記述する複雑なルールの精巧なセットを持たせます。これらのルールは、無形の歴史と相まって、開発者にとってGitFlowの日常的な使用を非常に難しくしています。

そのような複雑なルールのウェブを設定するたびに何が起こるか推測できますか？そうです-人々は間違いを犯し、偶然それらを壊します。GitFlowの場合、これは常に発生します。ここに、私が観察した最も一般的な失敗の完全なリストではありません。これらは、同じ開発者によって頻繁に何度も何度も何度も何度も繰り返されます。ほとんどの場合、他のソフトウェア分野で非常に有能です。

開発者は、この標準の非常に複雑さに圧倒される可能性があります。私は個人的にそれが利益をもたらすとは思わない、そして上記の記事は同じ議論をする。しかし、それは別の議論です。客観的には、しかし、それは多くの手動管理を伴うかなり重い標準であり、多くの認知的努力を必要とします。

もっとシンプルに始める必要があります。現在、分岐標準について心配する必要はありません。最初にgitを使用することに慣れるようにしてください。実際に開始するのに必要な操作はわずかです。

• クローン
• 引く
• ブランチ
• マージ
• コミット
• 押す
• 方法についての知識を.gitignore作品
• たぶんタグ

はい、あなたの歴史は最初は少し乱雑に見えるかもしれません。大丈夫です。心配しないでください。gitを使用して取得してください。

徐々に知識を増やす

ここから、少し高度な使用法について徐々に教育することができます。

• それらに壮大な隠しコマンドを教える
• 作成したばかりのローカルコミットを破棄したいときにリセットを使用する方法を教えます。
• 修正方法を教える
• 不要なマージコミットを避けるためにリベースする方法を教える
• プッシュする前にコミットを整理するためにインタラクティブにリベースする方法を教えます
• ハッシュ、タグ、ブランチからチェックアウトする方法を教える

特に、リポジトリにコードを取り込むよりクリーンな方法を示す機会を活用するようにしてください。また、トレーニングアクティビティやあなたに何があるかを教えてください。何をすべきかわからないときに人々が近づくことができる教祖または2人を持つことも、多くの助けになります。Slackのようなものがある場合は、専用のチャネルを作成し、そこで質問や回答をするように人々を促してください。

次に、分岐標準を選択します

あなたがすべてではgitを使用して有能な会社のほとんどを持っていたら、その後、あなたは、分岐基準で見ることができます。前もって1つを選択するのは、いくつかの理由で本当に悪い考えです。

• 標準が会社のユースケースに適しているかどうかを判断するのに十分なツールの知識がない
• 彼らは代替規格を提供することはできません
• ツールと標準の両方を同時に学ぶ必要があります
• 一部のユーザーは、選択した標準がgitを使用できる唯一の方法であると想定します。
• 彼らは、標準が良いことよりも悪いことをしているまれなエッジケースを特定することはできません

山からGitワークフローを引き継ぐべきではありません。あなたのチームはそれについての意見を持ち、それがうまくいくかどうかについてフィードバックを与えることができる必要があります。まだ基礎を理解していなければ、彼らはこれを行うことができません。すべての開発者がこのような深い知識を持っている必要はありませんが、実際にそれを取得する複数の開発者が必要です。そして、少なくとも大部分がgitの能力を備えている必要があります。そうすれば、彼らはある程度レールにとどまるのに十分なことを知っています。

以下は、チームが検討できるGitflowの代替案です。

• OneFlow
• 機能ブランチのワークフロー
• 集中型ワークフロー

それらとGitflowを見て、ユースケースと比較検討し、適切なものを選択してください。

Gitの用語を最初に取り上げたときに、stackoverflowは非常に役立ちました。これらのような質問は私にとって本当に役に立ちました（主に簡潔さのため）。使用した最初の数週間はタブで開いたままにしました。答えをいくつか太字で印刷することもできますか？特に最初の図。

「git commit」と「git push」の違いは何ですか？

「git pull」と「git fetch」の違いは何ですか？

また、トランクの視覚的表現が非常に便利であることがわかりましたが、すでにその1つをSourceTreeでカバーしています。

_{脇に、このビットはおそらくコメントに属しますが、私は担当者を欠いています：私は質問で言及されたジュニアコンサルタントの一人です。始める前に、ソース管理システムとは何かを考えていたので、SVNを文字通り2回突いてみました。Gusdorは私にふさわしい以上のクレジットをくれました。チーム全体に、質の高い専門のGitトレーニング、おもちゃ、そして遊ぶ時間がありました。問題は、ガスドールの指示ではありません。これに代わる優れた解決策があればいいので、それを一生懸命ブックマークして詳細を学んでください。}

本を買う

正直なところ、私はあなたが説明するキャンプに真っ直ぐに落ちました。SourceSafeとClearCaseのバックグラウンドから来ました。上司が何度か歩いたにもかかわらず、最初はGitが完全に理解できませんでした。

私を助けたのは、何が起こっているのかを明確に説明した本でしたが、もっと重要なのは、Gitが以前に使用したどのソース管理システムとも根本的に異なることです。今、私は他の選択肢よりもGitを好みます。

残念ながら、その時点でどの本を読んだか思い出せませんが、どちらの本を手に入れるか（またはそれらを指すか）、それがどのように異なるか、どのように異なるマインドセットが必要かに焦点を合わせてください。

本の推薦のための最もよい推測は次のとおりです：

スコット・チャコンによるプロGit（簡単にアマゾンリンク...希望者から購入：https : //www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6）

注：Gitのリファレンスブックは購入しないでください。それはまったく役に立ちません。

私の経験から、一部の人はgitを理解しなくても快適に使用できます。彼らは基本的なチュートリアルを見つけ、基本的なコマンドを習得し、準備ができています。おそらく、ジュニアコンサルタントがそれに当てはまるところです。数日で本当にGitを学べるとは思いません！

他の人はそれをすることができません。彼らはgitが何をしているのかを理解する必要があり、それにはもっと時間がかかります。私はそのカテゴリーに属していました。.gitディレクトリの内容を操作することは非常に役立ちました。それは、私にとっては物事がクリックし始めたときです。また、技術リーダーとの1対1のセッションも役に立ちました。

人々は異なる方法で学習し、異なる部分について本当に混乱する可能性があるため、1対1のチュートリアルを行うことができます。gitがブランチを追跡する方法を理解していない、.gitディレクトリの内容を表示しているなどの事実に本当に悩まされている場合...

私はgit（TFSから）私がどこにいるかを紹介しようとしていますので、あなたの質問は私にとってタイムリーです。

ではピープル、本全体の基礎となる論文は以下のとおりです。

私たちの仕事の主要な問題はそれほどではありません、技術として社会学的な自然の中で。

私たちの問題は技術的な問題ではないため、これを取り上げます。git、少し鈍いですが、おそらくあなたや私の上級開発者の能力を超えていません。

技術的なマシンではなく、人間として、開発者の観点から見てみましょう。

あなたは、彼らが（おそらく）習得しているソース管理システムの使用を停止するように求めています。git専門家に使用をやめてgit、移動するように頼むようなsvnものですよね？gitの専門家はイライラするだろうと思うし、おそらくうまくいくし、彼女が本当に好きな部分があり、それを行うのは本当に難しいsvnので、おそらくあまり努力しgitませんsvn。

後輩が良く、それに連れてきた理由は、おそらくです-多分彼らはのこつを持っていないsvnとgit^それを捨てるために彼らのチャンスです。

しかし、高齢者は機会費用に警戒しています -彼らが学んだgit場合、彼らはそうではありません：

• React / Angular / Swift / Blockchain / Kotlinの学習（学習すべきだと感じる他の何か）。
• DIY /ホイットリング/セーリング/詩/グロッケンシュピール/彼らが実際にやりたいことは何でもする。
• 子供/親//友人/重要な他の人と過ごす時間。

• この「大きな新しいもの」を提供する-期限、予算などがあります。彼らはおそらくそれを心配しています。

  「上記のすべてを実行する必要がありgit ます。ソース管理が既にあるのに、なぜ使用する必要があるのですか？」

彼らが得意なことから、初心者の場合は率直に言って面倒で、開発方法を完全に再考する必要があるものに切り替える理由を教えてください。git機能の利点を説明しましたか？

プルリクエスト？きめ細かいチェックイン？分散ソース？フォーク？

彼らはこれらの理由をもたらしましたか？集中化されたソース管理マインドセットを使用している場合、これらは大規模で構造的な変化です。技術的な変化だけでなく文化的な変化もあります。

基本的に、開発者に何を求めているのかを考え、それが正しい理由であることを確認してください。ので、あなたはそれをしたい場合はsvn愚かと古く、誰が細かいその後、もう使いませんが、それはあなたのように考えると、ちょうどその日に上のクラックしたくない他人に販売するのは難しいです。チームとプロジェクトにとって意味のある用語でメリットを述べる必要があります。git苦労に値することに同意してもらうことができれば、彼らが技術を習得することを心配する必要はなく、設定したワークフローに同意するだけです。

幸運を。

これはソフトウェア工学の問題ではなく、心理学の問題だと思います。を参照したいと思いAlgorithms to Live By: The Computer Science of Humand Decisionsます。その中で著者は、探索/悪用のトレードオフのトピックを取り上げます。人間は通常、探検の段階を経てから、探求したものを利用する（使用する）段階を経ます。特定の間隔で何かを最適に使用するためにこれが当てはまる理由には、いくつかの堅実な数学理論があります。

これは年齢と経験にも及びます。人間は自分自身の生活をインターバルと見なし、特定の調査フェーズの後、知識を活用することが最適です。彼らは、年配の参加者に、自分が好きな有名人や家族と会いたいかどうかを尋ねる研究を引用しました。彼らは通常家族を選び、若い人は有名人を選びました。しかし、彼らが20歳以下であるかどうかをどのように判断するかを想像するように求められたとき、高齢者も日常的に有名人を選択しました。これは、既に知っていることを利用するよりも探検から得られるものが少ないと考えると、人々がソーシャルネットワークの構築をやめることを示唆しています。

シニアエンジニアはおそらく高齢で、おそらくいくつかのバージョン管理システムを経験しています。SVNおそらく今まで使った中で最高のものです（少なくとも私が使った古いバージョン管理システムを見ると、SVNはそれらすべてを打ち負かしています）。

彼らの最適な戦略はSVNを活用することです。なぜなら、彼らは調査を行い、これが最善であることがわかったからです。

これは人間の基本的な心理学であり、何十万年もの進化的最適化と戦っています。

あなたは彼らに、a）彼らが彼らの前にどれだけのキャリアを持っているか、彼らが自分自身を見ている間隔について異なる視点から考えるためにプライムし、b）彼らが素晴らしいと思うもの、彼らが何であるかを尋ねる必要がありますで行方不明SVN。の何百もの利点をレイアウトできgitますが、SVNおそらく5つのバージョン管理システムを以前に経験したことがあるのに、なぜ最高なのかについて明確な考えを持っているでしょう。あなたはその議論の装甲の隙間を見つけ、gitこれらの問題を解決できるかどうかを確認する必要があります。そうすれば、彼らは自分自身を納得させるでしょう。

Gitを使用するためのツールやGUIを提供しないでください。混乱させるだけです。Gitはコマンドラインで実行することを想定していたので、おそらくGitが学習されるはずです。どのGUIにも独自の用語と特殊性があり、単純なものにこだわることがあります。

次に、GitがSVNよりも優れている問題をいくつか見ていきます。あなたのチームにそれを学ばせるには、彼らがgitの方が良い理由を見るように動機付けする必要があります。

• ネットワークに接続していないときにコミットする機能
• 自分のブランチを作り、遊ぶ能力
• 相互に送信しても、トラックをマージできるパッチ
• 痛みのないさくらんぼ狩り。
• 変更のリベース
• git spliceでバグを見つける

SVNはここ数年で前進していると思いますが、それらはかつて痛みの世界を引き起こすものでした。開発者がこの新しいツールが単なる素晴らしいものではなく、作業に確かな利点を持っていると判断した場合、開発者はその背後に潜む可能性が高くなります。

学ぶことは新しいことであり、混乱を招くほどの類似性がありますが、2017年にはDCVSはすべての開発者にとって非常に重要なスキルです。

心配しないでください

Gitでは、作業がコミットされると、失うことはほぼ不可能です。簡単に失うことのできる唯一の作業は、まだコミットされていない作業です。

どのようにgit reflog機能するかを見せます。彼らはそれを使用する方法を知る必要はありません。彼らはただそれがそこにあることを知る必要があるので、何かがうまくいかない場合、彼らは彼らの仕事を取り戻すための助けを得ることができます。

次に、この1つの単純なルールを印象づけます。彼らはいつでもコミットをバックアウトできます（リモートからでも！）。

GUIを使用しないでください

GUIを使用すると、すぐに開始できますが、Gitを実際に理解することはありません。さらに、Git GUIを使用する場合、コミットされた作業を「失うことはほぼ不可能」ではないことがわかりました。マージ時にチェックリストを表示するなどの恐ろしいことをGUIが実行し、ユーザーがアイテムのチェックを外すと、警告も記録もなしに履歴からそのファイルを消去します。GUIは、単にコマンドラインGitを学習するよりもはるかに悪いです。

ペアプログラムコードのコミット

git add -Aその後の学習はgit commit難しくありませんが、特にリモートに対してマージ（またはリベース）する場合は、何らかの支援が必要になります。誰でもいつでも支援を求めることができることを明確にしてください。コマンドを入力してメモを取るまで待機します。時間が経つにつれて、彼らは助けなしで対処できる状況の数を徐々に増やします。

Gitはすでに安全です

上記の誰かが「安全なプレイ場所」について話しました。しかし、Git はその安全な場所です。仕事を失いやすいのは、通常の日常的なケースの2つだけです。

• コミットされていないコード
• GUIを使用する

早い段階で頻繁にコミットし、GUIで間違ったパスを開始しないようにします。また、過去の他のソース管理システムよりもGitをコードで信頼できることがすぐにわかります。

私は見て助言するGitlessを。これは、多くの基本的なワークフロー簡素化gitのオーバーラップ（ステージングエリアを心配する必要はありませんが、枝がファイルの自分の作業コピーを保存し、より簡単な使い方だgit rebaseと扱われるgl fuseコラボレーションのための基本となるgitリポジトリを維持しながらなど、）または何か異常なことをする必要がある場合。また、メッセージはもう少し初心者向けです。そして、何らかの理由でgitlessなしでシステムを使用する必要がある場合、コマンドは踏み台として機能するのにgitに十分近いです。

gitのコマンドラインの使用方法の基本を文書化してみました。私（PerforceとSource Safeの使用経験がある）と、古い「関連するフォルダーを圧縮するだけ」のパラダイムを好むプログラマーの両方にとって、それはまだ混乱していました。不透明なツールが作業ディレクトリの内容を変更するのは気になり、多くの場合、作業ディレクトリに特定の変更を組み込むためにツールと議論する必要がありました。

代わりに、2種類の間接参照を使用します。

• GitKrakenを使用して、ブランチの視覚的な履歴と、コマンドラインステートメントを非表示にするGUIを提供します。GitKrakenは、「元の」リモートリポジトリと、gitがローカルの作業ディレクトリと考えるものとの間のやり取りを処理します。

• また、gitが自分のローカル作業ディレクトリであると考えるものとは別の「実際の」ローカル作業ディレクトリを保持します。これらの2つの作業ディレクトリを手動で同期します。これにより、作業ディレクトリの変更が意図したとおりになったことをより快適に感じることができます。

これらの従業員がGitを学ぶのを支援するためにできることはありますか？

問題はGitであり、他の問題ではないと確信していますか？私がコメントから得たのは、経営陣がシニアの貢献者から賛同せずに何かを変更することを決定し、変更を後押しするために彼らの後輩に仕事を任せているということです。これが失敗の良い出発点であり、変化が何であれ。Gitの複雑さは問題ではありません。問題は、彼らが必要と思わない変更が彼らに強制されることです。

そのため、スイッチの利点が見当たらない限り、Gitに足をドラッグする方法に集中しないでください。Gitが現在抱えている問題の解決策であることを説明します。Gitがまだ必要と感じていないものを提供する方法ではなく、Gitが他の人々の問題に対する解決策を提供する方法、Gitが現在戦っている問題を解決する方法ではありません。その後、Gitを教えることは問題ではありません。

多くの場合、Gitは支店での問題を解決するために会社で使用されています。はい、ブランチではSubversionよりも優れていますが、魔法はしません。

経験豊富な開発者は、多くの企業で働いている可能性が非常に高いです。

• 管理者が相反する要求を決定する意思がないため、ブランチを作成しました
• 構成スイッチではなく、顧客ごとにブランチを使用しました。
• 管理者はすべてのお客様に同じバージョンのソフトウェアにアップグレードさせたくないため、お客様ごとにバグ修正ブランチを用意する必要がありました。
• 等。

したがって、あるツールがツールを使うのが得意だと言うとすぐに、私の心は言う。

経営陣は、会社の進路を決めたくありません。むしろ、101の異なるリリースのソフトウェアをテストしなければならず、仕事を101の異なるブランチにマージしなければならないという無駄な生活を無駄にしたいと思います。

また、2人が同じファイルで同時に作業するという概念は「良い」ものであり、よく実行されているプロジェクトを経験した人には受け入れられないため、Gitをそうするためのツールとして宣伝することは経験しそうにありません好きな開発者。

Gitで履歴を見るたびに、コードが変更された理由を確認するのは非常に困難です。履歴の50％以上が論理的には公開されるべきではないマージであり、コードが開発者を離れるとすぐに意味がなくなります機械。

しかし、私はどこかで働きたいです：

• 信頼サーバーでコンパイルおよび単体テストが行​​われるまで、中央システムにコードは入りません。
• コードレビューを追跡する簡単な方法があります
• 「get」を実行するたびに、コードが常にコンパイルされて動作する場所
• 他の人と競争する必要なく、またはビルドを壊しているかどうかを確認するためにオフィスに迷い込むことなく、変更をプッシュできる場所。

したがって、実際の問題を解決し、Gitが経験豊富な開発者が購入するソリューションの一部である場合、「マジックマージ」を実行できるクールなおもちゃだからといってGitが好きになるとは思わないでください。

したがって、開発者がローカルGitから中央Gitにプッシュできる場所はどこでも間違っています。管理された自動化プロセスは、開発者から変更を取得し、テストなどを行った後、合併をチェックしても大丈夫です。長期的に関心のない支店など。

Kiln（http://www.fogcreek.com/fogbugz/devhub）または「プルリクエスト」ワークフローを使用するGitHubでも、経験のある開発者を満足させることが期待されます。処理する。