Basic Introduction to a Git Workflow for Subversion Users

If you would like to learn how to use the version control system Git and you’re currently a Subversion user, this guide is for you. I’ve recently started using Git myself, and coming from Subversion there are several basic concepts and ideas that need to be understood.

There are many great guides freely available that can teach you everything there is to know about Git (such as ProGit and Git From the Bottom Up), but here I hope to give a (very) quick overview of the basic concepts and a simple workflow.

First of all, it’s important to understand that Git is distributed, which means that every developer has a full copy of the repository. We’ll see where this comes into play in a minute.

A Basic Workflow

  • Developer clones the repository (Similar to “checking out” in SVN). This gives the dev a full copy of the repository.
  • Dev creates a new branch for working on a task/bug. We’ll call the branch “fix-bug-x” for the sake of this example. Work is never done in the main(“master”) branch. Branching in Git is built to be dead simple since it’s used so often.
  • Dev commits code early and often to the dedicated branch in his local repository.
  • At any time, local commits can be “pushed” to the origin repository. This basically syncs local commits with the origin repository. At this point, other devs could “pull” from the origin repository and get those changes(which would all still be on the dedicated branch).
  • When work is complete, the dev pushes all changes and creates a “pull request”. This is basically a request for the owners of the repository to merge all commits to the “fix-bug-x” branch into the master branch.
  • The owners/admins of the repository review the code in the pull request. At this point, they can either merge the “fix-bug-x” branch into the master branch (which would get deployed), or they can reject the pull request for any reason (i.e. incorrect fix, bad code, etc).

And that’s it! The cycle repeats itself. Do keep in mind that this is A (simple) workflow, and that there are many possible others.

A Few Benefits of this Git Workflow

  • You can’t break the build for other developers, since everyone will be working on distinct branches for their respective tasks.
  • If you get halfway through an item when a critical bug report comes in, you simply commit your changes to the current branch, then create a new branch in which to fix the bug. The bug fix branch can then be merged into master, all without being affected by the code of your half-finished feature.
  • Implementing a code review system is ridiculously easy. Simply implement the rule that all code in a pull request should be reviewed before getting merged into master.

Now I will say that there is a LOT more to know about Git, but hopefully this is enough to get you started and show you how simple it can be. Now you can go ahead and dive into the previously mentioned resources with confidence to get more of the fine details.


You may also like

Leave a comment