Distributed version control systems (DVCS)

[fudje]

I'd say that workflow is over-complicated, at least for git.

Firstly, it's never necessary to keep a local branch of a mainline development tree that you don't touch, because git keeps track of remote branches at the same level as it does local branches. So instead of having remote master (read-only) > remote master (read-write) <> local master <> local topic1..n you can have something like remote master (read-only) > remote master (read-write) <> local topic1..n -- If you want to test the remote master without your changes, you can commit your current changes to your local branch and checkout the remote branch or master directly (into what git refers to as a "detached HEAD"). Similarly you can compare remote and local branches directly using eg. 'git diff'. This won't cost you any extra bandwidth, when you want to get a new copy of the remote branches, you can do so without affecting any local branch whatsoever.

Another thing to note is that superfluous use of rebase is not generally recommended. The reason for this is that what a rebase actually does is it rewrites the history of your local branch so that all of your local changes appear to happen after any remote changes that occurred, and if there are confliciting changes, ie. you and another developer working on the same region of a file, it quickly becomes difficult to recognise where the conflicts were resolved. Rebasing is primarily useful for branches where you pull the remote branch, perform and commit all your changes, get any updates from the remote one time, fix any conflicts, submit a pull request, and never touch that branch again. If you are performing a lot of changes to one branch over time, merging the remote branch in at frequent intervals and fixing merge conflicts along the way gives a clear indication of what had to be changed at what point, reducing the amount of work that has to be done when your branch is merged back into the main development tree.

On a bit of a tangent here, I'd also recommend against creating a fork using github's tools until you're ready to push some changes to it. Git can easily handle multiple remotes, allowing a mix of read-only and writable, and this also makes it easier to avoid having redundant copies of the master branch on your git remote. This is an almost entirely different workflow, though.