Centric connect.engage.succeed

The Git (a) way

Geschreven door Redactie Craft - 19 juli 2016

Redactie Craft
One day when I was happily hacking on some code in my Visual Studio editor, my eye fell on a small hyperlink that read ‘Git’. As the mouse pointer was lingering over the tiny link – just three letters – I pondered: what the heck does that do in my Microsoft editor?

Git is an open source version control system, used by those Linux guys. Isn’t it? For a moment my curiouser – albeit not wiser – self implored me to push the link and find out why it was there. It was on the TFS team explorer page, so it must be the GIT I was thinking about. But then the workload kicked in again. And I forgot about it for some time.

But although it was removed from the usual 4K memory that I use in everyday life: It never went away. And a half year later when I had to convert a large software project from Subversion to TFS: I remembered. And it was a life saver. And… it gave me the first reason why to use the Git system in my organization. This blog is about that reason. And all the other reasons why to use Git and to what purpose. Oh yeah: and for the very, very concerned managers that I spoke, I’ll throw in some downsides why not ;-)

Conversion to TFS

Okay: how did that happen? We had a large software project with over one and a half million lines of legacy source code that we’re still maintaining. It sat for the last ten years or so in a subversion repository on an old 200mHz PC box in some corner of the IT department. It even had a name: “Bob the Builder”. An old doll of the same name was sitting on top of it. You could shake it and a mechanical voice would shout “Can we build it: YES WE CAN!”. You guessed it: it also was our old build system way back in the nineteen hundreds.

Can you convert that to the modern TFS environment? That was the question they posed me. Yes I can! (Not my wiser self!). So I had to try to figure out some way to convert it to TFS. But that was not as easy as it seemed. Conversion software from Subversion to TFS happened to work only for small projects or freezed halfway conversions.

This was the first time Git came to the rescue. You can convert Subversion – including history (!) – to Git. And from Git, you can convert your project to TFS. Easy peasy. Git has a lot of conversion plugins. They’re all over the internet. You can convert almost anything to and from Git. After that first conver¬sion I did a lot more conversions. And in the process made a lot of managers happy by converting just about everything to the company wide TFS system.

Off lining

The new flexible way of working in modern society is not always from nine to five at the office. Lots of our colleagues work in commuter trains, on airfields, on the plane, some even on a holiday if their still working co-workers hit a wall. We work a day at home because the highways are filled up. We wait for one or two hours before ‘coming in’. Nowadays in the world of Windows 10 and direct access, and a glass fiber connection at home that’s no big deal. But the train or plane?

Off line working with a source code repository that’s made by design to be always online and centralized is a headache. The moment you hit the button to change a line of code: bang. No connection. Checkout of the file is not possible.

There goes your train of thought. You thought you had it nailed. And now you have to deal with your connection, file read/write attributes and those lowly real-world things you just forgot. What the… okay let’s sort that out…. Okay your good to go. Where the hell were you? Wat did you just think of? The moment you hit that first key when you wanted to change that line of code? It’s gone. Now you have to retrace your steps all over again, process everything and after 10, 15 minutes your back on track.

It’s a horror. But again: Git kicks in to the rescue. This is what you do: pull down the project you are working on in Git. Git builds a local repository. Set the complete directory tree to read/write in one go and code away. No more read/write blocks. And if you make a mistake. No sweat, the whole repository is there. You can undo your own stupidness and silly mistakes if need be. And after coding: ask Git what you have changed, stage it, check it in, and then push it to TFS. Okay that was a lot. Three steps instead of one. And there are a lot of details in those steps. But there are shortcuts. And after the first few mistakes it becomes easier. But it’s a great experience for working off-line.

Borrowing from open source

Yes we (Centric) build propriety source code at our companies premises. But we sometimes borrow from open source. Not the GPL stuff, but more the public domain thing. The MIT or Apache type licensed projects. Today’s software is filled with it. And a lot of it is on github. And that’s where we use Git. So you need the Git system anyways to download the last versions and to see what’s going on. And the best part is: if you think of an improvement, you can share it. But you share through the Git system. Publish your improvements there is the social thing to do. Give something back to the community, as the community has given you so much. Oh! You do that in your working hours? No! Sadly I do that at night or in the weekends. In my off time I share it back to the community. On github, on codeproject and on sourceforge. Guess what? It feels great. I posted some projects on sourceforge and forgot about it. Until I got an email from a curious downloader. And I was absolutely astonished! What! 60.000 downloads?

Building a POC

As an architect I often get asked a lot to explore some new grounds. Build a ‘proof of concept’ (POC). Because the management want ‘proof’ before deciding. So you sail away and code away for a while. Hopefully not in vain and not for the proverbial drawer to dwindle in. The code you write might even be used later on by ‘real programmers’ in a real world system!

But the thought process does not work from nine to five. It works all the time! In the car, under the shower, at night, on the loo, in the supermarket. The best ideas are not formed behind a desk. And what better then to write it down right away. In former days, thinkers would carry a writing pad around, or a notebook. But I carry my Git around. Write it down, check it in. Placing it in a cloud space, MyDrive, Dropbox, or whatever available.

Interlude: my managers asked me to write down that all my source code in the cloud is encrypted, locked, AES hashed etc. Just in case somebody begins about security, privacy and the crap. And I did sign an NDA!

Okay. We’re good to go! The POC has been accepted. What now? I take the Git repository that I’ve dragged along with me for so long and push it to a TFS project somewhere in our companies repo. For the company the policy is “TFS unless…”. An email to the new project guys and I’m done. That is: I’ll wait for desperate and high pitched emails to do some explaining….

Overly complex but flexible

Let me state it here: Git has a downside. It is complex, very complex! Too complex for the most average developer. But it is very flexible. And in order to be flexible it works completely different than most centralized source repositories. And it certainly requires a mindset. Reading the Git book is considered mandatory. The good thing: it’s free (like in ‘free beer’). But the mandatory thing is no joke. There is no such thing as a Git user interface or GUI. There are some tries, but they all miss important parts. At the end of the day, you’re on your own looking at a command prompt. It really reminds you of the good old Unix days.

Life is easy in TFS. You check out a file or multiple files, change them and then commit it back to the repository. Others can then ‘get’ your changes. Or you can get there’s. But not in GIT. To begin with: repositories live in many places on many machines, and changes live in many more places. To begin with an overview: this is how Git sees the machines after ‘pulling’ a repository.

Each computer holds a version database or repository, has a staging area with ‘staged changes’ and working directories with tracked and untracked files. You can checkout a project to a working directory, but you must (hand picked!) stage all changed files to the staging area. A commit will then update your local repository (but not the server repository: that is a ‘push’ operation).

And it even gets worse. Working with files under the staged area, is even more complex. You can have modified, unmodified and untracked files. They are all available.

A good example of an untracked file is the build executable that we are trying to build and accomplish. Untracking and ignoring files is a whole new ball game, requiring a ‘.gitignore’ system file.

The good thing with all this complexity: you can do things you cannot do in TFS! And that’s where the next paragraph comes in.

Working with products not designed for TFS.

In the HTLM5 / AngularJS world, a lot of JavaScript (Oh sorry Microsoft guys: ECMA script) tools are used like NuGet, bower, gulp, grunt, typescript and the like. Alas! Not all of these products where originally designed and written with the MS-Windows operating system in mind. And certainly not with Visual Studio in mind. File paths longer than 260 characters are quite common and causing their own problems. And causing their own integration problems with TFS source control and even break havoc on the build systems. Because files with names longer than 260 characters are not easily removed from MS-Windows. Overflowing the build systems drives, and creating headaches for the system administrators.

Last month (June 2016) when the third update of Visual Studio 2015 did hit the streets, things are getting better. It integrates better, TFS has its own “.tfignore” and the like. But before that: checking out on Git and building away from TFS was the only way to not get into trouble.

So for the future: lessons learned! If you want to break away from MS-Windows restrictions: there’s an alternative. And Microsoft is now also deploying there .NET C# Core system to Linux and the Mac. Hello new world!

Microsoft products on Git

Speaking of which: a lot of Microsoft’s new products live on github! The dot net framework, the C# compiler set, over 750 projects in total. And its growing rapidly. Oh I hear you thinking! I do not need Git, I can just download a zip file with the whole shebang. But that’s not the community way to do it! I warned you guys. With a Git checkout, you can have the latest and the greatest. And you can – and should – share back to the community if you improve the thing. Whatever ‘the thing’ is.

Outsourcing project for customers

Not all of our coworkers are programming here on the premises. A lot of them get hired away, outsourced, on projects for customers. And rightfully so! They make more money than the home bound programmers here within the premises of the company. But how to cooperate and work together? That’s a different story. Mostly they don’t even get a Visual Studio from us, but from the customer. How to share? How to discuss the finer points of those few lines of code where we programmers shine?

It’s not only that they are away for most of the week, but experience physical boundaries as well. DMZ boundaries, internet firewalls, service centers that are not cooperating and the like.

You can share a zip in the email. That is: if you know how to circumvent the virus scanners and extension scanners of the email servers. But after 3, 5 or even 10 zip’s flying around, you lose track. At least: my short memory does. I admit it. So how to cope?

And again: it’s Git to the rescue. Wrap your code in a Git repo and share it through the internet or the email is a handy approach. You can fly it over again and again, adding history to the tiny filesystem that a Git repository is. After doing this a couple of times, and saving me the errors by looking at the history inside the repository, I was sold. Never zip or RAR again without a Git repository.

Aftermath

Yes: you can get away with GIT in your organization. It will and has raised eyebrows over the last couple of years, but the world is changing. Getting opener. Easier. Taking care of NDA’s, closed source and boundaries: there is a way to get away with (G)IT.

*) Figures in this blog are from the “Pro Git 2.0” book, published by Apress in 2014 under the creative commons license.

Tags:ALM

     
Reacties
  • Thingks
    Henri Koppen
    20 juli 2016
    (disclaimer: I might not read answers since there's no post update mechanism, my email is h.koppen@thingks.nl)

    Very nice read! And as a former .NET techie I recognize a lot you write.

    I use SourceTree as a handy GUI (and yes not complete), also two GIT providers -Github and BitBucket- have browser consoles with graphical elements. For the PRO's the terminal is perfect, for lesser god there are some gui's :-)
Schrijf een reactie
  • Captcha image
  • Verzenden