git workflow: several developers, only 2 branches

Question

I've the following situation:

One internal server (server1) with the main repo with 2 branches master and dev, four developers with 3 clones of the git working with branches of the dev

Rules:

1. the server1/master cannot be touched or merged by the developers
2. every developers needs to update version of server1/master before work and before push

I think about that procedure: The developer 1 has to do: after git clone and maybe git pull, every day will be something like:

git checkout dev
git pull (for synch every modification from other developers)
git checkout -b myModification (for making a branch from dev)

after making modification add and commit:

git checkout dev
git merge --no-ff myModification
*git pull (for fetching  modification in dev made in the meanwhile from others developers)

after testing on dev branch:

git push origin dev

I would like to know

1. what is the best workflow definition for my problem
2. what are the git command for every developers
3. If the git pull is correct or is better to have git rebase -i dev or change the position of this command

thank you in advance

Answer 1

That's not a bad workflow for small shops where you trust every developer to check back to the dev branch on the server. It's basically what I do at home.

A more common workflow is for developers to push their changes back to a special "review" branch:

git push --dry-run origin dev:refs/heads/falk/dev
(satisfied this won't make a mess)
git push dev:refs/heads/falk/dev

Then I would ask the project administrator to merge the falk/dev branch into the dev branch.

If you have enough developers that it's likely that some of them will screw this up, the project administrator would set up permissions so that developer's can't push directly to dev.

By adjusting permissions and git hooks, you can arrange that a formal code review process be required before the merge can be done.

And finally, this whole thing can be automated by using Gerrit to manage the main repository. Administering that stuff is way above my pay grade, though.

OK, answering your specific questions:

1,2. Your workflow should work the way you've written it, although I personally usually wouldn't bother with creating the "myModification" feature branch since that only exists in the local workspace and it's a temporary thing anyway. Your developers may develop their own style.

So my own workflow would look like:

# start work, pull in any remote changes first
git checkout dev
git pull
(work)
# sync up again, just in case
git pull
git push origin dev:refs/heads/falk/dev
(ask administrator to do the merge)

git pull is the command you want to use. It may result in a conflict, which the developers will have to resolve manually.

git rebase can get you into trouble when pushing or pulling into other repositories, because it actually modifies the branch structure. You should only use git rebase in your own local workspace. Once you've pushed a branch to another repository, you should consider the branch structure to be "locked" and not modify it any more. Otherwise, you'll cause problems for the server the next time you push, and cause problems for the other developers when they try to pull.

Answer 2

For point 1: It looks like a typical topic branch workflow to me and in general is a very good idea.

For point 2: developers need to know and understand the basic set of git commands: branch, pull (--rebase), commit, merge for this workflow.

If you change your workflow to make developers pull in the latest set of changes before merging their topic back into dev there is a chance you can avoid rebase in the common case. The exception being that no one has pushed new changes to dev in the meantime, then a git pull --rebase becomes necessary. This should address point 3.

I would also amend the rules by: never commit directly on dev. The only thing you really want to see on this branch are merges. Why? So git log --first-parent dev gives you a nice high-level overview of your history.

Answer 3

Perhaps you should look around for examples of git workflows, e.g. the ones at Atlassian. The git in the trenches book might be useful, it discusses some examples of things to do (and how it can go wrong) for a fictional setup not too unlike yours. And don't forget to read your way through the git book.

One of the large advantages of git is that creating and manipulating branches is cheap and easy. Working on a branch and merging it into another, or grafting it on top, is almost risk-free. Switching branches is easy. Do take advantage of this. Let the developers work as they wish (one branch on their home machine or a dozen doesn't matter, it's a private decision).

Do insist that each commit be a single logical change (not "dump a day's work, to be continued tomorrow"). Learn how to take a string of changes (with backtracking, dead ends, illogically ordered changes) and create a clean, structured commit history out of it. Insist on clear, meaningful commit messages.

I'd take a less important project (some "nice to have," perhaps) to experiment a bit. Particularly if you are accustomed to another VCS, getting to grok git takes time working with it. Learn how to create branches and tags, learn about git stash, you will do something wrong sooner or later, and getting in the habit of setting up a fallback for the case I screw up badly has saved me a few times already...