A lot of the posts I write include command-line interface (CLI) commands to type in. I’ve found over time there are things I can do to improve how these commands are communicated.
We can’t do a fast-forward merge when the most recent commit on the receiving branch does not appear in the branch we are merging in. One of our options in this situation is to create a merge commit when we merge in our branch.
The short answer is, “yes”. You should use your .gitignore file to ignore the .env file.
In most operating systems by default, files that start with a period (.) are hidden. When setting up my .gitignore file, I like to ignore all these hidden files (with a few exceptions).
This is my general starter .gitignore file for projects. I have a separate .gitignore for WordPress websites.
By using “git add -p”, I can include some of my current changes in my commit (without including all of my changes).
While my mental model visualizes a Git branch as a stack of building blocks, in actuality a Git branch is a pointer to a single commit. Under the hood Git stores a text file for each branch and in the text file is a single line, which is the commit hash indicating the commit at the tip of that branch.
I’m a big fan of Git and I’ve worked with lost of developers in growing their Git skills. Often developers learning Git, start by learning how to write a “good” commit message. While writing “good” commit messages is an important skill, in my opinion it is the wrong place to start.
These are the rules I follow when writing Git commit messages. I’ve found these serve me well and are compatible with most projects I work on (if a project has a specific set of rules for writing Git commit messages, those would override any rules I’ve outlined here).
When performing a Git rebase, I often find myself in the situation where I have one or more merge conflicts. This is how I resolve these merge conflicts.