The Artima Developer Community
Sponsored Link

Java Buzz Forum
Don’t move to Git

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Mathias Bogaert

Posts: 618
Nickname: pathos
Registered: Aug, 2003

Mathias Bogaert is a senior software architect at Intrasoft mainly doing projects for the EC.
Don’t move to Git Posted: Nov 13, 2013 12:29 PM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Mathias Bogaert.
Original Post: Don’t move to Git
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
Latest Java Buzz Posts
Latest Java Buzz Posts by Mathias Bogaert
Latest Posts From Scuttlebutt

Advertisement
So, you’ve heard all your hipster friends raving about git. They say it’s the latest and greatest, and you simply must try it. What’s the real story here? I’ll tell you. Speed is overrated You’ve heard that git changes the way you work; most operations are local and blazing fast, blah blah blah. Do you really need all this speed, though? How long can it take to carry out an svn update in the morning? Five minutes? 10 minutes? Are those minutes really that big of an issue? Switching branches in subversion might take a few minutes, too. But really, if you have more than two branches, you’re doing it wrong. And please don’t tell me that those few extra seconds you have to wait after each commit or update add up to anything more than just a tiny inconvenience. Get over it. Who needs local branches? Cheap local branching – git has them. But why would you need local branches? You’ve been committing to a remote trunk for years and everything has been great. Yes, your team meshed everything together: fixes, new features, proof of concepts. All in the trunk. Sure, sometimes you have to keep uncommitted changes on your machine for days. But if it works, why fix what’s not broken? “And no, it wasn’t me that broke the billing system. I just fixed a typo in the About page!” How could you possibly know that there is where the main USD/EUR conversion was happening? You work with such amateurs! The old workflow has worked until now Workflow innovation? Efficiency? Pssh, nonsense. Processes have finally been grokked. You have your procedures and they just work. They are documented. You might lose your ISO certification if you make radical adjustments to the way your team works. Trust me – I had to sit in five architectural board meetings to decide whether to switch from Notepad to Word. Word won by one vote. Centralized is safer Do you really need a decentralized version control system? Of course not! You have an IT department for a reason – to separate concerns and lower costs. Let your DevOps people make sure the central repository is backed up. Why would you need the whole history of the project locally? Are you really going to check who did the first commit on the project? Merges should be avoided anyway git is good with merges. git is good at branches. git is good at everything. Aren’t you tired of hearing the same thing over and over again? Let’s be honest: You shouldn’t be merging because you should not have more than one or two branches anyway. A single trunk in most projects will do! But let’s say you really need branches, maybe a release branch for some very important upcoming release. Isn’t it easier to have a person – or even better, a team – dedicated to merge code and resolve conflicts? Somebody familiar with the process? They can look at diffs and email the relevant persons in the company on how to resolve them. Again, if it ain’t broken, why are you trying to fix it? Yeah, […]

Read: Don’t move to Git

Topic: 2014 will be the year of data Previous Topic   Next Topic Topic: Mobile browsers lag, so mobile HTML5 apps suffer

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use