app/git/svn脳からgit脳へ - 豚吐露＠wiki

svn脳からgit脳へ

svn脳、code内変更履歴と戦い、git脳へ導く方法を考える。

自社で、svnしか使ったことがなく、gitに慣れていない方々にgitを導入する際困った。
なので、このページでは、簡単にsvnとgitの違いを理解でき、gitのイメージを掴める資料の作成を目標にする。
猿でも～の前段階のイメージですね。イメージが無いと何をやるにも聞かんと分からんって状況になっちゃうので...

code内に変更履歴を書く構成管理

害悪。まともな構成管理ツールが無かった時代に頭の悪い人が考えた構成管理方法。

デメリット

• 無駄なcodeが増える。
• けど、書いてある履歴見ても正しい変更履歴が分からない。
• 担当者の気持ちで構成管理の基準が変わっていく。
• 不要なcodeを削除しないことが常態化する。
• 上記の考え方をscript言語に持ってきて性能低下を招く。
• 読み難いので保守がし難い。
• 読み難いので、品質が下がる。
• そもそも構成管理ができてない。
• 客に知識がある人が居ると、信用を無くす。

メリット

• この方法しかやったことない人(管理者、客)に向けては良い感じに見える。
• code量が増えるから仕事やった気になれる。
• code量が成果につながるprojectだと良い感じに見せれる。

『木を隠すなら森』という言葉があるように、有効なcodeを分かりにくく隠すなら、不要な無用な無効なcode群の中に紛れ込ませるのが一番。
これによって可読性、保守性は著しく下がり、当然品質が下がる。

特に、『#if false』で無効化してたり、『/*～*/』でコメント化してると、無効行がgrep時に判断できなくて工数が増える。
まだ『//』行コメントで無効化してる方が賢い。
加えて、無効行となった部分に対して、構成管理ツールがmergeしてくれて、担当は対応した気になっとるけど、処理が無効で動かないということもあり得る。怖い...

管理単位

• svn： file/dir単位
• git： work全体

コレが地味に理解を妨げていると思う。
svnでは特定の機能を任意のrevに変更する際、work全体で特定のrevを取ってくるのではなく、任意のfileだけを任意のrevにする。
この時、怖いのが、statusコマンドで変化が取れないこと。
だから、svnでは比較用のworkなど複数のworkを作りたがる。

svn check-out/git clone path

• svn： 任意のdir
• git： reposのroot dir

server reposからcheckoutやcloneする時、svnでは任意のdirやfileだけをcheckoutできる。
gitは、必ずreposのroot dirになる。

change-set

• svn：
• git：snapshot

branch/tag

• svn：trunkを任意の場所(/branches、/tags)にcopyしたもの。directoryを指す。
• git：任意のcommitを示す分かりやすい名前。branchはcommitと共に移動するが、tagはcommitと共に進んで行かない。

diff

svn	git
checkout	clone
update	pull (fetch + merge)
commit	commit
-	push
add	add
-	reset

image

workでの作業

• svn： 現在のpathを意識する必要がある。
• git： 現在のbranch(commit)とpathを意識する必要がある。

---

更新日： 2023年08月02日 (水) 14時57分05秒

• https://qiita.com/kaityo256/items/81e7951a1ca2706955a4
  https://www.kaitoy.xyz/2016/10/06/git-vs-subversion/
  https://suzaku-tec.hatenadiary.jp/entry/2017/08/14/001042 -- (s1n) 2022-06-23 10:01:32