DEV Community

Pratik Ambani
Pratik Ambani

Posted on

Git Strategy for Sanity

"Ah!! Plenty of articles here on the git, I don't want another one." - My first reaction when I reviewed this before publishing. 😜

Well, we as a team follow a predefined set of rules before committing codebase in git. I'm sharing the same over here as I find them very promising in order to maintain git sanity.

  1. Your code is formatted. (let me know in comments if you are also suffering from this phobia 😧 ).
  2. Don't you dare committing an erroneous code. 😈👿
  3. Don't forget to update your regularly with required updates on each commit. You may wish to have a look at this article.
  4. Commit Message must start with Jira ticket number(i.e. XYZ-1234).
  5. The second word of commit message must be either of (added, removed, changed, refactored, corrected).
  6. Nobody commits on master and feature/parent branch.

Extensions and Utilities:

I would strongly suggest you to configure,

Rules while creating new Repository:

This will be default structure for any new repository to be created in Production.
repo rules

  • Master will contain only
  • Release will be passed via feature/parent branch only.
  • feature/develop and feature/fixes will be merged into feature/parent only when the code is reviewed
  • All new branches will be extension of develop branch only
  • Need new Repo?: Create as much as you want, but keep em private only.
  • Default collaboration: only to required people

As usual, suggestions are always welcomed. Happy Coding and may the code bless you. 😇

Top comments (4)

kungtotte profile image
Thomas Landin

Your commit message rules conflict with the tradition of using the imperative tense, and it doesn't seem like your rules would be incompatible with following the tradition.

E.g. by convention your commit messages should work with this format: "If applied, this commit will: your commit message here". So you would write "Add feature XYZ" or "Fix login issue on page ABC" as the initial line of the commit message and it would work with that format.

In your case you could just change the tense of your second-word rule, "add", "remove", "change" etc.

Is there any reason why you went this route? Either version conveys the same information, both are just as grep-able, but only one follows convention.

evantypanski profile image
Evan Typanski

Also notice that this is the style for merges, eg. Merge pull request #300... so even if you're just staying consistent with the automatically generated messages it's important.

lmbarr profile image
Luis Miguel • Edited

Exactly, your commit message should be in the imperative mode.

stargator profile image

Thank you, most people on my team write in past-tense :(