Describe your workflow of using version control (VCS or DVCS) [closed]

Question

I'd like to learn other people workflow when using either vcs or dvcs.

Please describe your strategy to handle the following tasks:

• Implement a feature
• Fixing bugs (during development and deployed app)
• Code Review
• Refactoring code (post code-review)
• Incorporate patches
• Releasing the newer version of your app (desktop, web, mobile, would you treat them differently?)

Feel free to organize your answer not grouped by the tasks but grouped by whatever you think is relevant but please organize it by VCS/DVCS (please don't mix them).

Thank you.

Herewith

Since by its very nature, this question won't have one answer that's more correct than the others, it should probably be a wiki. – Phraseogram

Are you asking solely about SVN and git? If so, please change the title. If not, please change the text. – Foliolate

Answer 1

The main feature all VCS use for the various task you are mentioning is branching: the ability to isolate a development effort in a collaborative way. Since it is a Central VCS, several developers can collaborate on a same branch, with pessimistic or optimistic locks on files, in order to develop a parallel history.

But being a VCS has two major impact on branching:

1. It tends to discourage commits, because once a file is committed, it will immediately influence the workspace of other views with the same configuration (i.e. "working on the same branch").
   ~ The "publication" process is an active one, with immediate consequences,
   ~ while the "consuming" part (updating your workspace) is a passive one (you are forced to deal with changes published by other immediately upon update of your workspace)
2. It works well for linear merge workflow (i.e. "only merge from branch A to branch B, not mixing merges in both directions" -- A to B to A to B...). The merges are trivial, all modifications from A are simply carried over to B

Now:

Implementing a feature

Any VCS will do that by making a branch, but what greatly surprised me is that a "feature" branch is not easy:
* the feature may grow too complicated
* it may be ready in time for the next release
* only some part of it may need to be merged back into the main development branch
* it may depend on other features which are not fully done yet

So you need to be careful in the way you manage your feature branch, and your commits: if they are tightly related to the same feature, it will go well (you merge the whole thing back to your main development branch when you need it). Otherwise, partial merges are not easy with those tools.

Fixing bugs

The difference between bug fix during development and after release is that, in the former case you can often do it linearly in the same branch, as in the latter case you will have to establish a bug-fix branch, and decide what bugs you will need to back-port to your current development branch.

Code Review

It is best used with external tools (like Crucible for instance), and uses VCS functions like blame or annotations extensively, in order to better assign code fixes after a review.

Refactoring code (post code-review)

If the refactoring is minor, it can go on in the same branch. But if it is big, a special branch needs to be setup, with unit-testing done before beginning said refactoring.

Incorporate patches

Same comment as last point. If the patch is a big one, a branch needs to be created.

Releasing the newer version of your app

A VCS will only get you so far when it comes to releasing your app, because it is not a release management tool.
You will need to formerly identify a version to be released (label), but after that comes the deployment process which involves:

• stopping what is currently running
• copying the new files
• deploying them (updating sql database, webapp, ...)
• instantiating all config files (with the right values, addresses, port number, paths, ...)
• restarting (and if your system is composed of several components, restarting them in the right order!)

The key things with VCS and release management are:

• they are not very well adapted to store binaries to be released, meaning you need them to build your app, not to store the resulting executable
• they are not always welcome in the production environment (where security constraints limit writing access, as well as the number of tools running on those platforms, essentially monitoring and reporting tools)

The release mechanism also has an influence on binary dependencies:

• for external binary dependencies, you will probably use mechanisms like maven to get fixed revisions of external libraries
• but for internal dependencies, when you are not developing just one app but several which depends one upon an other, you need to know how to reference the binaries produced by the other apps (internal binary dependencies), and they usually won't be stored in your VCS (especially in the development phase, where you can produce a lot of different releases for your other apps to be able to use)

You can also choose to be in source dependencies (and get all the sources of the other internal projects you need for your own), and a VCS is well adapted for that, but it is not always possible/practical to recompile everything.

Obellia

@Benjol: thank you for the numerous edits :) – Obellia

Answer 2

The main difference with a DVCS (Distributed Version Control) from a VCS, is that it is made (by the very nature of its distributed work) to do one thing, and one thing well:

merge.

So you the tasks you mention can be viewed from that angle.
Branches will still be made, but not all of them will be visible by other developers. Lots of them won't actually leave your local repository.

Being a DVCS has two main impact on merging:

1. you commit as many times as you want. Those commits are not immediately visible to others (i.e. "they won't have to merge them immediately after the next update of their workspace")
   ~ the publication process is a passive one: your pushes can be ignored by other repos.
   ~ the "consuming" part is an active one: you can examine what has been pushed to you before merging that to your branch, and decide what you want to merge and from whom (and not just because you are all working on a "same branch").
2. it works well for any merge workflow (partial, criss-crossing, recursive, ...) The DAG (Directed Acyclic Graph) often used to record the history by those DVCS (at least Git and Mercurial) makes it easy to find what has already been merged and find the common ancestor. That is one important difference between SVN and its DVCS counterparts, but there are others as well.

Now:

Implement a feature

As I detail in my CVCS (Central VCS) answer, the difficulty behind a "feature" branch is that many sub-features will end-up intertwined.
This is where DVCS will shine as they will allow you to reorganize their local (as in "not pushed yet") history (changesets for Mercurial, SHA1 commits ofr Git), in order to facilitate partial merges, or sub-feature branches creations.

Fixing bugs

You can almost create a branch per bug-fix if you want. The idea is to make sure a bug-fix is identified by a simple linear set of commmits merged back in the development branch (or the maintenance branch if this is released).
I prefer making sure to first rebase the bug-fix branch on top of the development branch (to make sure my fixes are still compliant with any work which may have been done in parallel on said main branch), before merging that dev branch with the bug-fix one (fast-forward merge: the main branch now reference all the fixes)

Code Review

The blame or annotation feature is still there to help assign the tasks during a code review, but this time, all the developers are not necessarily on one site (since it is a *Distributed *VCS), and not with the same identification scheme (not using the same LDAP for instance).

A DVCS way to organize code review is to push new changes to a special code review repo, which will:

• reject those commits if they don't answer to the required quality criteria
• accept those (merge them with the code-review repo), and push them to a new repo (used for various testing for instance)

Refactoring code (post code-review)

They are done on the developer's local repo, in a branch (since it is so easy to merge it back)

Incorporate patches

Same process than last section.

Releasing the newer version of your app (desktop, web, mobile, would you treat them differently?)

The actual release process is simply initiated by a special identified (tag) version of your software. (the rest of the "release management process", that is the deployment and configuration part is detailed in the CVCS answer)
The question is, with a DVCS:
"from which repository will that official version of your software come from?"

You need to establish a "central" or rather "official" repository which will play the role of:

• repo for versions to be released
• repo for new repositories wanted to contribute

So it can serve both for release purposes, but also for new development purposes.

Obellia

I wish I could vote 2 answers :) – Herewith

Yes, sorry about that, I accidentally clicked upvote (again) and turned out to be downvote with no way of going back to the previous state. Thank you for editing the answer. – Herewith

@vonc: Excellent answer, as usual. Is there a way to directly contact you? – Aric

@pablo: sure, write at "vonc at laposte dot net".I don't know much about Plastic SCM ;) As for your branching model (nvie.com/git-model), it reminds me of the one I refer to in my branching answer (https://mcmap.net/q/13137/-when-should-you-branch) in "How Software Evolves" (oreilly.com/catalog/practicalperforce/chapter/ch07.pdf) – Obellia

I am in the beginning stages of my career and am picking up the ropes of collaborative development. This answer of yours gives me the much needed insight. – Harriette