The common problem GIT n00bs encounter
Okay, so you decided to jump on the band wagon and use GIT for your projects.
You start hacking away, committing, pushing and all those wonderful things.
Everything is going great. You’re versioning your code, so you feel like a pro.
But then it happens. You start getting messages like, “Your branch is converged…” and “The following files contain conflicts…”
So you dive back into the GIT documentation, learn how to handle these simple problems, and keep going.
Then a few weeks later you decide to push to your team’s project and all hell breaks loose. You have twenty conflicts, you can’t remember what goes where and file structure has changed since your last push. So a merge breaks everything on your local and it all feels hopeless.
Meanwhile, the client is waiting to hear back from you. A line of sweat falls down the side of your cheek as panic sets in.
At this point you feel total hatred for GIT and all it stands for.
At this point you should have realized: This is all your fault.
I spent a lot of time in my early days with GIT repairing fucked up merges after spending weeks pushing code to another branch.
This had little to do with how well I had read and memorized the docs. This also had little to do with my lack of knowing every feature, command and configuration hack in the GIT toolset.
My downfall was in the simple actions I was performing every few hours during the work day.
It wasn’t what I was doing, but how I was doing it.
Getting religious about following (improved) GIT workflow was what changed things around for me.
There are many workflows you can go over. But consider this a simple step forward if you’re struggling to learn the basics.
Introducing: Simple, effective GIT practices
Time to get serious about your GIT strategy and your team’s use of it. Software projects can be brought to their knees without a good one. Seasoned developers will already have this nailed. This is for smaller, newer, younger startups that are still going through the growing pains of building a dev team.
These practices do the following:
- Reduces the chance of improperly resolved conflicts caused by “too much stuff” happening and “can’t remember” scenarios.
- Allows developers move fast. Deploying changes without lengthy, broken merges.
- Prevents unfinished features from showing up in production and “all hell breaking loose” in the worst possible moment.
- Makes changes easier to track and peer review.
Let’s get to it. The best practices for small teams learning to use GIT:
1. Commit often
How many times have you waited until the end of the day to commit and push your changes?
This not only makes changes hard to track and painful to revert, it also creates havoc during merges.
Commits are not meant to be giant chunks of small changes.
Commit often doesn’t mean every hour or every minute. It means, commit every time you make a describable change.
Changes that don’t belong in the same task, shouldn’t be in the same commit.
Think of a commit as a small task. If the task starts getting big, break it down into multiple commits.
Avoid ever committing changes of two tasks at once. It’s messy and glues tasks together that you might want to revert separately, or merge separately.
2. Branch your features and tasks
Have you ever run into this problem? While taking a few weeks to write a new feature, you tie in a few core fixes and clean up a few things on the side. Then halfway through, deploying a few of those fixes becomes a necessity. Maybe it’s because another feature has become blocked as a result of the bug, or you’ve created a new dependency in the process of writing the feature.
Correctly separating branches is your key to avoiding this problem.
If you’re writing a feature that you won’t be able to deploy for a while, you want to make sure any changes that affect the rest of the application stem from your master or parent branch.
You should get in the habit of branching everything that could potentially create an error. That pretty much means, everything.
3. Use pull requests
Pull requests are a great feature that comes with GIT. It gives you a huge advantage over simple merges and pulls.
At GitHub, pull requests have become the key method of contributing to open source projects. Simply, fork a repository, make the changes you want and send a pull request to the author. From there, they can review your changes, discuss what you did and make sure your code meets their standards before pulling it.
Simple pulls/merges can become invisible and unregulated. It’s difficult for team members to guess at what’s going to break if your merge goes bad.
With pull requests you can get other team members to peer review your code before pushing it live. It also makes testing and reverting new features much easier.
4. Keep master stable
The master branch of your repository should always be kept clean and stable. Think of master as the root of all of your stable code. Master should be the latest stable version.
Branching off from master, you can work on new features and test them in safe place. However, once it’s time to merge to master, your responsibility becomes making sure it’s not going to cripple your master branch.
Using all of these beta branches allows you create beta versions on other branches. This way you prevent ever having an unstable master branch.
5. Branch major release versions
Once you’re ready to release a new major version and continue to another, you simply pull in new stable changes, branch a new stable and continue working on master.
You will eventually run into the need to continue support for a specific version of your app. Since you’re keeping master clean and stable, it becomes simple to release new stable versions as you go, simply by creating branches based on master.
Each release branch then allow you to perform hot fixes and develop version specific features, then merge to the release when stable.
All of this separation creates freedom to move around and decreases the chances that you’re going to screw a live app/site up because of a core change or bug fix gone wrong.
Make GIT your asset
Once you learn to use GIT to your advantage, it becomes your greatest ally. Especially in a team of developers. Try the above in your own projects. Then bring them to your team.
I’ve found that development gets easier when you invest the time and effort into maximizing your effectiveness in GIT.
Hopefully these small tidbits I’ve learned can help you and your team work more cohesive.