![\"\"](\"http:\/\/10kdev.net\/wp-content\/uploads\/2014\/05\/eed4341e49cc3e1aa8c7d924e4415e89.png\")
<\/p>\n<\/p>\n
So — you are using distributed repositories (DRs) like Git or Hg. \u00a0 And you are thinking — why the heck use branching? \u00a0Branching is great for local one-offs but I can copy\/paste for that!”<\/p>\n
I admit that I have struggled with this questions as well — for instance thinking that SVN is just as good of a tool for developers. \u00a0IN the beginning people pushed these DRs but we never, ever used them in the manner that they were intended; they were just shiny new toys. \u00a0Some of us, me included, took a lot of guff for not being the earliest of adopters. \u00a0After a lot of hands on over the years, working with these repos the correct and incorrect ways I finally have solid arguments for using distributed repositories, especially when it comes to branching.<\/p>\n
Note this is *not* in any way an anti-SVN post; that repo has great tooling and was revolutionary when it came on the scene. \u00a0You can even use plugins like git-svn with some success in front of a central SVN repository; and in many ways I find build masters preferring its branch and tag methodology. \u00a0But I would argue that from a developer’s standpoint a distributed is tough to beat.<\/p>\n
For me the definition of fluidity is how much something aides your development process. \u00a0A DR seems in the way at first with the double-check in steps . . .check into your local, check into your central. \u00a0But once a developer sees the advantage of the local repo it becomes much easier to create batches of changes locally and then push them up to the central repo. \u00a0(Central repo is usually where the build server points and everyone agrees to push to). \u00a0DRs accept the merge bumps we all run into and make it part of their process . . . so development becomes something with less in the way. \u00a0You can worry less about the checkin \u00a0process.<\/p>\n
Also, their is the speed of creating and switching between local and remote branches in a DR; uber-fast. \u00a0This alone in hands-on makes these tools worth it.<\/p>\n
Have you ever had to work on a branch in SVN? Check out the whole thing and switch workspaces with your IDE — what a pain. \u00a0With Git (for instance) I just issue a git checkout branch<\/em> and nothing else needs to be done. That’s as easy as it gets. \u00a0Adding and committing are all as easy as any other repo.<\/p>\n One thing is with RVs is that it’s also *easy* to get into trouble with merging and getting code out of sync. \u00a0These systems are more sophisticated so that’s part of the problem. \u00a0Git has the merge\/rebase \u00a0wars, and a lot of time in Hg and Git you’ll see unintended branches pushed out by new users. \u00a0This is OK, it takes a while to learn. \u00a0Make the learning process easy. \u00a0All too often I see an experienced person blowing up on a newb forgetting that they too usually can’t write documentation and probably made the same errors.<\/em><\/p>\n But — the flow makes you do small commits; this in the long run helps keep you out of trouble. Easy!<\/em><\/p>\n Remote branches are SO simple with a DR. \u00a0Since they store their diffs much differently — and SVN has to create whole new copies of directories, the speed is so slow comparatively. \u00a0Team members can share remote repos in seconds, and with Hg and Git you can fire up local servers<\/em> in your local directory for sharing right away sans central server.<\/p>\n If you sit down and work with the tools — SVN, TFS vs DRs it doesn’t seem obvious off the bat how this might work. \u00a0I have some use cases below that, when you run into them can immediately see how useful sharing becomes outside the central repo; it is very powerful and not immediately obvious to non-coders as to why.<\/p>\n I mention this because often non-coders get to pick the big tools: people like management, paper architects, PMs and build masters, maybe even QA. \u00a0Their input is important, but as a developer not always relevant for *doing* the work. \u00a0I guess that’s why there is git-svn as a compromise and\/or transitional tool. \u00a0Sometimes newer management and QA tracking tools, Rally for a while, only worked with more legacy repositories like SVN and TFS.<\/p>\n I am a combination command line\/UI person. \u00a0For instance, I always make sure my build scripts can run on the command line (as will the build server) and<\/em> in my IDE which is usually Eclipse, sometimes IntelliJ. \u00a0 \u00a0You can get intra-build errors that are difficult to debug if you don’t master this. \u00a0With a DR — you simply get more tools. \u00a0The command line options for Git are endless; I love the interactive staging UI on the command line (git add -i); I also use Tortoise for eyeballing all my files, it lets me add\/commit at the same time; the log and branch viewers are fantastic and picking out commits its simple. \u00a0The amount of commit history is great as well.<\/p>\n In fact DRs really make you think beyond coding as to how you push forth your code.<\/p>\n —<\/p>\n Commit types:<\/strong> Build masters and managers are more concerned with feature pushes and rollbacks on a macro level; developers with micro commits and history. \u00a0I find DR tooling makes this workflow much simpler.<\/p>\n Branching: <\/strong>A lot of times when there is a large test suite and a refactor or major requirement change must go in a lot of those tests and other code will break. \u00a0The main build must not break<\/strong><\/em>. \u00a0 The best way to handle this, with ease, is to use a Git or Hg branch; make your changes while consistently merging trunk into your branch; anyone can work on it as well. \u00a0Fix everything, then merge back to the trunk (after a merge from trunk of course). \u00a0This is one of the most powerful and easy to do activities with a DR. \u00a0You’ll know it when it happens to you. \u00a0Many times you can do this by yourself with SVN by just not checking in and making updating from trunk; but you don’t get the ease of branching or the ease of sharability.<\/p>\n Postscript<\/strong><\/p>\n Using DRs properly and leveraging the features is not immediately obvious; you have to dig in and experience it to see why they might deliver more value. \u00a0SVN and TFS are certainly very adequate; I like SVN’s integration into everything there is and I like TFS’s concept of a shared shelveset. \u00a0Many build masters prefer SVN’s straightforwardness for *their* tasks. \u00a0And SVN was certainly maligned (to CVS for instance) when it first came out. \u00a0As developers we should avoid harsh orthodox judgments and see if something will actually put forth value or if we are just doing something for newness\/coolness sake.<\/p>\n It’s taken years to see the value for me because almost everyone doesn’t branch\/develop the same way on different sites. I guess that’s the lesson. \u00a0Again, deferring to SVN which was the first repo to put out this mantra while they were still hosted on tigress.org: “We don’t provide you with a process, just a framework to do YOUR process.”<\/em> \u00a0Brilliant.<\/p>\n And someday there will be something better anyway.<\/p>\n","protected":false},"excerpt":{"rendered":" So — you are using distributed repositories (DRs) like Git or Hg. \u00a0 And you are thinking — why the heck use branching? \u00a0Branching is great for local one-offs but I can copy\/paste for that!” I admit that I have struggled with this questions as well — for instance thinking that SVN is just as […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[],"_links":{"self":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/1122"}],"collection":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1122"}],"version-history":[{"count":6,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/1122\/revisions"}],"predecessor-version":[{"id":1128,"href":"http:\/\/10kdev.net\/index.php?rest_route=\/wp\/v2\/posts\/1122\/revisions\/1128"}],"wp:attachment":[{"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1122"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/10kdev.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Sharing<\/h3>\n
Functionality<\/h3>\n
Some Workflows<\/h3>\n