Should I use past or present tense in git commit messages

Question

I read once that git commit messages should be in the imperative present tense  e g   Add tests for x   I always find myself using the past tense  e g   Added tests for x  though  which feels a lot more natural to me   Here s a recent John Resig commit showing the two in one message      Tweak some more jQuery set results in the manipulation tests  Also fixed the order of the expected test results     Does it matter  Which should I use

User · Answer

Your project should almost always use the past tense   In any case  the project should always use the same tense for consistency and clarity   I understand some of the other arguments arguing to use the present tense  but they usually don t apply   The following bullet points are common arguments for writing in the present tense  and my response    Writing in the present tense tells someone what applying the commit will do  rather than what you did    This is the most correct reason one would want to use the present tense  but only with the right style of project   This manner of thinking considers all commits as optional improvements or features  and you are free to decide which commits to keep and which to reject in your particular repository   This argument works if you are dealing with a truly distributed project   If you are dealing with a distributed project  you are probably working on an open source project  And it is probably a very large project if it is really distributed   In fact  it s probably either the Linux kernel or Git   Since Linux is likely what caused Git to spread and gain in popularity  it s easy to understand why people would consider its style the authority   Yes  the style makes sense with those two projects   Or  in general  it works with large  open source  distributed projects   That being said  most projects in source control do not work like this   It is usually incorrect for most repositories   It s a modern way of thinking about a commits  Subversion  SVN  and CVS repositories could barely support this style of repository check-ins   Usually an integration branch handled filtering bad check-ins  but those generally weren t considered  optional  or  nice-to-have features    In most scenarios  when you are making commits to a source repository  you are writing a journal entry which describes what changed with this update  to make it easier for others in the future to understand why a change was made  It generally isn t an optional change - other people in the project are required to either merge or rebase on it   You don t write a diary entry such as  Dear diary  today I meet a boy and he says hello to me    but instead you write  I met a boy and he said hello to me    Finally  for such non-distributed projects  99 99  of the time a person will be reading a commit message is for reading history - history is read in the past tense   0 01  of the time it will be deciding whether or not they should apply this commit or integrate it into their branch repository    Consistency  That s how it is in many projects  including git itself   Also git tools that generate commits  like git merge or git revert  do it    No  I guarantee you that the majority of projects ever logged in a version control system have had their history in the past tense  I don t have references  but it s probably right  considering the present tense argument is new since Git     Revision  messages or commit messages in the present tense only started making sense in truly distributed projects - see the first point above     People not only read history to know  what happened to this codebase   but also to answer questions like  what happens when I cherry-pick this commit   or  what kind of new things will happen to my code base because of these commits I may or may not merge in the future     See the first point  99 99  of the time a person will be reading a commit message is for reading history - history is read in the past tense   0 01  of the time it will be deciding whether or not they should apply this commit or integrate it into their branch repository   99 99  beats 0 01     It s usually shorter   I ve never seen a good argument that says use improper tense grammar because it s shorter   You ll probably only save 3 characters on average for a standard 50 character message   That being said  the present tense on average will probably be a few characters shorter    You can name commits more consistently with titles of tickets in your issue feature tracker  which don t use past tense  although sometimes future    Tickets are written as either something that is currently happening  e g  the app is showing the wrong behavior when I click this button   or something that needs to be done in the future  e g  the text will need a review by the editor      History  i e  commit messages  is written as something that was done in the past  e g  the problem was fixed

User · Answer

The preference for present-tense  imperative-style commit messages comes from Git itself  From Documentation SubmittingPatches in the Git repo      Describe your changes in imperative mood  e g   make xyzzy do frotz    instead of   This patch  makes xyzzy do frotz  or   I  changed xyzzy   to do frotz   as if you are giving orders to the codebase to change   its behavior    So you ll see a lot of Git commit messages written in that style  If you re working on a team or on open source software  it is helpful if everyone sticks to that style for consistency  Even if you re working on a private project  and you re the only one who will ever see your git history  it s helpful to use the imperative mood because it establishes good habits that will be appreciated when you re working with others

User · Answer

Stick with the present tense imperative because   it s good to have a standard it matches tickets in the bug tracker which naturally have the form  implement something    fix something   or  test something

User · Answer

does it matter  people are generally smart enough to interpret messages correctly  if they aren t you probably shouldn t let them access your repository anyway

User · Answer

I wrote a fuller description on 365git      The use of the imperative  present tense is one that takes a little   getting used to  When I started mentioning it  it was met with   resistance  Usually along the lines of    The commit message records   what I have done     But  Git is a distributed version control system   where there are potentially many places to get changes from  Rather   than writing messages that say what you   ve done  consider these   messages as the instructions for what applying the commit will do    Rather than having a commit with the title            Renamed the iVars and removed the common prefix          Have one like this            Rename the iVars to remove the common prefix         Which tells someone what applying the commit will do  rather than what   you did  Also  if you look at your repository history you will see   that the Git generated messages are written in this tense as well -      Merge    not    Merged        Rebase    not    Rebased    so writing in the same   tense keeps things consistent  It feels strange at first but it does   make sense  testimonials available upon application  and eventually   becomes natural       Having said all that - it   s your code  your repository  so set up your   own guidelines and stick to them       If  however  you do decide to go this way then git rebase -i with the   reword option would be a good thing to look into

User · Answer

Who are you writing the message for   And is that reader typically reading the message pre- or post- ownership the commit themselves     I think good answers here have been given from both perspectives  I   d perhaps just fall short of suggesting there is a best answer for every project   The split vote might suggest as much    i e  to summarise    Is the message predominantly for other people  typically reading at some point before they have assumed the change  A proposal of what taking the change will do to their existing code  Is the message predominantly as a journal record to yourself  or to your team   but typically reading from the perspective of having assumed the change and searching back to discover what happened    Perhaps this will lead the motivation for your team project  either way

User · Answer

It is up to you  Just use the commit message as you wish  But it is easier if you are not switching between times and languages   And if you develop in a team - it should be discussed and set fixed

[git] Should I use past or present tense in git commit messages?

Examples related to git

Examples related to git-commit

Examples related to conventions

Examples related to commit-message