Git Best Practice

In my past 2 years of programming with Python and React in various little hackathon projects and side projects like this blog, I've never really worked much with pull requests or creating branches. I've just been pushing to the main branch.

I'm now working on a hackathon and would like to practice creating branches, writing good commit messages, merging branches, etc.

I found this Git Style Guide inspired by inspired by How to Get Your Change Into the Linux Kernel, and the git man pages

Branches

use lower case in branch names, use hyphens to separate words
choose short descriptive names like "oauth-migration", not "login_fix" (too vague)
use identifiers from tickets like git checkout -b issue-15
delete branch from upstream repo after merging, unless there's good reason not to
use git branch --merged | grep -v "\*" to list merged branches.
more tips

Commits

when writing, think about what you would need to know in a year from now when running across the commit
each commit should be a single logical change, ex: if a patch fixes a bug and optimize performance, split into two
use git add -p to interactively stage specific portions of files
don't split a single logical change into several commits (features + tests should be one)
commit early and often : small, self-contained commits are easier to understand and easy to revert
commits should be ordered logically, if commit X depends on Y, Y should come before X.
squash commits using --squash and -fixup

Messages

summary line should be descriptive yet succinct, no longer than 50 chars
should not end with a period
after that comes a blank line and a more thorough description (72 chars) explaining why the change was needed, how it addresses the issue, and what side-effects it might have
it should also provide pointers to related resources (link to issue in bug tracker)
if commit A depends on B, state in message of A, and use SHA1 to refer to commits

Short (50 chars or fewer) summary of changes

More detailed explanatory text, if necessary. Wrap it to
72 characters. In some contexts, the first
line is treated as the subject of an email and the rest of
the text as the body.  The blank line separating the
summary from the body is critical (unless you omit the body
entirely); tools like rebase can get confused if you run
the two together.

Further paragraphs come after blank lines.

- Bullet points are okay, too

- Use a hyphen or an asterisk for the bullet,
  followed by a single space, with blank lines in
  between

The pointers to your related resources can serve as a footer
for your commit message. Here is an example that is referencing
issues in a bug tracker:

Resolves: #56, #78
See also: #12, #34

Source: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

Merging

Do not rewrite published history
keep history clean and simple, before merging
- make sure it conforms to style guide, perform actions if it doesn't (squash/reorder, reword messages)
- rebase onto branch, so it can be applied directly to end of "main" branch and result in a simple history (suited for projects with short-running branches)
If your branch includes more than one commit, do not merge with a fast-forward:
- git merge --no-ff my-branch

Extras

Some maintenance tasks git commands

More Git stuff

Some articles by Julia Evans

BENEDICT NEO