Question

We are checking out git and would like to understand which workflow might suit our small team (4 developers).

Some details about what we do:

• We are working on a .NET product that is currently composed of 1
  repository with around 4-5 solutions, total of around ~ 70 projects
  and growing.
• We currently have 1 central repository with 1 branch.
• Each developer works on different code base areas, although
  occasionally will collaborate/modify other team member’s code area.

What is a “typical” git workflow for a team such as ours?

I would like to spend as minimal time as needed on “administrative” operations as possible.

For example, today we have seen that a git push request by a developer fails since another push was made before, and he had to merge changes locally using git pull first.

Is a typical scenario going like this:

Developer, commit locally.
Pull from git repository.
Push into git repository.

Can we not skip the pull? (have the merge done on the remote server?)

Currentlly we are using ClearCase, and this is resolved by merging during the push (“commit”) operation without the need to pull first.

Answer 1

First, I would recommend at least two branches. We call ours master and integration. Master is the current stable production-ready code base. This is what’s either in the customer’s hand or about to be submitted to the App Store (we’re an iOS shop). Integration is where we store our test-ready code. If someone asks for a test build, this is what we give them. Code here compiles and runs, but isn’t perfect. Depending on your deployment and testing process you can have as many additional branches as you need. Branches in git are easy and fast, there’s no reason to not have as many as you need.

Here’s how our process works:

1. Developer uses git pull to get the latest version of integration on their machine.
2. Create a topic branch off of integration. ‘git checkout -b fix-home-page` will create a new branch named “fix-home-page”.
3. Fix fix fix, code code code make a new commit every 5 minutes because commits in git are easy and fast. Once you’re done with your feature / bug fix:
4. Switch back to the integration branch and use git pull to make sure you’ve got the latest commit.
5. git merge --squash fix-home-page will pull in your branch in one nice clean commit and keep your history linear.
6. git push to shove your fixes back up to the main repo.

I like git merge --squash because it greatly reduces the number of conflicts. Other people like to use rebase, which will also give you a linear history and preserve all the commits from your topic branch. Use whatever suits you.

Finally, to answer your question: Yes, you have to do a git pull before pushing. Git is great about resolving conflicts, but if it can’t resolve the conflict then you need human intervention to figure out what should be happening.