Becoming a Git power user is on the bucket list of every developer. Here are five Git tips that will help you level up your workflow and bring you one step closer to Git mastery.
Tip #1: Modify the Previous Commit Without Changing the Commit Message
You’ve just committed your changes on your local copy with a detailed and thought-through message, but the moment you hit RETURN, you realize you forgot to add that one change that really belongs there. If only there was a way to update the previous commit instead of creating a new one…
It can be a jumbled assortment of changes from all sorts of topics: some lines of code for a bugfix, a stab at rewriting an old module, and a couple of new files for a brand new feature.
Or, with a little bit of care, it can be something that helps us stay on top of things. It can be a container for related changes that belong to one and only one topic, and thereby make it easier for us to understand what happened.
In this post, we’re talking about what it takes to produce the latter type of commit or, in other words: the “perfect” commit.
Is it really necessary to compose commits in a careful, thoughtful way? Can’t we just treat Git as a boring backup system? Let’s revisit our example from above one more time.
If we follow the first path – where we just cram changes into commits whenever they happen – commits lose much of their value. The separation between one commit and the next becomes arbitrary: there seems to be no reason why changes were put into one and not the other commit. Looking at these commits later, e.g. when your colleagues try to make sense of what happened in that revision, is like going through the “everything drawer” that every household has: there’s everything in here that found no place elsewhere, from crayons to thumbtacks and cash slips. It’s terribly hard to find something in these drawers!
Following the second path – where we put only things (read: changes) that belong together into the same commit – requires a bit more planning and discipline. But in the end, you and your team are rewarded with something very valuable: a clean commit history! These commits help you understand what happened. They help explain the complex changes that were made in a digestible manner.
How do we go about creating better commits?
Composing better commits
One concept is central to composing better commits in Git: the Staging Area.
The Staging Area was made exactly for this purpose: to allow developers to select changes – in a very granular way – that should be part of the next commit. And, unlike other version control systems, Git forces you to make use of this Staging Area.
Unfortunately, however, it’s still easy to ignore the tidying effect of the Staging Area: a simple git add . will take all of our current local changes and mark them for the next commit.
It’s true that this can be a very helpful and valid approach sometimes. But many times, we would be better off stopping for a second and deciding if really all of our changes are actually about the same topic. Or if two or three separate commits might be a much better choice.
In most cases, it makes a lot of sense to keep commits rather smaller than larger. Focused on an individual topic (instead of two, three, or four), they tend to be much more readable.
The Staging Area allows us to carefully pick each change that should go into the next commit:
$ git add file1.ext file2.ext
This will only mark these two files for the next commit and leave the other changes for a future commit or further edits.
This simple act of pausing and deliberately choosing what should make it into the next commit goes a long way. But we can get even more precise than that. Because sometimes, even the changes in a single file belong to multiple topics.
Let’s look at a real-life example and take a look at the exact changes in our “index.html” file. We can either use the “git diff” command or a Git desktop GUI like Tower:
Now, we can add the -p option to git add:
$ git add -p index.html
We’re instructing Git to go through this file on a “patch” level: Git takes us by the hand and walks us through all of the changes in this file. And it asks us, for each chunk, if we want to add it to the Staging Area or not:
By typing [Y] (for “yes”) for the first chunk and [N] (for “no”) for the second chunk, we can include the first part of our changes in this file in the next commit, but leave the other changes for a later time or more edits.
The result? A more granular, more precise commit that’s focused on a single topic.
Testing your code
Since we’re talking about “the perfect commit” here, we cannot ignore the topic of testing. How exactly you “test” your code can certainly vary, but the notion that tests are important isn’t new. In fact, many teams refuse to consider a piece of code completed if it’s not properly tested.
If you’re still on the fence about whether you should test your code or not, let’s debunk a couple of myths about testing:
“Tests are overrated”: The fact is that tests help you find bugs more quickly. Most importantly, they help you find them before something goes into production – which is when mistakes hurt the most. And finding bugs early is, without exaggeration, priceless!
“Tests cost valuable time”: After some time you will find that well-written tests make you write code faster. You waste less time hunting bugs and find that, more often, a well-structured test primes your thinking for the actual implementation, too.
“Testing is complicated”: While this might have been an argument a couple of years ago, this is now untrue. Most professional programming frameworks and languages come with extensive support for setting up, writing, and managing tests.
All in all, adding tests to your development habits is almost guaranteed to make your code base more robust. And, at the same time, they help you become a better programmer.
A valuable commit message
Version control with Git is not a fancy way of backing up your code. And, as we’ve already discussed, commits are not a dump of arbitrary changes. Commits exist to help you and your teammates understand what happened in a project. And a good commit message goes a long way to ensure this.
But what makes a good commit message?
A brief and concise subject line that summarizes the changes
A descriptive message body that explains the most important facts (and as concisely as possible)
Let’s start with the subject line: the goal is to get a brief summary of what happened. Brevity, of course, is a relative term; but the general rule of thumb is to (ideally) keep the subject under 50 characters. By the way, if you find yourself struggling to come up with something brief, this might be an indicator that the commit tackles too many topics! It could be worthwhile to take another look and see if you have to split it into multiple, separate ones.
If you close the subject with a line break and an additional empty line, Git understands that the following text is the message’s “body.” Here, you have more space to describe what happened. It helps to keep the following questions in mind, which your body text should aim to answer:
What changed in your project with this commit?
What was the reason for making this change?
Is there anything special to watch out for? Anything someone else should know about these changes?
If you keep these questions in mind when writing your commit message body, you are very likely to produce a helpful description of what happened. And this, ultimately, benefits your colleagues (and after some time: you) when trying to understand this commit.
On top of the rules I just described about the content of commit messages, many teams also care about the format: agreeing on character limits, soft or hard line wraps, etc. all help to produce better commits within a team.
To make it easier to stick by such rules, we recently added some features to Tower, the Git desktop GUI that we make: you can now, for example, configure character counts or automatic line wraps just as you like.
A great codebase consists of great commits
Any developer will admit that they want a great code base. But there’s only one way to achieve this lofty goal: by consistently producing great commits! I hope I was able to demonstrate that (a) it’s absolutely worth pursuing this goal and (b) it’s not that hard to achieve.
If you want to dive deeper into advanced Git tools, feel free to check out my (free!) “Advanced Git Kit”: it’s a collection of short videos about topics like branching strategies, Interactive Rebase, Reflog, Submodules and much more.
Having a semantically versioned software will help you easily maintain and communicate changes in your software. Doing this is not easy. Even after manually merging the PR, tagging the commit, and pushing the release, you still have to write release notes. There are a lot of different steps, and many are repetitive and take time.
Let’s look at how we can make a more efficient flow and completely automating our release process by plugin semantic versioning into a continuous deployment process.
Semantic versioning
A semantic version is a number that consists of three numbers separated by a period. For example, 1.4.10 is a semantic version. Each of the numbers has a specific meaning.
Major change
The first number is a Major change, meaning it has a breaking change.
Minor change
The second number is a Minor change, meaning it adds functionality.
Patch change
The third number is a Patch change, meaning it includes a bug fix.
It is easier to look at semantic versioning as Breaking . Feature . Fix. It is a more precise way of describing a version number that doesn’t leave any room for interpretation.
Commit format
To make sure that we are releasing the correct version — by correctly incrementing the semantic version number — we need to standardize our commit messages. By having a standardized format for commit messages, we can know when to increment which number and easily generate a release note. We are going to be using the Angular commit message convention, although we can change this later if you prefer something else.
It goes like this:
<header>
<optional body>
<optional footer>
Each commit message consists of a header, a body, and a footer.
The commit header
The header is mandatory. It has a special format that includes a type, an optional scope, and a subject.
The header’s type is a mandatory field that tells what impact the commit contents have on the next version. It has to be one of the following types:
feat: New feature
fix: Bug fix
docs: Change to the documentation
style: Changes that do not affect the meaning of the code (e.g. white-space, formatting, missing semi-colons, etc.)
refactor: Changes that neither fix a bug nor add a feature
perf: Change that improves performance
test: Add missing tests or corrections to existing ones
chore: Changes to the build process or auxiliary tools and libraries, such as generating documentation
The scope is a grouping property that specifies what subsystem the commit is related to, like an API, or the dashboard of an app, or user accounts, etc. If the commit modifies more than one subsystem, then we can use an asterisk (*) instead.
The header subject should hold a short description of what has been done. There are a few rules when writing one:
Use the imperative, present tense (e.g. “change” instead of “changed” or “changes”).
Lowercase the first letter on the first word.
Leave out a period (.) at the end.
Avoid writing subjects longer than 80 charactersThe commit body.
Just like the header subject, use the imperative, present tense for the body. It should include the motivation for the change and contrast this with previous behavior.
The commit footer
The footer should contain any information about breaking changes and is also the place to reference issues that this commit closes.
Breaking change information should start with BREAKING CHANGE: followed by a space or two new lines. The rest of the commit message goes here.
Enforcing a commit format
Working on a team is always a challenge when you have to standardize anything that everyone has to conform to. To make sure that everybody uses the same commit standard, we are going to use Commitizen.
Commitizen is a command-line tool that makes it easier to use a consistent commit format. Making a repo Commitizen-friendly means that anyone on the team can run git cz and get a detailed prompt for filling out a commit message.
Generating a release
Now that we know our commits follow a consistent standard, we can work on generating a release and release notes. For this, we will use a package called semantic-release. It is a well-maintained package with great support for multiple continuous integration (CI) platforms.
semantic-release is the key to our journey, as it will perform all the necessary steps to a release, including:
Figuring out the last version you published
Determining the type of release based on commits added since the last release
Generating release notes for commits added since the last release
Updating a package.json file and creating a Git tag that corresponds to the new release version
Pushing the new release
Any CI will do. For this article we are using GitHub Action, because I love using a platform’s existing features before reaching for a third-party solution.
There are multiple ways to install semantic-release but we’ll use semantic-release-cli as it provides takes things step-by-step. Let’s run npx semantic-release-cli setup in the terminal, then fill out the interactive wizard.
Th script will do a couple of things:
It runs npm adduser with the NPM information provided to generate a .npmrc.
It creates a GitHub personal token.
It updates package.json.
After the CLI finishes, it wil add semantic-release to the package.json but it won’t actually install it. Run npm install to install it as well as other project dependencies.
The only thing left for us is to configure the CI via GitHub Actions. We need to manually add a workflow that will run semantic-release. Let’s create a release workflow in .github/workflows/release.yml.
name: Release
on:
push:
branches:
- main
jobs:
release:
name: Release
runs-on: ubuntu-18.04
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v1
with:
node-version: 12
- name: Install dependencies
run: npm ci
- name: Release
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# If you need an NPM release, you can add the NPM_TOKEN
# NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
run: npm run release
Steffen Brewersdorff already does an excellent job covering CI with GitHub Actions, but let’s just briefly go over what’s happening here.
This will wait for the push on the main branch to happen, only then run the pipeline. Feel free to change this to work on one, two, or all branches.
on:
push:
branches:
- main
Then, it pulls the repo with checkout and installs Node so that npm is available to install the project dependencies. A test step could go, if that’s something you prefer.
- name: Checkout
uses: actions/checkout@v2
- name: Setup Node.js
uses: actions/setup-node@v1
with:
node-version: 12
- name: Install dependencies
run: npm ci
# You can add a test step here
# - name: Run Tests
# run: npm test
Finally, let semantic-release do all the magic:
- name: Release
run: npm run release
Push the changes and look at the actions:
Now each time a commit is made (or merged) to a specified branch, the action will run and make a release, complete with release notes.
Release party!
We have successfully created a CI/CD semantic release workflow! Not that painful, right? The setup is relatively simple and there are no downsides to having a semantic release workflow. It only makes tracking changes a lot easier.
semantic-release has a lot of plugins that can make an even more advanced automations. For example, there’s even a Slack release bot that can post to a project channel once the project has been successfully deployed. No need to head over to GitHub to find updates!
Hello everybody. My name is Mar, and today I want to guide you through the most important step of your Tech career, your first interaction with Github.
I started off as a Computer Science student not long ago, in 2016. However, it took me a whole year to give this Github thing a try. I was hesitant and confused at first, but it did not turn out to be as complex as my peers made it sounds when they were talking about it. All it takes is some motivation! Now let’s dive right into it.
Commits are fundamental to Git, but not all developers have a comprehensive understanding of what a commit actually is and how it gets applied to your project.
In short, a commit is a snapshot of your Git repository at one point in time. In this beginner Git tutorial, we will dig into the journey of creating a commit.
In this edition of "Best of DZone," we take a look at all things Git, from basic commands, to theory behind its functionality, to development and deployment patterns. All tutorials and articles featured below are from our wonderful community members who continue to power DZone by sharing their knowledge of and passion for development with readers like you.
Take one last stride to cross the finish line and wrap up your OS project!
Have you ever started an open-source project, dived right into the code, discovered new API features that you loved, fiddled around with the build process, and then take a little break and never come back to it?
In this post, we will explore how to use conventional commit as well as the benefits of using it in your projects. Let's get started.
What Is It?
Conventional commit is a commit message standard first proposed by the Angular team to make their commit message uniform across different developers' check-ins. This standard gives a certain structure to commit and is helpful in building tools on top of commit messages.
Back in the day, when I was beginning to work on public-facing projects, setting up a development environment was really tedious. You have to install all the required software’s on the host machine. Relocating a project from one host to another sometimes comes to be the real work.
Now, the trend seems to have been changed. Once you want to work on a project, you start setting up a virtual machine on a remote computer that your company provides or a local virtual machine (at least in my company people prefer to work on virtual machines). There are many benefits, but one that I use all the time is the ability to take a virtual machine from one host and run it on a different one. Other than that, the ability to have multiple operating systems is very valuable for both development and testing.
