Reminder: One Git push can have multiple commits

Photo by Adli Wahid on Unsplash

Odds are you already know that a Git push doesn’t have to be just one commit. When you were learning Java or Python or something like that, learning Git was probably an afterthought, so it’s easy to forget about seemingly obvious aspects of Git.

There is a feature of the git status command that can help you keep track of how many pushes your local is ahead of your remote. But to enable that feature, your local has to have an “upstream” set.

I’d probably need a whole other article to explain what an upstream is. Here I’ll just explain what you need to know about upstream to help you keep track of how many commits you have in a push.

For the examples in this article, let’s say that you’re working on the main branch of your local and it’s set to push to the main branch of the remote, and there have been no changes to the local since the last push to remote.

If you don’t have the upstream set, you can set it with the command

git branch --set-upstream-to origin/main

If you want it for a different branch, you would replace “main” with the name of that branch.

Then git status should in the example give something like

On branch main
Your branch is up to date with ‘origin/main’.

This can make it easier to keep track of commits in your mind by making it easier to group them into larger pushes, especially in situations when you want to be granular with the version history without having to do a git push after each git commit. Which should probably be almost all situations anyway.

For example, if you want to show that you’re doing test-driven development (TDD) but don’t want to risk leaving your repository in a state with failing tests, you can simply group a commit of failing tests into the same push as the commit of passing tests and if applicable a refactoring commit.

Then, when you push those commits all at once, the most recent commit corresponds either to a pass or refactor step, but the failing step is still available in the history.

To give you an idea of what this looks like, let’s say I’m working on a Java project in IntelliJ IDEA on a laptop with Windows 10. I just created SomeClass and the corresponding test class.

C:\Users\AL\IdeaProjects\ExampleProject>git status
On branch main
Your branch is up to date with ‘origin/main’.

Changes not staged for commit:
(use “git add <file>…” to update what will be committed)
(use “git restore <file>…” to discard changes in working directory)
modified: src/org/example/SomeClass.java
modified: test/org/example/SomeClassTest.java

I do git add on both of those files and then git commit with a message like “Failing the first test.”

C:\Users\AL\IdeaProjects\ExampleProject>git status
On branch main
Your branch is ahead of ‘origin/main’ by 1 commit.
(use “git push” to publish your local commits)

nothing to commit, working tree clean

Notice that it says the branch is ahead of origin/main by one commit. And it also suggests I use git push.

But I’m not running git push just yet. I change SomeClass so that the pertinent test in SomeClassTest now passes. So git add for SomeClass and then git commit with a message like “Passing the first test.”

C:\Users\AL\IdeaProjects\ExampleProject>git status
On branch main
Your branch is ahead of ‘origin/main’ by 2 commits.
(use “git push” to publish your local commits)

nothing to commit, working tree clean

Now it tells me my local branch is ahead by two commits. Maybe now I do the refactoring commit. I could keep going without doing a git push for a long time. Though maybe I shouldn’t let more than a dozen commits go by without a git push.

Let’s say that this is the point at which I do a git push. Someone looking at the remote (for example, on GitHub) who refreshes the page after I do git push will see the remote gain three commits, the most recent of which is the refactoring commit. The failing commit is still available in the history, but it’s not the most recent, just like I wanted.