私は多くの新しい技術サポート担当者と協力しています。開発者にとって優先度が高くない小さな問題を修正することを好む場合もあります。これには、SVN の基本を非プログラマーに教える必要があり、これには少し注意が必要です。
どのリソースが役に立ちましたか? SVN を教えるために通常使用する図はありますか?
私がそれを読んだとき、ここには2つのことがあります。1 つはコンセプトを教え、2 つは SVN の使い方を教えます。
一般的にはシンプルに保ち、複雑さは時間と使用の中で自然に処理されます。
簡単に言えば、SVN は作業中のバックアップですが、保存するすべてのバージョンではなく、行った変更のみを保存します。
ここでは実践的な経験に代わるものはありません。チェックアウト、更新、チェックインの方法を示してください。学習曲線が大幅に短縮されるため、Tortoise SVN を使用することをお勧めします。
物事を単純にするために、私は彼らがコミットできる独自のブランチをセットアップするので、彼らはまだそれを理解する必要がなく、バックグラウンドでマージを管理するだけです. しかし、すぐに彼らはそれを理解するでしょう!
基本的に、SVN でできること、コードだけでなく、一般的なドキュメントに使用できることについて議論できます。
コードに言及していない例は役に立ちます:
著者は自分の本を書き、そのコピーを中央の場所に置きます。その文書の名前は 1 です。彼が変更を加えると、そのコピーに 2 という名前が付けられます。次のコピーには 3 という名前が付けられます。中央の場所にアクセスできる限り、いつでも必要に応じて以前のコピーを参照できます。
現在、出版社は彼の本に 2 人の校正者を割り当てています。SVN を使用すると、校正者は語彙の間違いを修正して修正し、修正したコピーを中央の場所に置くことができます。ライターと校正者も最新のコピーを取得でき、変更内容を読むことができます。これは、新しいコピーが配置されるたびに、関係者が変更内容についてコメントを書き込むことができるためです。
校正者が論理的および文法的な間違いを見つけたらどうしますか? 単純に変更して中央の場所に新しいコピーを置くことはできません。なぜなら、書き手の意図がわからず、独自の書き方 (つまり、意図的に標準から逸脱したもの) である可能性があるからです。彼らはバグ追跡ソフトウェアを使用できますが、それは別の記事にします。
問題のバージョン管理が解決することを彼らに示すことが出発点であるべきです。.bakポイントを確認するために、最初にファイルを最初に実行させることができます。
しかし、ウィキペディアに十分に精通している場合は、ウィキペディアの歴史と、ウィキペディアがどのように保護されているかを示す方が断然良いでしょう (ウィキペディアの好奇心の一部に答えることができます)。ウィキをインストールして、試してもらうことができます。
その後、svnの「退屈な」テキストコマンドからそれらを入れてください...
最近、SVN を Web 開発チーム全体 (プログラマー、インターフェース ビルダー、グラフィック デザイナー、コンテンツ エディター、サイト モデレーター、非技術マネージャーで構成される) に紹介したときに、まさにこの問題に遭遇しました。技術以外のドキュメントを探しましたが、最終的に使用できるドキュメントはほとんどなかったため、独自のドキュメントを作成することにしました。残念ながら、そこにある情報の大半は、ユーザーがクライアント/サーバーアーキテクチャと「ブランチ」とは何かについて知っていることを期待しています-私の場合、それを想定できませんでした. 私の移行前の PowerPoint の 1 つを SlideShare で見ることができます (" What Is This Thing Called SVN? FTW or WTF? ")
http://www.slideshare.net/secret/wBsLzZb3O7cXCU
本当の鍵は、SVN が - その中心にある - ファイルをコピーして貼り付けるためのより良い方法であるということを説明することでした。default.bak、default2.asp、defaultBackup.asp、defaultMyCopy.asp などを取り除くことは、誰もが理解できることでした。
ユーザーがソース管理の考え方に慣れてきたので、開発チーム (および他のユーザー) が助けてくれるように、内部 WIKI で質問するように人々に勧めました。
また、一貫した方法でローカル デスクトップを自動設定するカスタム SVN デスクトップ ツールを作成しました。これにより、会社全体の全員が他の全員と同じ設定 (c:\projects\projectname) を持つことが保証され、ローカルも更新されました。手動で何も構成する必要なく、いつでもローカルで Web サイトを表示できるようにする IIS のインストール。
そのため、多くの手を差し伸べる-ユーモアを使う-物事をシンプルにする- 標準化を維持する - 質問する方法を提供する -サポートを提供する- ユーザーと「一日をやり遂げる」必要性を認識する. そして可能であれば、彼らの机に座って、各人がハードルを乗り越えるのに必要なだけ何度でもプロセスを説明してください.
クライアントのブランチを持つだけでなく、以前のリビジョンを追跡することが重要なシナリオを説明します。
svn に固有のものではない、より一般的なバージョン管理のチュートリアルがあり、役に立つかもしれません。
あなたは彼らを圧倒したくありません - ただ彼らにそれに対する基本的な必要性を与えてください.
すべてがフォルダーのように見えるため、CVS と言うよりも SVN を説明する方がはるかに簡単であることがわかりました (ただし、浅いコピーを使用します)。このように物事を説明するだけです。
そして、すべてを詳細に説明するのではなく、知る必要がある場合にのみ伝えてください。分岐とマージについて説明し始めると、彼らの頭が爆発するのを見ることができるかもしれません。
プログラミング以外にも SVN を使用できることを伝えるとよいでしょう。構成ファイル、ドキュメント、基本的にバージョン管理が必要なもの、またはバックアップするだけのもの。
すべてのファイルとファイルのさまざまなバージョンに関する情報が存在するリポジトリと、実際に作業するファイルである作業コピーについて教えてください。
ファイルのチェックアウトやコミットなどの簡単なことから始めます。ファイルをコミットすることは、「新しいファイルまたは新しいバージョンのファイルがあります」と言っているようなものです。ファイルを最新バージョンに更新し続ける方法を示します。
たぶん、トランク、ブランチ、タグ、マージ、その他すべてのジャズについて話し始めることができます。優れたリソースは、実際に何かを学んだ非プログラマーです。彼らはおそらく、他の非プログラマーにより適したフレーズやアナロジーを使用できます。
「幹」や「枝」などに名前を付けた木の比喩はどうですか?
サポート担当者に、SVN はソース コード サーバーであり、SVN が行う変更はクライアント側の変更であることを伝えます。彼らが行うことは、ソース コードのクライアント コピーを変更することです。そこに保存するには、SVNに投稿する必要があります。他のクライアント/サーバー アプリケーションと同じ方法です。
この記事は、新しい開発者が見るのに非常に適していると思います。図は優れており、情報は非常に単純です。
本当にコツは、分岐の重要性を理解してもらうことです。リビジョン管理自体の概念は誰でも簡単に理解できます。