Seb De Deyne
When I’m working on a feature or refactor, I often leave
@todo comments to remain in flow and deal with other points later.
I don’t mind committing them to my feature branch, as long as I work them away before merging in.
On large branches, it can be easy to forget about that todo I left in there a few days ago.
public function process(Podcast $podcast): void
// @todo Broadcast event to trigger webhooks
Before I merge, I pipe
git diff into a
grep call to scan for changes that include
git --no-pager diff main..feature-branch | grep -i "^\+[^$]*@todo"
+ // @todo Broadcast event to trigger webhooks
This is a friendly reminder to keep leading slashes in mind in
The other day, I pulled down a project and couldn’t get the CSS to build because files were missing. It turned out another developer created a new
resources/css/vendor directory to override styles for third-party components. A fine name, but
vendor was ignored so they were quietly missing from the repository. We updated
.gitignore to use
/vendor instead and all was well.
# Ignores all vendor files
# Only ignores vendor at the project root
In most projects, we use git flow to some extent — depending on the project and team size. This includes feature branches.
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
Working on a project with a lot of interdependencies between features with a bigger team comes with a new set of challenges dealing with git.
We’ve recently set up a new guideline: if it’s not directly tied to your feature, don’t put it in your feature branch.
Mac is case insensitive, Linux isn’t. This has caused me trouble in the past after deploying my code to an Ubuntu server.
If you rename a file on Mac, git won’t pick up any changes if you only change the case.
If GitHub is your daily driver or you’ve contributed to open source at some point, you’ve probably seen the comparison screen before.
“Compare and review just about anything”
They’re not lying. You can compare a lot in there, but most of it isn’t available in the UI. Here are a few tricks you probably didn’t know about.
Reviewing pull requests, I often see contributors sneakily adding editor configuration to the repository’s
If everyone would commit their environment-specific
.gitignore rules, we’d have a long list to maintain! My repository doesn’t care about your editor configuration.
There’s a better solution to this: a personal, global
.gitignore file for all your repositories. Here’s how you can set one up.