Here is, roughly, our structure of work using git, for web development. We have a master branch, and individual or groups of work are done seperately in branches, then merged in.
- A ticket (or several) comes in.
- We create a branch on our local development repository, and push it to origin.
- We fix the tickets in code, commit the work and push to origin.
- Once we're happy with our work, we pull the branch down to a repository on our UAT / Staging server and check it out for the client to review.
- The client approves the work.
- We go back to our local development repository, we check out master, merge the branch, and push to origin.
- We create a tag from master afterwards.
- We then go on the live server, pull master and move/update the tag to the new one.
There are 7 of us, working on about 15 projects or so throughout the year. Generally, one person is sufficient to work on a project at any one time, but sometimes two people might work in separate branches with a view to merging into the master branch around the same time.
Generally we think merging is best because it, as I understand, preserves a development history with regard to what was merged and when. Whereas rebase seems to completely destroy this and linearize the master log.
Why would, if this assumption is correct, someone want to use rebase? Is it only for extremely busy projects that are constantly being branched and merged and there needs to be a guarantee that merges are successful - so developers can test out adding master to their work and resolve conflicts before merging back in?