Process for committing code

git
1

I’m coaching @dylangrafmyre on what happens when you’re ready to commit code, so here’s a quick checklist. Let me know if there’s anything to add.

Commit Checklist

  1. Get all the tests passing first (if possible).
  2. Open up a scratchpad to start jotting down the commit message.
  3. Go through each diff (in RubyMine):
    1. Remove any debug print statements.
    2. Ensure that the right level of commenting is used. No comments that are better done with code. Use comments for something like some test code that should work but doesn’t and that might get fixed by some gem upgrades.
    3. Remove any commented code.
    4. Clean up formatting for changed lines.
  4. Consider whether the set of changes should be one commit or multiple commits.
  5. Run the tests again if you’ve changed any files.

The goals for each commit should be to:

  1. Tell a small, self-contained story.
  2. Make it easy for your code reviewer.
  3. Be useful for running a git bisect to track down any regressions.

What else?

2

This covers everything.

1 Like
3

If available in the dev environment, I would add:

  • run check style
  • run static code analysis
  • go through the team’s best coding practices
4

So wait, this is for each and every commit? Or would you use incremental commits, and this is for “roll-up” type commits? I’m a much bigger fan of very prolific committing… It’s a dirtier history later, but much easier in the long term to go back to “working” states…

5

For my checklist, that’s every commit. It only takes a very short time to run through my list, with the exception of running the test suite. I think Martin’s list is great as well, and that’s something I should strive for, as the JetBrains tools have great static analysis. However, I think I never get around to running the static analysis as the dynamic analysis gets most issues.

Another tip is to not immediately push commits, so that you can revise the history a bit if needed before committing.

6

I think there is some middle ground. Like @litch I commit regularly, sometimes 10 times a day. I would die if I had to run through all that every time. What I do is develop in a branch with LOTS frequent commits. But when its time to merge back to master, your list looks to be comprehensive. Personally, I despise commits that break tests, so I would rethink saying “if possible” on item #1.

7

I just started a thread here on what to do if you don’t have time for full tests:

Any feedback is greatly appreciated!

1 Like
8

Here’s a couple articles on git commit messages. This stuff matters!

  1. How to Write a Git Commit Message : Super great advice!

  2. Separate subject from body with a blank line

  3. Limit the subject line to 50 characters

  4. Capitalize the subject line

  5. Do not end the subject line with a period

  6. Use the imperative mood in the subject line

  7. Wrap the body at 72 characters

  8. Use the body to explain what and why vs. how

  9. 5 Useful Tips For A Better Commit Message: More good advice

  10. Pro Git: Definitely know this book!

1 Like
9

Anybody here know a better way to get squash to a single commit on top of master?

Here’s what I do:

(be sure nobody else is working on your branch before starting this process!)

  1. squash your commits to one commit, using rebase -i and make a nice single commit message
  2. git fetch, then rebase origin/master, and when you’re ready push -f
10

@justin this is exactly what I do. I seem to always get the number of commits to include in the rebase incorrect, however, which is very annoying. What’s the trick here? For example if I make 3 commits after a commit tagged 1.0.0, and I want to squash them into a single commit that comes immediately after 1.0.0, what is the exact thing you’d write? git rebase -i HEAD~3?

11

There is a git squash on git extras: https://github.com/tj/git-extras/blob/master/Commands.md#git-squash

12

If you found the solution to some problem, include the link to that stack overflow discussion or blog post in your commit message, so it’ll be easier to track down if you need it again.

13

https://shakacode.slack.com/team/bshyong posted this article that I thought this was really good: https://www.atlassian.com/git/images/articles/git-team-workflows-merge-or-rebase/merge-trees-1-600x183.png

14

Thanks @mapreal19!

So, are the steps to first change to the correct branch and run git squash? And that makes the branch just have one commit?

git checkout fixed-cursor-styling
git squash fixed-cursor-styling
15

Hmm that won’t work. As you can read:

Merge commits from src-branch into the current branch as a single commit.

To have that branch a single commit and not merging we could specify the commit reference:

git squash 95b7c52 # it would be the last commit from the base branch (e.g. master/develop)
16

@mapreal19 I’ve been using a manual process:

  1. First git rebase -i <SOME SHA> my feature branch into a single commit. I generally have to look at the history to see how far back to rebase -i. There’s probably a script for this.
  2. Then I git fetch && git rebase origin/master and that puts my one uber-commit on top of master.
  3. Once I deem everything ready, I do a git push -f, making sure nobody was working at the same time off of my feature branch.

I bet there’s a better, more automated way to do this.