Tim Allen on 22 Dec 2018 07:31:35 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[PLUG] Git: net time gain or loss?


I can't imagine working without git. I've gone through RCS, CVS, Subversion, Bazaar, Mercurial, and finally git, and it has gotten things as right as I've seen a VCS do. It has warts, but given the adoption rate of git vs anything else, I've learned to live with some minor annoyances... like any technology. There are few technology sectors that have such a clear winner with the populace than git in version control. Text editors, shells, operating systems, even Linux distros all have several contenders, whereas git dominates the VCS landscape.

I work on small, medium, and large projects. I've got quite a few commits in Django, which is a huge project with thousands of contributors across the world. Our git workflow strategy has evolved over the years, as we actively try to encourage new contributors, but also like to have training wheels for them. On the flip side, we like to have a workflow that works for a project of Django's size, and keep our most frequent contributors happy as well. Django has over 25,000 commits across 45 branches in the main repository; that doesn't include any forks! So it can and does scale.

The ability to tie in automated tests through GitHub which gently nudge people (myself included!) in the right direction is huge; I realize this isn't a "git-only" feature, but the user experience GitHub has put together for CI tools is unparalleled and improves overall code quality. The user experience of seeing code pushes in line with discussion happen in real-time is just cool to see in action. It makes the code base feel like a living, breathing art form.

I work with Bitbucket Server / Stash (on-prem Bitbucket), GitLab, and GitHub on a regular basis, and am mainly a command line basher. I'm not a fan of git GUIs - there's far too much power tied to interface elements, where selecting a single checkbox to try to "make something work" can create issues. With great power comes great responsibility, and learning the git toolbox is key, which I firmly believe should be done at the command line. The ability to create aliases for the more arcane commands is useful. You'll see I keep quite a few in my home directory; see here: https://github.com/FlipperPA/home/blob/master/.gitconfig and here: https://github.com/FlipperPA/home/blob/master/skel/bashrc-vagrant#L76

My favorite bash alias is `gitohshit` which outputs a command to go back one step after an "oops" moment.

The fact git commits are just deltas is a huge win over previous version control systems which would make entire copies of the code base when branching; this is what drove me away from svn, where branching on large code bases becomes useless. The merging is smarter than any system I've seen previously, and continues to improve. It ain't perfect, but IMHO, it's the best system out there for version control. Code and configuration not under version control is fundamentally broken.

As for the question of time: yes, revision control adds time to the process. So do code comments, proper documentation, and tests. But haste makes waste, and in my experience, the benefits far outweigh the time investment that becomes second nature after a while.

Regards,

Tim
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug