Git master repo branches

Question

If a group of 8 people are working on a project is it needed to have separate branches for all members?

If so

1. How does one branch the master repo.
2. what happens with merging between branches?
3. How will each member have the latest code from the rest of the group?

Could having individual branches cause more problems than if each member works on the same repo, but still on their individual files?

Answer 1

I say have a master branch, a develop branch and then various branches for features and fixes, not team members. Think about how you will want to deploy and manage the code in order to find your best repo management strategy. With 8 people you'll presumably have a lot of commits. If you need to sort some code out from two weeks back will it be easier to figure "Evan wrote this so it'll be in the evan branch" or "it's the broken menu item so it's in fix_menu branch". When tracking something down and you find the branch, then you'll need to find the commit(s) and follow through the merges. What if another person stepped in to assist on a feature?

1. Ideally master branch is always production worthy so you don't want people merging their changes directly to that. Thus the develop branch. One person's code may work like a charm as they write it but then have issues when integrated back. The develop branch (like a staging/dev server) is the place to discover those issues leaving master as pure as possible.

2. Merging is pretty simple. There are only conflicts when the same code block differs between the two commits being merged. Git marks and makes you sort out the conflicts before continuing the merge.

3. Git uses push/pull to send and grab commits. You push your changes out and git will alert you if there are newer changes in your destination. Pulling is actually two operations - fetch and merge. Fetch says get me the latest of this branch or the latest of all branches from the remote repo. Fetch doesn't touch your current branch so it's safe. Pull will both fetch the latest and then try to merge it into your current branch.

You can also setup tracking branches. git branch --track <newbranch> origin/develop This way people can spin off a feature branch while being able to easily pull in the updates made on the develop branch.

Another good tip is to get used to looking at commit log visualizations so you know how various scenarios appear...when three developers are working on the same branch it looks this way...a merge makes the viz-line looks like this.

If your team is new to git, I would start out with a single repo maintainer. Things will get messy fast if everyone is learning. Let one person manage the master branch. Communicate branching and keep an eye on develop. As a next step, practice rebasing with squashing. Remember that all commits will exist in the linear history of a branch - so when you merge a feature branch into develop, all those useless little "work-in-progress" commits will clutter up the develop timeline. Squashing and then merging keeps the history clean (and helps prevent rollback to an incomplete state).

Answer 2

This largely depends on your development style, whether you have one person responsible for merging everybody's work and making things correct, or if you spread that out across your developers.

Because every clone is essentially its own repo, all your developers do get a "branch" of sorts, the one in their clone. They can further branch if they want, but when it comes time to push they will (by default) have to make sure their changes are linear with any changes on the central repository (if you use one central repository as the overlord).

As for your questions:

1) If you have a central bare shared repo you can just make "git branch" calls within it to create branches. Alternatively each developer can create a branch from master in their clone then push that branch up to create it.

2) merging between branches is pretty straight forward. If there are conflicts the developer will have to correct those during the merge and then that will be shown as a merge commit. If there are no conflicts then a merge will just appear as a series of commits being added to the branch.

3) If using the central repository setup, each member will periodically be doing "pull"s from said repo. Any new branches created or any updates to existing branches will come with that pull so that they can be sure to have the latest (shared) data. Otherwise one developer could request that another developer pull directly from their working repo to get access to code in progress for collaboration.

In my opinion, each developer having explicit individual branches in a shared repo may be more complexity than you want, unless you have somebody specifically tasked with merging changes from each developer into a production branch (or master). Just make sure each developer knows to pull (--rebase) before they try to push their changes up and re-test their changes if anything has changed in the shared repo.