The Goal

Ultimately, when people talk about Source Control, they have the same concepts in mind. I want to be able to easily update my source control, collaborate with others, and have a history of changes that I can review and use to make other changes. So for our Analogy, these basic concepts, we’re going to call Getting from point A to point B.

SVN, The Car

With SVN (aka Subversion), I like to compare it to a car. You can hop in, drive around, and get from point A to point B with relative ease. You do need to learn how to drive a car, but after a little while, you get the hang of it. Eventually, you can get pretty good.

You get from point A to point B by combining things like accelerating forward and turning left and right. Maybe you perform even more complicated maneuvers like accelerating in reverse and turning the opposite direction to back up. Some people can even tackle crazier terrain and go off roads with their cars. All and all, it is a very versatile and well suited for the job. It isn’t very difficult to learn, and gets the job done.

Git, The Helicopter

Git, like SVN, can get someone from point A to point B. However, they approach the task with some fundamental differences. I like comparing it with going from driving a car to flying a helicopter. The helicopter is very versatile as well. It doesn’t require roads to travel along, and doesn’t get caught in traffic like cars can. They don’t have to deal with red lights or stop signs. To the normal driving looking up at them, it seems that they just “go.”

This is because you don’t just drive forwards and backwards, turning left and right. With a helicopter, you also go up and down. This adds an additional layer of complexity. You gain more mobility, but is crucial you understand the fundamental differences. For example, unlike a car when you accelerate and you go forwards, with a helicopter you punch the accelerator and you go up, not forwards. For anyone who has ever played a video game with realistic controls for a helicopter, it is hard. People have recorded tutorials teaching how to fly helicopters in games, and show the fundamental differences on how you approach flying. Even when flying planes in these games is similar to driving a car, many concepts are backwards when flying a helicopter.

Trying to Drive a Helicopter

So at lunch a guy hears his friends talk about how they skipped over traffic this morning, and got to work in minutes instead of the hour it normally takes. They rave how great it was, and so the guy asks if he could try it out. They say sure, and hand him the keys. He goes out, pops the keys in, and without trying to understand the fundamentals of flying a helicopter, he tries to drive it like a car. For those who have watched people try to “fly” a helicopter in a game without a clue, this is what it looks like:

When the player jumped in the helicopter, he punch the throttle thinking he’d go forward, and pulled back on the stick thinking he’d go up. Instead, he went up and backwards and then out of control.

When SVN users try out Git, and don’t learn or understand the fundamental differences, they get very frustrated with it. Even if they manage to duplicate their experience with SVN using Git, they are just adding more complexity without any real gains.

Learn the Differences

The difference comparison at the Git Wiki is fair in it’s assessments. It shows how each solution handles different features, and what impact it has. With Git, there are some drawbacks, such as you can’t just checkout a subset of a repository. You either download the whole thing (with history) or not.

If you approach using Git like it was SVN 2.0, you will be disappointed, frustrated, and will give up. Git is close enough that you can feel like you are using SVN, but when it doesn’t act like SVN, you won’t know why. So do yourself a favor, and when you sit down to learn Git, think “I’m used to driving a car, but I’m learning how to fly now. I’m learning something new.” If you approach it with this mindset, I believe you will be much more successful.

Related posts:

1. OS X and Tabs – Skipping Drop Down Controls

Background

I have tried to use it in the past two or three times, but each time I had basically given up. There were a few reasons why in the past I didn’t really stick with using Git:

• I really didn’t understand the differences between Git and SVN. Most importantly, I didn’t understand the reasoning for why Git did things different, and the advantages it did.
• I used to rely heavily on GUI based SVN tools. Over time, especially the last year or so, I’ve moved away from these GUI tools to the command line. I found it a lot easier to do merges, switches, and even commits from the command line. After being much more comfortable with the command line, it made it easier to use Git, which has far few GUI options.
• Subversion is still a great tool with great adoption and support. While I might be willing to switch to use Git, I wasn’t looking forward to helping the rest of my team members learn how to use it. Especially those who required a GUI for Subversion. Also, all the tools we had were built on Subversion, it would be a lot of work switching everything to Git, and some things at the time didn’t interface with Git.
• git-svn was missing a few features two years ago that really make it a viable interface with Subversion. Also, because of how versatile Git is with supporting all sorts of workflows, the tutorials for using it with SVN all seemed missing a complete picture. Even now, I had to Google and piece meal a few different tutorials to get my setup to work correctly.
• Most arguments for Git over SVN that I heard focused on Subversion’s short comings, instead of the benefits of using Git. I was happy with Subversion, and it was working well in production, so I assumed Git users were just people who didn’t like SVN.

So, as I write this post, I’m not writing as a newly made Git fanboy, but a Subversion user who has found a lot of advantages with using Subversion and Git together. I plan on to keep using Subversion for the remote repositories with my current projects, and in the future when I deploy new repositories, I’ll consider using Git fully, or still use Subversion if it is better suited.

Newly Found Advantages

To understand the power in Git, it is a “distributed version control system” where each “Git clone is a full-fledged repository.” This is also where a lot of hangups happen with Subversions users. I kept expecting to “checkout” a “working copy.” What I needed to remind myself is I was “cloning” a version of that git or svn repository. This enables several features that aren’t really viable on Subversion alone.

Understanding Git Branches

One thing to understand about the differences between git and svn branches (and tags) is this: SVN treats them as just a foldering structure, Git manages them for you. This means Git can handle branching, tagging, and merging much more cleanly. With SVN, while I could do merging alright, I always felt like I was looking up different revision number, double checking my commands, and it felt very, very fragile. With Git, it felt like branching and merging were very solid.

When I first really saw Git branches in action, my mouth dropped somewhat. The light bulb clicked, and I saw the real advantages. Because my local git repository isn’t tightly coupled with the branches on the remote server, I can make a branch locally without having to have it on the server. Almost all of the svn repositories I work with are large, one 200MB and another 605MB, and branching them is a complete pain. Either I have the server branch them and download the branch, or branch locally and then upload the branch through committing. It was a complete pain. However, that same 605MB Subversion trunk, takes milliseconds to create a local branch in Git. Even if I want to create a remote branch, Git is smart enough to issue the SVN copy command, but branch locally without having to download the entire thing from the svn server.

So now, how often do I branch? A lot more often. How often do I merge? I a lot more often. Now if it isn’t a quick 15 minute change, I’ll branch it. That way, if I need to do any hotfixes quickly, I can switch back to my master branch without any worries.

Stashing

This would be another great Git feature is the ability to “stash” a set of uncommitted changes. So lets say I was working on my master branch. Then I need to do a hotfix, but I hadn’t made a branch. Git allows you to “stash” the change. It is like an “unoffical commit.” So you can stash a set of changes, and apply them later. You can have multiple stashes, and apply them, or just the ones you want. When you’re done with them, you can clear them all out.

These are only a handful of the things I’ve found so far, but look forward to learning more and more.

Getting Started

Warning: at this point and time I’m still learning and feeling out a workflow, so what I have below might not be 100% accurate or the best. Feedback is appreciated and welcome.

Alright, so now that I’ve explained some of the things I’ve been impressed with for Git, here are my notes for getting started from scratch. First off, if you use Windows, you can go to the git website and download the binaries. If you have Mac OS X, I recommend installing it through MacPorts. If you have Linux, then use the package manager of your distribution.

Configuration

Next, a few configurations to make your life better. Run the command:

Then, you can put your settings, here are mine:

Cloning

Now, when using Git with SVN, there are a few special things you need to keep in mind when cloning, you’ll need to let Git know where to find the branches and tags. If you use the standard trunk, branches, tags layout, then you can use the –stdlayout flag. If not, you will have to declare where trunk(flag -T), branches(flag -b), and tags(flag -t) are located. So here is how you can clone your SVN repository:

Alright, now, this will take a long time especially if it is a large repository with a lot of history. Reason being is it is cloning the complete history, not just the current files. So be prepared to wait. Now, you’d think it would take up a ton of space, but Git uses compression to condense the history very well.

Once it is done, you are ready to begin. Before you even start, I highly recommend making a backup of your main folder, especially if cloning too a very long time. The reason is if you mess something up, you can just delete the entire folder, copy over your backup, and start again. This will avoid you having to re-clone and wait for an hour for 20,000 revisions to download.

Basic Committing

Now, lets first take a look at the current branches you have locally:

Now, if you want to see all the branches, including remote branches, then add a -a flag for “all.”

So freature_one would be the corresponding svn location: http://www.example.com/svn/branches/feature_one

Now, a little Git 101 with SVN. In the Git world, master is what SVN calls trunk. It is the master branch. So lets do some basic committing. After making some changes, lets commit them to the local Git repository:

The -a is to add any new files to the repository, and the -m is for the message (and you can combined them to -am). You can make several commits, but you haven’t pushed them to the SVN repository yet. To do this, you do the following:

And that is it. This will take each commit you made, and commit them to the svn repository. Now, you will also need to get the changes from the SVN repository. The terminology is different, but functions pretty much the same:

This is pretty much the same as doing “svn update”. From what I’ve read, there is just a little bit difference, in the sense that git will get the changes from the current HEAD, apply them, and then apply and uncommitted changes.

Now, if you have any conflicts, you can use the following command to use a merge tool to resolve the conflicts:

If you want to check the status, you can run:

Branching & Merging

Alright, now if you want to make a new branch to work off of, and you are branching locally, just execute this command.

This will make a branch from master. This will also switch you to using the new branch. One great thing with Git is you don’t mess with any switch commands, worrying about paths, or anything else like that. It makes developing PHP applications that much easier, since I’ll setup my environment just once.

So as you are working, you can switch between the branches easily with a:

Now, when your code is ready to merge back into master, just do a:

Resolve any conflicts if you have any, and then perform a git svn dcommit.

Now, if you want to do a remote branch so you can collaborate this branch with others, you issue an svn branch. Now, you’ll want to make sure you are on branch you wish to branch from, and it is linked to the correct svn path. During all my testing and playing around, I somehow got my master branch pointing to a svn branch instead of trunk. So issue an “git svn info” and verify the “Path” is pointing to trunk. If it isn’t, then issue the command “git reset –hard remotes/trunk”.

When ready to make your new remote branch, just issue this command:

Then when it is done (which normally is pretty quick), you can see see your new branch by “git branch -a” and it should be called “remotes/name_of_branch”. Now, create a local branch from that remote branch:

Now you can follow the same process as you would on master: git svn rebase (svn up), git commit -am “message”, git dcommit. When you are ready to merge it back into trunk, you’ll want to do a merge like before, but this time use the “–no-ff” option. There is a great, longer explanation as to why, but here is the short answer: Fast-Forwarding (ff) is basically a Git trick to make your merge appear like it happened in time with the normal branch you are merging into. Well, there is a bug where this also can re-assign the url path of your master branch from trunk to an svn branch. So:

There is no way to delete the svn branch from your local Git. However, you can easily issue an svn command: “svn del http://www.example.com/svn/branches/name_of_branch”. However, afterward, even after you do a “git svn rebase”, you will still see the remotes/name_of_branch in your branch list (git branch -a). There is an explanation of why it will stay, if you want to remove it, you do it by:

This will remove it from your list.

Non-Traditional SVN Layouts

For one SVN repository, we have the traditional trunk, branches, and tags. However, we also have a “production” directory, which contains our current production code for the website. Our workflow is we develop against trunk, get it stable, and merge it to production. Then, all of our push scripts pull from the production folder. With Git, this folder was not showing up. There is a simple fix for this, by adding another config to your Git repository.

You should see an entry like this:

So what you can do is add another svn-remote entry

Then, to have it show up in your remote branches list, call a one time fetch:

You will now see remotes/production in your “git branch -a”. Now, to get a local copy:

There are a few caveats. You will have to do a separate git svn rebase to do an “svn update”, since that command only updates the current svn-remote you are working on. So if I wanted to update both, I would:

Reverting & Reseting (Yikes! I messed something up…)

With SVN it seemed every now and then I would bork my working copy, and I would have to try to revert. If that didn’t work, sometimes I would just delete my local copy and re-checkout.

With Git, given that cloning from SVN can take a very long time, will repeat my recommendation from before. Make a copy of your local repository every now and then, incase if you really mess things up you don’t have to clone the entire thing again, and instead just do a “git svn rebase”.

But before you have to resort to that, lets take a look at some options. There are some good articles on the topic. One is git reset which works well for uncommitted changes. Did I really mess something up and want to undo to the previous commit?

This will do a hard reset to the exact files as of the last commit. Lets say you have some local commits that are just bad, or a merge that went wrong:

This will let you restore to what is on remotes/trunk. I haven’t done much with “git revert” but it seems fairly easy to use.

Summary

The bottom line, is once learned, Git seems to enable myself as a developer to do more with my source code. Its interface with SVN allows me to gain almost all the benefits of Git without causing major disruption to my fellow co-workers and environments.

Thanks to a handful of UTOS (Utah Open Source) and UPHPU (Utah PHP Usergroup) people. They’ve helped fill in a few gaps I’ve had in my understanding on how Git works.

Notes

Here is a list of just some of the articles, blog posts, and web pages to help me figure everything out.

• Git Crash Course for SVN Users – This is a wiki page on the basics of Git. Doesn’t cover itegration with SVN Remote Repositories however.
• Learning git-svn in 5 min – Great short article on getting started with git-svn
• Git SVN Tutorial – A good, basic tutorial on using a Git workflow with SVN.
• Git: how my life has improved since last month when I used SVN – Another blog post outlining how to use Git from and SVN user standpoint.
• How to Convert a Local Branch in Git to a Remote SVN Branch – A walkthrough on how to share a local branch to a remote branch on SVN.
• Git Tutorial : Starting with git using just 10 commands – A great intro to some useful commands, such as git log, git status, git diff, gitk, and has another post with even more useful commands.
• Git Community Book – Great for clear instructions on how to do beginner and intermediate things. This is where I figured out how to use the stash command.
• Pro Git – Another excellent book about using Git, free online and available for print as well. Very clear and easy to understand. Has a good chapter on working with Git & Subversion
• Git Man Page – Good luck. Its good after you know how Git works and need to read up on some details.
• Git Cheet Sheet – Great quick summary of common tasks in Git.
• Git SVN Tutorial – While this is for the parrot project, it does have a good example of a Git/SVN Workflow
• Five advanced Git merge techniques - Five more advanced tricks with Git and merging, not sure if I’ll actually use all of them.

And some random Git Commands so I personally don’t forget them:

• git log –graph –oneline –decorate – Show me my log in a scrollable version with branches shown.

Related posts:

1. SVN Switch – Key to Success In Web Development
2. Speaking: Utah PHP Usergroup – Streamlined Web Development
3. XAMPP for Mac – My Frustrations & Solutions

In web development, one big area where I don’t see us using a lot is branching, tagging, and merging. However, with our iPhone Apps, we use tagging and branching a lot. As I started to think why, one of the biggest things was the environment. Client development, especially with the iPhone, is double clicking on a project file for Xcode, and I’m ready to go. There is almost no hassle running trunk versus running a tag or branch. It is all the same.

Building against a website, however, is different. Your environment requires a lot more information and pieces. For me, I need to make changes to my host file (for custom domains), Apache/Nginx configuration, MySQL Connection information, etc. There is no file i “double click” and go. It is a pain anytime I need to change my local (or staging or even production) paths and settings.

This is where the svn switch command comes in handy, and is extremely important. It allows you to change your checked out working copy’s source (or url), while maintaining any local changes you may have made. You can tell the actual path, regardless of file or directory names, by doing an svn info command. The best way to understand is through examples.

Arg, should have made this a branch.

You’re working on a big change, such as completely rewriting your internal message system. Suddenly, your boss walks in saying “There is a bug we need you to fix and push live now!” It is a simple bug, but your trunk is only half way through a major change. What do you do?

1. New Branch on Server – You need to make a new branch on the server based off the server’s version of trunk. It’s a simple copy function, while having it execute on the server:

   svn copy -m “Branching for new email system” http://svn.example.com/trunk/ http://svn.example.com/branches/new_email_system/

2. Switch your trunk working copy to new branch – This allows you to keep all of your current changes locally, but switches you to the branch version:

   cd /path/to/trunk/
   svn switch http://svn.example.com/branches/new_email_system/

3. Commit changes to branch – Commit your changes to the repository which will be applied to the branch:

   svn commit -m “changes to new message system.”

4. Switch back to trunk. – Make sure you are still at your trunk. If you did an svn info, it would show the URL location at the branch. Execute the switch again:

   svn switch http://svn.example.com/trunk/

5. Switch between trunk & branch as needed – When you need to work on the trunk, switch to the trunk. When you need to work on the branch, switch to the branch. The great thing is you won’t need to change any URLs in your configs in apache and such, it will just work.
6. When your branch is ready, merge into trunk – Perform a merge since the starting of the branch to the last revision in the branch, applying it to the trunk:

   svn merge -r 100:125 path/to/branches/new_email_system path/to/trunk

7. Test changes made by merge, then commit. – Test the changes locally, and when you are satisfied things went well, commit the merged changes to trunk: svn commit -m “new message”
8. Continue Development – you are safe to proceed as usual.

Over the new few weeks I plan on posting more little tutorials and tricks of some more advanved SVN commands, and hopefully it can help some of my fellow team members. Let me know if you have any questions, or want to know how to do other things. But the bottom line is if you haven’t used the svn switch command, especially in web development, you are sorely missing out.

Related posts:

1. Zend Studio vs PHP Development Tools
2. Speaking: Utah PHP Usergroup – Streamlined Web Development
3. Streamlined Web Development: In-Depth

First, navigate to the folder I want to edit it’s ignore settings.

Second, execute the command: svn propedit svn:ignore .

(don’t forget the period)

It will then open up a text editor. You put one match pater (or filename) per line. Save and exit, and your svn properties will have been changed. You then need to commit your change, and you’re good.

Now, I won’t forget. If you follow my blog, you might have noticed a trend of myself putting simple things I don’t do frequently here. It seems I have a terrible memory, and it makes is easy for me to find things on my blog again. Hopefully, just maybe, it will help someone else out there too.

Related posts:

1. Recursively Add New Files to SVN
2. Mac Keyboard Quirks – Making Mac more like Windows

Related posts:

1. Speaking: Utah PHP Usergroup – Streamlined Web Development
2. PHP Video Tutorial – Getting Started – Installing XAMPP
3. Streamlined Web Development: In-Depth

I never could figure out how to do it until I read a comment at a blog post:

svn st --ignore-externals | grep ^? | sed 's/\?/svn add/' | sh

Man, shell is just awesome. This is better than the first suggestion of using “svn add –force *” because it would add ignored files as well. Hope this helps someone and makes them happy like I am now!

Related posts:

1. XAMPP for Mac – My Frustrations & Solutions
2. List of 50 PHP Tools
3. Redesigning blog….

I’m very pleased to announce the topic for November’s UPHPU Meeting : Streamlined Web Development using a VCS (Version Control System) and Trac.

Starting the meeting off will be Code Greene’s Kevin Carter. Kevin, who has used Git in a production environment for several months now, will be presenting a primer on how to get started with Git. Additionally, he’ll cover the advantages of distributed source code control and possibly some topics on using git in an svn eniroment. His blog can be found at http://dexterthedragon.com.

Following Kevin will be are main speaker, Justin Carmony. His presentation will focus on the unique challenges with developing, deploying, & managing Website development. Justin Carmony has put together his trips, tricks, and suggestions for streamlining the development cycle. With a focus on automation, using SVN and Trac allows developers to focus on development rather than redundant tasks. Whether a small project with a single developer, or a large project with a big team, SVN and Trac in a LAMP environment can help any developer. Time permitting he will show some of his own live examples of using SVN & Trac. If you have a specific topics or questions you would like addressed in his presentation, please feel free to let him know on his blog.

Justin Carmony has worked in web development professionally for the last four years. With emphasis on PHP, .NET, and Web Services, he has worked on projects ranging from simple websites to complex communications between thousands of remote systems. He currently is working as an independent contractor & private consultant. If you have any questions, comments, or curiosities you can contact him (justin AT justincarmony DOT com) or read about his latest endeavors at his blog (www.justincarmony.com/blog).

We will have streaming as usual and slides will be posted early.

If you’re in the Salt Lake City area, and would like to attend, it will be at the following address: 12393 Gateway Park Place Suite 600, Draper, Utah.

If you’re not able to make it, but would still like to listen in & participate via IRC, check out the UPHPU’s live meeting page. If you have any specifics on what you would like to hear, or have any questions that you would like me to answer in my presentation, leave a comment below.

Related posts:

1. Web Development 10-Years Ago & Now
2. Zend Studio vs PHP Development Tools
3. iPhone Web Development: Controlling the viewport via Javascript