I've recently setup some of my various config files to be source-controlled in a Github repository. Here are some examples of what I mean by config files...

How many times have you been working in a Git feature branch, and come across something in code that you want to change, but isn't related to the feature your on? Perhaps a code tidyup, or fixing some unrelated warnings?

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.