最近、Git の基本概念を学びました。使い方に慣れるために、少し git-svn を使用しました。友達と一緒に git で最初の「真の」プロジェクトを開始したいと思います。
そこで、一般的に Git を使用する際のベスト プラクティスとは何か、また SVN に精通した開発者が陥りがちな落とし穴があればお聞きしたいと思います。
複数の開発者間のコラボレーションは、おそらく、中央の「ベア」リポジトリを使用して行うのが最適です。これは、Subversionのリポジトリにほぼ類似しています。自分のリポジトリしかない2人以上の人の間で変更を共有することは難しく、エラーが発生しやすくなります。また、中央リポジトリを使用すると、Subversionのバックグラウンドからのアクセスがより快適になります。
Gitの優れた点の1つは、複数の「共通」リポジトリを簡単に作成できることです。開発をセットアップしたので、通常対話する1つのサーバー(ほとんどのプロジェクトの「オリジン」)に一連のベアリポジトリを保持しますが、一部のプロジェクトでは、すべてをGitHubにプッシュします。どちらが単一の中央リポジトリであるかを選択する必要はありません。GitHubリポジトリからプルして作業し、後で自分のコピーにプッシュできます。
Git はアクセントの悪い SVN だと考えるのは落とし穴があります。この最近の質問は、SVN で意味のある Git の 2 つの落とし穴を示しています。
rebase
Git では に置き換える必要があると考えていmerge
ます。他の誰かの変更をマージすると、多くの不必要なマージ競合が発生して、rebase
回避できる場合があります。もう 1 つの大きな落とし穴は、Git の FAQの「予期しない動作」の下によく表されています。
A quick rule of thumb is to *never* push into a repository
that has a work tree attached to it, until you know what you are doing.
マニュアル ページのどこかで、これが「予期しない結果につながる」可能性があると穏やかに説明されています。他人の作品をすべて失うようなものです。
このGit SVN クラッシュ コースでは、SVN で考えながら Git に簡単に移行できます。
GitHubでアカウントを取得し、それを使用して機能する必須ではないコードを維持することは、それを実行するための独自の最善の方法を見つけるための優れた方法です。ネットワーク ビジュアライザーは、git でさまざまなことを試しているときに何が起こっているかを「見る」のに非常に役立つことがわかりました。