SVN to Git

Apart from Ruby and Rails framework, mastering the SCM skill is a part of the checklist to be in the elite group. SCM is software configuration management and it is for managing changes in software.

You do not want to made some mistakes and realize all your hard work is lost, especially on the source codes.

I've first discovered SCM using SVN, of which a much improved version of CVS. This solves much of a problem when I need to work together to develop our software with other programmers.

Before using SVN, I need to zip up the source codes, copy it to my colleagues and then they do the changes and then we pass around. But tracking the changes is a cumbersome and error-prone task.

Since SVN, we have less problem with that, however, there is a problem too. SVN needs a central server, of which we need to synchronize (update, commit) with.

But lately, since I'm doing more open source and rails community seems to love Git, I've come to know this little tool that is once mastered, can't live without it. Git is different because it is a distributed SCM, unlike SVN which is a centralized SCM.



Apart from that, Git allows us to have a "server" repository in our own computer and commit as frequent as we want. Then share our repository along with its history with others. Whether through a server or peer-to-peer, meaning, just sync with each other without the need of a server (since each computer is a server itself).

To simplify the understanding, here is how we can use Git on a daily process:

1. Initialize the repository (git init) - this is done one time when you first create a new project.
2. If the project is from someone else, you can download it (git clone).
3. Then you can start making changes and then you can do a commit (git commit).
   
   Have you played games? In some games, you can do a "save game", before you venture into tricky situations that can lead to game over. Commit is just like save games.
   Or for those non-gamers, commit is like incremental backups.
4. If you clone the repo from server or other computers, it should have a remote automatically. A remote is a URL link that is stored in the repository and it is able to update (git fetch or git pull) the repo by re-downloading from the remote repo again.
   
   The difference between git fetch and git pull is that git pull will perform a fetch and then a merge.
5. In SVN, all the updates are git pull. I'm more comfortable to use git fetch as it is non-destructive that doesn't affect my current files.
6. Once downloaded, we can merge or rebase the files. Rebase is similar to merge, but it will rewind back in time to the point where the codes are the same and apply changes incrementally.
   
   So, rebase is also quite handy as we do not want to have too many commits or branches floating around. However, only rebase on your own local branches. It's not recommended for rebasing with pulled branches. A golden rule to remember.
7. Once awhile, you're doing some deep development on your codes, you may want to consider branching - meaning don't touch on the stable codes. Branch out (make a copy) and then make changes there.
   
   When needed, you can switch between branches and maintain the code on each branch. Imagine you have multiple hats, switching branch is like changing your hats, putting a different hat. :)
   
   Better still, once you've finished, you can merge or rebase back the to the master branch. Cool?
8. All the stuff that you need is within the git folder (usually .git - hidden in linux/mac). You can just backup the entire folder and go.

There's more to git such as setting up .gitignore to ignore certain files. Let me know if you need help on that. Now, let's git going.