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.
class PodcastController
{
public function process(Podcast $podcast): void
{
$podcast->process();
// @todo Broadcast event to trigger webhooks
return $podcast;
}
Before I merge, I pipe git diff into a grep call to scan for changes that include @todo.
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 .gitignore files.
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
vendor
# Only ignores vendor at the project root
/vendor
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.
Read more
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.
Read more
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.
Read more
Reviewing pull requests, I often see contributors sneakily adding editor configuration to the repository’s .gitignore file.
composer.lock
package.lock
+ .vscode
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.
Read more