Like many things in git, zdiff3 is one of those hidden features that I wish was set as the default option. It has made my day to day development much easier when it comes to resolving conflicts and it's a nice little improvement over diff3. If you want to enable zdiff3 by default on versions of git >= 2.35, you can run git config --global merge.conflictStyle zdiff3. If you just want to give it a test run next time without setting that option to see if you like it you can also run git checkout --conflict zdiff3 ./conflicted/file/path to checkout just the one conflicted file again with the zdiff3 algorithm.

So it’s long overdue that major libraries and services like GitHub are reconsidering the use of terms like “master” and “slave”. (Django actually replaced them six years ago to use more accurately descriptive terms.) Whether or not they are intentionally rooted in the metaphors of Black enslavement, the plain fact is that living people have clearly stated that the words make them uncomfortable. Our intent matters much less than our impact.

Git is hard: screwing up is easy, and figuring out how to fix your mistakes is fucking impossible. Git documentation has this chicken and egg problem where you can't search for how to get yourself out of a mess, unless you already know the name of the thing you need to know about in order to fix your problem.

So here are some bad situations I've gotten myself into, and how I eventually got myself out of them in plain english.

GitHub has just beta-released GitHub CLI, an open-source tool that allows developers to work with issues and pull requests from the command line. Written in Go, GitHub CLI can be installed on Linux, macOS, and Windows.

Using GitHub CLI, developers will be able to list open issues and filter them based on assignee, label, and state; to create pull requests; to check out pull requests locally; to view the status of your work, and more.

Ever considered setting up and running your very own git server? It’s actually quite easy! In this post, I’ll outline the steps I took to set up my own so that you can give it a try yourself. But first, why might you even want to go through the trouble of setting up your own server?

After all, there are a wide array of excellent and free to use choices out there, such as GitHub, GitLab, and the up-and-coming sourcehut.

One reason is ownership: in today’s world of corporate surveillance, rampant privacy violations, and data breaches, there is something to be said of truly owning your own data. Both git and the web itself were designed and built on principles of decentralization and distribution. Standing up your own server is one way to tap into that heritage.

It’s also just plain fun, at least if you’re into that sort of thing. You get to build something useful and put your name on it. It’s something you control. You get to decide how it works, how it looks, who can access it, and what exists on it.

Setting up a git server is actually relatively straight-forward. Almost all of the heavy lifting is done by git itself, but I will also introduce a few supplementary tools to handle things like access control and HTTP access.

Now that I’ve provided you with an introduction to Git and a brief overview of using Git with GitHub, it’s time to build on that knowledge by taking a closer look at one workflow often used when collaborating with Git. The “fork and branch” workflow is a common way of collaborating on open source projects using Git and GitHub. In this post, I’m going to walk through this workflow (as I understand it—I’m constantly learning), with a focus toward helping those that are new to this sort of thing.

This is the website for the Pro Git book, written by Scott Chacon and published by Apress. Here you can find the full content of the book, a blog with tips and updates about Git and the book and open source projects related to Git or referenced in the book.

How to use git to track OpenDocument (OpenOffice, Koffice) files?