Using Git for collaboration on a 4 person project

Question

In one of my university projects I'm in a group of 4 developers tasked with developing a web application from scratch. We all have a very basic understanding of Git and decided to go with it for code base collaboration, we have a repo set up and everyone is a collaborator on GitHub.

For the last couple of months we've simply been cloning and committing to/from the master branch, and this has worked out fine. Lately however, there have been times where two or more people are working on the code base at one time and we often end up with some people being behind on commits and having to clone the repo before committing, which sometimes ends up in their changes being lost.

Today, one of the group members talked about having a "development" branch, which we all clone and commit to, and then merge into the master branch at the end of each sprint. We tried this, but didn't really see an improvement as we're still all working from the same code base, so the same problem as before occurs.

Someone else had the idea of forking (this is something new to me) the main repo, working on it and then sending pull requests to the main repo, which can then be merged in. This in practice sounds like a good plan, because the changes can be reviewed and fixes made if it breaks the code. That's how I understand it, anyway.

But as I said, we're all pretty new to Git and have a very basic grasp on the whole idea. What's the standard way of organising a team of 4 developers working on a Git repo? I've had a look into some of the Git documentation but it's all rather confusing for someone who only really knows how to clone and commit to a master branch.

Thank you for any help!

Answer 1

Talking about things being "standard" in development methodologies is dangerous because there is almost no such thing. Groups of developers tend to organise themselves in ways that work for them (or in the way that management tell them to organise themselves).

All of the approaches you have identified are valid ways of using distributed version control systems. I would suggest that you're not seeing massive benefit from the alternatives because you're working on a university-sized green field project with a small team of people in the same geographical location, speaking the same language, with similar abilities, and with similarly clear ideas of what the outcome should be. Git tends to shine when any of those are not the case.

For distributed projects where you really want one person to be acting as gate keeper to the canonical version of the project, pull requests work really nicely. When you want everyone to have effectively equal commit access, a development branch is a good solution. People tend to use development branches so that they can have an always-working version hanging around for people to use. I assume you don't currently have users, which is why you are unlikely to see much benefit from this approach.

I would basically continue as you are unless you talk to each other and decide that something is not working for you as a team, in which case you can decide if one of the other ways of working are going to be better for you.

Answer 2

You need to look into Git Workflow, and/or branching models. There are many, and here is one to get started:

A successful git branching model

You need to think about the notion of releases, staging, production and so on, because that can be easily represented. It's basically all about organization.