1

I've been a solo developer using git for years and haven't yet used the tagging feature. Typically I'll create a "new_feature" branch, make several commits, then merge back to my master branch. However, these are individual commits, and don't map to the feature all at once. I do like keeping them separate in case I notice a bug. However, it would be nice to group the commits together once back on master. My question is whether developers will typically just combine the branch commits into one commit before merging back to master so that they have a single commit with a description of the new feature or whether they tag the last commit when they merge it back to master.

Are there pros and cons to each method?

Improve this question
3
  • There's a third option -- you can do no-ff merge, then it's both a single commit and collection of commits
    – RiaD
    Feb 10, 2021 at 22:04
  • Interesting! I wasn't aware of that possibility. From your experience would this be superior to tagging? If I understand this correctly, then, all of the messages would be within one commit (no-ff merge) vs. the tagging process which would have the messages "externally" located in the branch history.
    – Eric
    Feb 10, 2021 at 22:13
  • How does your deployment process look like?
    – Doc Brown
    Feb 11, 2021 at 6:58

1 Answer 1

Reset to default
3

Squash Commits

I recommend squashing your commits before merging back to your main branch.

While the best practices for git state that you should commit early and commit often, this does not mean that your git history should be riddled with multiple, small and insignificant commits.

Such commits will make reduce the readability of your git history.

Here's an example

:
:  
commit e4b665b4a updated how login works
commit dcd77a46a updated version
commit e4c77b936 fixed some review comments
commit d36a0e6b5 fixed some review comments
commit a69fed5f5 added more test
commit 49945ad19 added in some tests for web client
:
:

That commit history doesn't tell me at which commit a feature ends and begins. Add to that other developers merging their branches in to the trunk, and you are going to have a mess.

But contrast that with this history:

:
commit e4b665b4a added validation for book creation
commit dcd77a46a new route for book creation
commit e4c77b936 added login screen
:

Aside from the difference in message clarity (done on purpose, to make another point), it's clear to see which commit added which kind of feature. Your peers will thank you!

Side Note: while i haven't added it here, please also include your JIRA/ticket in the commit, to be able to relate it back to a story/JIRA for sanity.

Use tags for releases

This is what i do at my work. And i recommend it. You should tag releases to demarcate and identify when a stable version was pushed to production and what changes went into that version.

Releases should identify which JIRAs and bugs were resolved by this version and any known issues and work-arounds. This allows other developers using your software to be aware of what surprises are in store (fore-warned is fore-armed!).

Release v1.1.0

[JIRA-1110] fix glitches in validation that trigger when user logs in from mobile
[JIRA-1203] Added new route for creating a new book
:
:

Known Issues:
This application will not allow login from aa unsupported browser
:
:

An added benefit is that you can setup your repo to run CI for tags, that can involve more significant and intense tests (such as performance tests), that would be too expensive and time-consuming to run on ever commit.

Improve this answer
4
  • What heuristics do you suggest for deciding which commits to squash, and which to keep separate?
    – outis
    Feb 11, 2021 at 4:21
  • Here's an example from Linux: Linus Torvalds considers the commit history the same as code. So, in exactly the same way that you refactor code so that the code looks like you knew exactly what you wanted to build and how from day 1, you refactor the history so that it looks like you knew exactly what steps to take to get to the result. Of course, this is an extreme example, because Linux has 3000 developers and there is a commit every couple of seconds (and the rate of commits seems to be increasing super-linearly), so a clean history is vital.
    – Jörg W Mittag
    Feb 11, 2021 at 8:45
  • For my current project, I'm pushing new code to the server almost every week with new features. Let's say in a particular week I add 3 new features. Would you consider this to be a "release" to then be tagged?
    – Eric
    Feb 11, 2021 at 14:12
  • 1
    I'd recommend squashing the commits for each feature, so you should have only 3 commits for the 3 features. I say this because most of the time commits in one feature consist of multiple small commits. There is no defined size of a release. You (organization) define it. A release is defined by a cadence or a need - say a weekly, monthly or quarterly release. An example of a need is a security patch or could be based on an agreement in a contract. So if you've added 3 new features and its time to release based on your cadence or need, then by all means - tag and release.
    – m_vemuri
    Feb 12, 2021 at 1:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.