/Git

Git - Beyond The Basics

- Anders Sundman tl;dr: “How well do you know Git? Many of us use it daily and pick up the basics as we go. After a few years, you might start to think that you know Git pretty well. But there are more things in the Git man pages than are dreamt of in your philosophy...”

featured in #576

How I Configure My Git Identities

- Benji Mora tl;dr: “I like to mess with my dotfiles and every so often, I find out about a new way to do things and I spend more time than I should learning how to use it. A few years ago I learned about includeIf for including specific files if some condition was met for git.”

featured in #569

How To Fork: Best Practices And Guide

- Joaquim Rocha tl;dr: “Over the years, my work did sometimes involve maintaining forks of various open-source projects. That’s not the case with my job now, but when a colleague reached out for help with a fork that hadn’t been rebased in ages, it got me thinking that the steps I follow might be useful for other developers too. Hence this article.”

featured in #560

How I Use Git

- Thorsten Ball tl;dr: “How I use git is based on the last 12 years of working in companies with smallish (less than 50) engineering teams. In every team, we used git and GitHub exclusively; changes were made in branches, proposed as pull requests, and then merged into the main branch. In the last few years, after GitHub introduced squash-merging, we used that.”

featured in #559

Git Absorb

- Stephen Jung tl;dr: “You have a feature branch with a few commits. Your teammate reviewed the branch and pointed out a few bugs. You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits.” Instead of manually finding commit SHAs for git commit --fixup, or running a manual interactive rebase, Stephen shows us an alternative.  

featured in #556

Git Absorb

- Stephen Jung tl;dr: “You have a feature branch with a few commits. Your teammate reviewed the branch and pointed out a few bugs. You have fixes for the bugs, but you don't want to shove them all into an opaque commit that says fixes, because you believe in atomic commits.” Instead of manually finding commit SHAs for git commit --fixup, or running a manual interactive rebase, Stephen shows us an alternative.  

featured in #555

Modern Git Commands And Features You Should Be Using

- Martin Heinz tl;dr: “Most people only ever touch the most basic of commands, such as add, commit, push or pull, like it's still 2005. Git however, introduced many features since then, and using them can make your life so much easier, so let's explore some of the recently added, modern git commands, that you should know about.” Martin presents Switch, Restore, Sparse Checkout, Worktree and Bisect. 

featured in #540

Modern Git Commands And Features You Should Be Using

- Martin Heinz tl;dr: “Most people only ever touch the most basic of commands, such as add, commit, push or pull, like it's still 2005. Git however, introduced many features since then, and using them can make your life so much easier, so let's explore some of the recently added, modern git commands, that you should know about.” Martin presents Switch, Restore, Sparse Checkout, Worktree and Bisect. 

featured in #539

How I Use Git Worktrees

- Alex Kladov tl;dr: “There are a bunch of posts on the internet about using git worktree command. As far as I can tell, most of them are primarily about using worktrees as a replacement of, or a supplement to git branches. Instead of switching branches, you just change directories. This is also how I originally had used worktrees, but that didn’t stick, and I abandoned them. But recently worktrees grew on me, though my new use-case is unlike branching.”

featured in #535

In Praise Of Small Pull Requests

- Elliotte Rusty Harold tl;dr: “Prefer small, focused pull requests that do exactly one thing each. Why?” (1) Easier to review (2) Can be reviewed quickly. (3) Easier to figure out exactly where the mistake is. (4) Less likely to conflict with other developers’ work. (5) Saves a lot of work if you made a critical error. (6) Easier to make sure each individual pull request is completely tested.

featured in #533