Gitk is a built-in GUI repository browser for Git.
There are options, but to begin with, just launch it by typing
It’s fast and handy if you just want to quickly browse commits or staged/unstaged files and don’t have an alternative GUI app.
Also a useful companion if you’re doing interactive staging.
You can instantly search full commit messages (matching commits will be shown in bold, remember to set IgnCase otherwise the search is case sensitive).
You can also use the touching paths option to look for files affected by a commit, and you can search by strings added or removed or changing lines matching.
There’s a second search box for finding things in the diffs.
You can modify colours, fonts and so on.
NB: Sourcetree has command line tools as well (so you can type
stree, though I couldn’t get them to install properly when I tried).
I’ve been trying Tailwind CSS recently. I’ll likely to continue using it.
People talk about Component First vs Utility First CSS frameworks – in my opinion the important word here is “first” – you should use your own best judgement to combine the two techniques.
- Start prototyping the design using atomic styles.
- Observe where you’re reusing the same styles a lot and/or it’ll be a pain (e.g. paragraphs of body text)
- Build components for these using
@apply in your CSS file (between
@tailwind components; and
- Don’t bother build components for things you are unlikely to reuse.
Does the HTML source code look a horrible with all those styles?
A bit when you very first see it. But:
- most code you didn’t write yourself looks confusing initially
- maybe your CSS file looks confusing close up too
There are several ways Utility First can save time:
- You’ll be switching back and forth between HTML and CSS rather less
- There won’t be as much friction in the early stages of building the site (you’ll be plugging in atomic classes and seeing the results straight away, you won’t be worrying about how to name things or constructing BEM selectors) – however you should keep an eye out for when you need to build a component.
- Obviously for a while you’ll be referring to the framework’s documentation a lot to learn the class names, but in the case of Tailwind CSS there’s an autocomplete search field on the site. The abbreviations for margin, padding, flexbox etc., once learnt, are logical and easy to remember.
- I find specifying code for screen breakpoints a lot simpler (typically I end up with lots of nesting in conventional CSS/SASS).
- No maths needed when building grids etc.
Can you still customise everything?
Yes. Your tailwind.js config defines everything – colours, breakpoints, font sizes, font families, leading, the grid etc. etc.
Who’s it good for:
- Developers who aren’t working in CSS every single day and can’t remember the intricacies of flexbox or grids.
- Anyone who doesn’t want their site to look like every other Bootstrap site (or any other framework that comes with pre-built components)
Can you still use it with SASS?
Yes (my typical build process for static sites uses Gulp and PostCSS)
There are two aspects to this, the CSS file size/download speed, and the speed the browser can process the quantity of selectors in it.
By default Tailwind will generate a very large CSS file with several thousand selectors. But with a little optimisation (turning off unused colours and screen sizes) you can dramatically reduce this. Also, the size is modest if served minified and gzipped.
Here’s a gulpfile.js, tested with gulp.js 4.0.0 and BrowserSync 2.26.3
It also uses the Tailwind CSS framework.
View example gulpfile.js on GitHub
Here’s a good beginner’s guide to Gulp (although the syntax for task execution has changed in 4.0.0, you need to use gulp.series or gulp.parallel)