05 Nov 2020
Let’s face it – often you just need to get down and dirty, quickly sketch up some code to see if your idea of a bugfix or a feature is going to work.
Sometimes you can whip up some C# code using
C# Interactive window in Visual Studio, or an online
C# REPL (see this article for more info on that).
But a lot of times you DO need to make changes to your existing project(s), just because of all the other stuff, like DB access, authentication, other APIs responses, routing, dependency injection etc. that is needed to test your brand spanking new idea.
Also, you don’t want to accidentally break already working code and want to be able to roll your changes back quickly if it doesn’t work and you need to pull the plug on it.
Before we dive deep into the process, let’s have a quick overview of what it looks like. Here is a simple flow diagram:
This is very important: you need to make sure there are no uncommitted changes left hanging around in your working folder. If you have any modified files, you can do one of the following:
git commit -a -m "<your commit message>"
git stash, and when you are done experimenting and cleaning up, bring them back with
git stash apply
git reset HEAD --hard
Make sure you get the latest code of whichever branch you’re starting your experimentation. If
master is your stable branch, switch to it and get the latest code:
Now you are going to need to create a separate branch on which to experiment, so that your changes could be reviewed by other devs, and to avoid getting it all mixed up with any other changes.
Make sure to give meaningful names to your branches – something that conveys the purpose of the change you’re making. If it looks like your change is going to be big and affect lost of areas of the codebase, consider creating separate branches for each logically self-contained unit of change.
Now everything is ready for your grand idea – go ahead, write your code. It’s a good practice to commit your changes now and then, particularly when you get something to work the way you wanted. This gives you a point in your source control history to revert to if things break.
Now it’s up to you to decide if your experiment was a success - and as it often happens, we don’t get there right away, and that’s OK. It’s totally fine to put things on the back burner, put it all on hold, and give your brain some time to process things.
If you need to do switch to another task in the meantime, just commit whatever you’ve got and then switch back to your main branch:
However, if you are happy with the results, onwards and upwards!
Now is the time to commit your changes, get them reviewed by other devs. The review process is likely to result in more changes, and you might be repeating steps #4 and #5 a few times.
When the code review is complete, you can merge them into your main branch.
Alternatively, you may want to clean up your commit history by squashing all of the intermediate commits in your experimental branch into one succinct commit with a comprehensive description of all changes:
I hope this article helped you to learn how to use
git more efficiently and to freely
experiment with your code without the fear of breaking anything or losing your changes.
Liked this article? There is more where it came from – sign up to my mailing list and receive new blog posts when I publish them. I never spam or give your email to anybody, and you can unsubscribe whenever you want.