Last week I had a catchup meeting with a client about the progress of a platform I'm building for them, and showed them how the "devops" side of things works. Demoing it really struck me how insanely awesome all the tooling we have nowadays is, and also how much I take it for granted!
I've worked with quite a few companies now - both as a permanent employee and as a contractor/consultant. However, up until now, I haven't worked with a team who use Pull Requests for all code changes. Whilst I know the PR model well through GitHub and open source - I hadn't previously used it within an actual workplace.
I quite often hear experienced Git users say that you should always use the command line for Git, and you should try to avoid using Git GUIs. Whilst I understand the reasons given, I also think it's a huge generalization that unfairly sees Git GUI users as unlikely to really understand Git properly. I certainly know Git very well, and honestly think I'm far faster and more efficient in a Git GUI than I could possibly be on the command line - and I'm certainly not slow in the CLI.
Up until about six months ago, all my commits have used past tense. For example, I'd write "Added ...", or "Fixed ...", etc. However, at my current contract, they have a standard where the commits use imperative tense, eg. "Add ...", "Fix ...", etc.
My last post was focused around a problem in Git which occurs when the rebase command isn't used, and developers blindly use pull/push. The problem is that it creates pointless merge commits, and also stops the Git history from being linear, ie. the branches are diverging and remerging back in all the time. It makes the history extremely hard to read and understand.
I'm a huge fan of Git, but have certainly found it has a bit of a learning curve when first starting off. Whilst I now feel extremely confident using it, there were quite a few 'aha' moments required to get here. Git gives you a huge amount of power and flexibly - but it is frustrating that unless all developers working on a codebase properly understand it - especially rebasing - then the codebase tends to have LOTS of erroneous merge commits, making the Git history a complete mess.
I quite often use keywords surrounded in parenthesis in my code as temporary todo markers for Resharper's
Todo Explorer. One common keyword I use a lot is
(nocommit) to indicate something is temporary and shouldn't be committed to source control. This is where Git hooks come in very handy to stop me accidentally committing these temporary changes.
I use a couple of different Bitbucket accounts, and in the past have mostly just used HTTPS to connect, but did find that I was getting prompted for credentials more often than I would like - even after telling SourceTree (my GUI of choice) to save those credentials.
Before reading this, I'd recommend reading my previous post, which goes into the core differences between different Version Control System (VCS) features, with a very strong emphasis on Git.
I started off intending this post to be about the opensource Git-Tfs project. I've used Git at home for both personal and freelance projects for quite a few years, but at work we unfortunately use TFS2008. To allow me to use some of the power of Git at work (at least locally on my computer), I've turned to Git-Tfs.
I quickly realised that in order to explain my reasons for wanting the extra functionality of Git over TFS, I would first have to explain how some core features differ in different Version Control Systems (VCSs). So I decided to split this into two posts - one about Git and VCSs in general, and the other about Git-Tfs. The second post about Git-Tfs can be found here.