5 Effective GIT Practices For Small Agile Teams

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.

But wait…

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:

  1. Reduces the chance of improperly resolved conflicts caused by “too much stuff” happening and “can’t remember” scenarios.
  2. Allows developers move fast. Deploying changes without lengthy, broken merges.
  3. Prevents unfinished features from showing up in production and “all hell breaking loose” in the worst possible moment.
  4. 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.

Working in a startup team is the best thing you can do as a developer

As a solo developer you’ve worked alone for many years. You tend to expect to take on the full load in every project. Then one day you end up in a small startup team.

You experience new emotions you never felt before. You feel out of sync. Everyone’s stepping on your toes. Touching your code. Shortly after you want to call it quits.

This feeling is normal. Learning to flow with a small number of other individuals is a little awkward at first. It takes some catching up on your interpersonal skills. It takes learning how to articulate code in the English language instead of in your head.

The most humbling, and maybe most painful, change you will make is learning to swallow your own pride and not compete for the glory.

You’ll grow as a technologist

Even if you don’t consider yourself a team player, working in a team is an enlightening experience. You’ll learn how to explain yourself and your code, and this will make you a better developer. For the first time, you’ll have to challenge yourself to write code that others can read. That also means writing clear documentation.

The synergy of your team will help you grow in leaps and bounds. Your team is like a support group. Each developer you work with will have something to teach you.

I have worked alone for years, but most of everything I know I attribute to someone more senior than me. Working in a team has helped me grow in leaps and bounds as a developer.

The organisational principles you’ll be exposed to will make you more organised, even later if you go back to being a solo developer.

You’ll learn to swallow your pride

Be humble. Help team mates find their strengths. Be an authority, not an expert. Let others say you’re the shit. Don’t rub it in. After all, you’re probably not as good as you think you are.

Letting everyone know you think you’re the best puts you in a bad position. Talk big and you’ll be caught with your pants down soon enough.

And remember, what you value might not be what everyone else values.

So shut up, work hard and wait for the praise instead. Put in value and grow trust.

You’ll find your strengths

Working in a team will help you find where you fit in and let you discover your strengths.

Full stack developers have the opportunity of digging into a little of everything.

This is your chance to find your specialty.

You’ll make valuable connections and find new opportunities

Working in a small startup is exciting because the organisational structure doesn’t block you from stepping outside you’re supposed role in the team. Small tech startups are often more open to new ideas and will allow you a greater amount of freedom than a corporate job in a large company. Large companies tend to put more restrictions on what their employees can do, even during after hours.

Actively search for other ways to provide value, outside of your role, to the startup.

In small startups, you have a much better chance of shining, of meeting connections that could potentially change your life. In bigger companies with thousands of employees, you’re just another one of crowd. Easily replaceable and invisible.

But don’t listen to me. I’ve never worked a corporate job. I’ve been hacking away in the wild since day one. Opportunities can be found in any setting. However, I prefer to avoid situations where I don’t have the highest leverage possible. In the end it boils down to, “is what you’re doing taking you to where you want to go?”

With any luck, you’ll find some great mentors

You’ll absorb a lot from your teammates. However, there are rarer key individuals in the startup scene that are even more important to you.

Those are the people that you run into who later become your mentors. Experienced developers and entrepreneurs are probably going to help you more personally than all of the books you can read on your topic.

This, maybe more than anything, is a reason to join a startup. Whichever benefits you’re lucky enough to come across, your own personal development will determine your success. Mentors will help you develop yourself in the right way. In the search for the mentor, a startup is the right place to be.

Adjusting to a startup team is a process

Being a solo-developer is fun and gives you the freedom to do whatever the hell you want. It means you have original thoughts and haven’t depended on a team your whole career to pick up your slack. You’re hustle is pretty fine tuned, or better put, out of control.

Solo coders hold their independance dear. They work through problems with a vengeance and more often than not, work more than they get paid.

Our biggest downfall is the trap of thinking our personal style is all there is. Joining a team will challenge you to mix the personal style you’ve developed with those of other developers. It will challenge your thinking and help you grow as a developer. It will give you a first hand into how digital products are successfully developed and deployed. You will learn organizational structure and how to be effective in a small company.

So when you join a team, make sure they’re crazy, weird and the type of startup that makes an attempt to try new things other startups are not commonly doing.

I joined a team that decided to build their system on Node.js and MongoDB. I wasn’t planning on taking on a new language or tackling a new technology stack. But I was interested in learning some new skills and getting first hand experience of how a small semi-successful startup operates day to day.

Find startups you can learn from and exchange value with. Better yet, find a company doing something new and doing it successfully. The last thing you want to do is to get stuck pumping out portfolio websites in Drupal for the next five years. Yuck!

More related reads you’ll enjoy: