Ever saw your code break and don’t know when exactly the bug was introduced? Zvonimir Spajic walks us through git bisect to find the commit that broke things.
I’ve used it myself quite a few times by now and it truly is really helpful in those situations. What I didn’t know however, is that it’s possible to have git bisect find the culprit automagically, by adding a checker-script using git bisect run <script> [<script args>].
If you are lucky and can write a script to check it for you then becomes fully automated.
The script needs to be outside of source control and return exit code 0 if the commit is considered good or 1 if it’s considered bad.
When building applications on build pipelines like GitHub Actions, Google Cloud Build, CircleCI, etc. every second counts. Here’s this small trick I use to speed up build times: when cloning the repo from its Git source, I instruct Git to do a shallow clone of the single branch it is building.
💡 If you’re running a prebuilt “git clone” step on your Build Pipeline it most likely already uses this trick. Be sure to double check though.
When doing a git clone you, by default, get the entire history of the project along with that. Take this clone of Laravel for example:
That’s a whopping 32004 objects totalling ±10MiB that have been downloaded, even though the default Laravel branch only counts 66 files spread across 36 directories.
The objects contained in this ±10MiB make up the entire history of every file and folder the project. To build the project we don’t really need all that, as we’re only interested in the latest version of each file and folder. By leveraging the --depth argument of our git clone command, we can enforce just that. This is what we call Shallow Cloning.
That’s a much speedier clone with only 108 objects, totalling a mere ±40KiB!
🤔 You could argue that 10MiB worth of objects is still OK to clone, but think of scenarios where you have a big “monorepo” with plenty of branches … then you’ll be talking about hundreds of wasted MiBs, if not GiBs.
Single Branch Cloning
When building a project you’re building only one certain branch. Information about the other branches is irrelevant at that time. To directly clone one specific branch we can use the --branch option to target said branch. With that alone we won’t get there though, we we still need to discard information about other branches. This is where the --single-branch option comes into play:
Here we’ve cloned only the 3.0 branch of Laravel, resulting in roughly 10000 fewer objects to be downloaded.
By checking the contents of git branch -a we can also verify that other branch info has not been fetched:
$ cd laravel
$ git branch -a
Shallow Cloning + Single Branch Cloning
By combining both we can download only the latest files of a specific branch. Since the use of --single-branch is implied when using --depth, we can drop the former and our command will look like this:
If you’ve ever wondered how Git internally manages commits and merges, Zvonimir Spajic (@konrad_126) has got you covered:
Creating branches in git is blazingly fast and having a bunch of them is pretty cheap. This means we get to merge them quite often. But how is a branch represented internally and what does it mean to merge them? Understanding how this works internally will help you understand why merge conflicts occur. Let’s dispel the magic.
I’ve seen Zvonimir bring the contents of this post forward during a talk at Full Stack Ghent. Very technical, which I enjoyed quite a lot.
GitLens supercharges the Git capabilities built into Visual Studio Code. It helps you to visualize code authorship at a glance via Git blame annotations and code lens, seamlessly navigate and explore Git repositories, gain valuable insights via powerful comparison commands, and so much more.
Just installed it and must say it’s really nice. Here’s an introductory video walking you through the extension: