StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The main difference with a <strong>DVCS</strong> (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:</p> <p><strong>merge</strong>.</p> <p>So you the tasks you mention can be viewed from that angle.<br> Branches will still be made, but not all of them will be visible by other developers. Lots of them won't actually leave your <em>local</em> repository.</p> <p>Being a DVCS has two main impact on merging:</p> <ol> <li>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")<br> ~ the <a href="https://stackoverflow.com/questions/2563836/sell-me-distributed-revision-control/2563917#2563917">publication process</a> is a passive one: your pushes can be ignored by other repos.<br> ~ 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").</li> <li>it works well for any merge workflow (partial, criss-crossing, recursive, ...) The <strong><a href="https://stackoverflow.com/questions/2676302/arrows-direction-in-progit-book/2676634#2676634">DAG (Directed Acyclic Graph)</a></strong> 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 <a href="https://stackoverflow.com/questions/2692950/whats-the-difference-between-svn-and-git-for-merging/2692999#2692999">important difference between SVN and its DVCS counterparts</a>, but there are <a href="https://stackoverflow.com/questions/161541/svn-vs-git/2549128#2549128">others as well</a>.</li> </ol> <p>Now:</p> <h2>Implement a feature</h2> <p>As I detail in my <a href="https://stackoverflow.com/questions/2704996/describe-your-workflow-of-using-version-control-vcs-or-dvcs/2705214#2705214">CVCS (Central VCS) answer</a>, the difficulty behind a "feature" branch is that many sub-features will end-up intertwined.<br> 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.</p> <h2>Fixing bugs</h2> <p>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).<br> I <a href="https://stackoverflow.com/questions/804115/git-rebase-vs-git-merge/804178#804178">prefer making sure to first rebase</a> 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)</p> <h2>Code Review</h2> <p>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).</p> <p>A DVCS way to organize code review is to push new changes to a special code review repo, which will:</p> <ul> <li>reject those commits if they don't answer to the required quality criteria</li> <li>accept those (merge them with the code-review repo), and push them to a new repo (used for various testing for instance)</li> </ul> <h2>Refactoring code (post code-review)</h2> <p>They are done on the developer's local repo, in a branch (since it is so easy to merge it back)</p> <h2>Incorporate patches</h2> <p>Same process than last section.</p> <h2>Releasing the newer version of your app (desktop, web, mobile, would you treat them differently?)</h2> <p>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 <a href="https://stackoverflow.com/questions/2704996/describe-your-workflow-of-using-version-control-vcs-or-dvcs/2705214#2705214">CVCS answer</a>)<br> The question is, with a DVCS:<br> "from which repository will that official version of your software come from?"</p> <p>You need to establish a "central" or rather "official" repository which will play the role of:</p> <ul> <li>repo for versions to be released</li> <li>repo for new repositories wanted to contribute</li> </ul> <p>So it can serve both for release purposes, but <em>also</em> for new development purposes.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload