Git Cheat Sheet: Best Practices for Naming Pull Requests and Commits + Essential Git Commands

1. Best Practices for Naming Pull Requests and Commits

Well-structured commit messages and PR names provide clarity and help in understanding the purpose of a change. Below are some tips and best practices for naming your PRs and commits:

Commit Naming Best Practices:

1.Use Imperative Mood: Your commit messages should be written as commands, e.g., "Add feature X" instead of "Added feature X." It describes what the commit will do if applied.

Example:

• Good: Add login functionality
• Bad: Added login functionality

2.Keep It Short but Descriptive: Your commit message should be succinct but clear. Aim for around 50 characters in the subject line. Use the body of the commit to explain further if necessary.

Example:

• Good: Fix bug in user authentication flow
• Bad: Fix authentication issue because users weren’t being validated when login was attempted after the session expired.

3.Explain Why, Not Just What: If a commit is complex, explain why certain changes were made, not just what was changed. This is often useful in the body of the commit message.

4.Prefix Commits by Type (Optional): Use prefixes like fix:, feat:, chore:, docs:, or refactor: to indicate the nature of the commit. This is commonly seen in the Conventional Commits format.

Example:

• fix: Correct typo in user validation method
• feat: Add support for multi-language forms
• chore: Update dependencies

2. PR Naming Best Practices

1.Summarize the Change: The PR title should summarize the change succinctly, giving reviewers an immediate understanding of its scope.

Example:

• Good: Add multi-step form functionality for onboarding
• Bad: Changes

2.Use a Ticket Reference (If Applicable): If you use a project management system (like Jira, Trello, or GitHub Issues), include the ticket or issue number in your PR title to link it to the relevant task.

Example:

• #123 Add payment integration with Stripe API

3.Reflect the Impact: Highlight the outcome of the PR, such as bug fixes, performance improvements, or new features.

4.Avoid WIP in Titles: Avoid marking your PRs with “WIP” (Work In Progress). Instead, use draft PRs for incomplete work, and update the title when it’s ready for review.

2. Creating a Pull Request (PR)

A pull request allows you to propose changes and have them reviewed before merging them into the main codebase.

Steps:

1.Make sure your branch is synced with main.

git pull origin main

2.Push your feature branch to the remote repository:

git push origin feature-branch-name

3.On your Git platform (GitHub, GitLab, etc.), open a pull request. Use a clear and concise PR title and include a description.

PR Title Example: Add unit tests for user authentication module (#456)

3. Managing Multiple Commits in the Same Pull Request

When working on a feature branch, you'll likely make multiple commits. These commits will be shown in your pull request.

Steps:

1.Add your changes and commit them.

git add .
git commit -m "Implement basic login form"
git commit -m "Add error handling for failed login attempts"

2.Push your branch:

git push origin feature-branch

If you want to merge these into one commit before merging, use interactive rebase to squash them.

4. Renaming a Commit

If you make a typo or want to clarify a commit message, Git allows you to rename it.

Steps:

1.To rename the latest commit:

git commit --amend -m "Correct login form typo"

2.To rename older commits, use interactive rebase:

git rebase -i HEAD~n

In the editor, change pick to reword for the commit you want to rename.

5. Fixup Commits

If you need to correct a mistake from a previous commit, you can make a "fixup" commit and squash it later during a rebase.

Steps:

1.Create the fixup commit:

git commit --fixup <commit-hash>

2.Automatically squash it:

git rebase -i --autosquash HEAD~n

6. Resetting Origin (Remote Branch)

If you need to reset your local branch to match the remote (origin), you can hard reset your branch.

Steps:

1.Fetch the latest from origin:

git fetch origin

2.Reset to match origin:

git reset --hard origin/main

7. Rebasing and Fixing Rebase Conflicts

Rebasing helps maintain a cleaner history by replaying your changes on top of the latest code. However, conflicts can arise, and you need to resolve them.

Steps:

1.Rebase your branch:

git rebase origin/main

2.If conflicts occur, fix them manually, then continue:

git add .
git rebase --continue

8. Squashing and Autosquashing Multiple Commits

To combine multiple commits into one clean commit before merging:

Steps:

1.Start an interactive rebase:

git rebase -i HEAD~n

2.For autosquash:

git rebase -i --autosquash HEAD~n

9. Cherry-picking a Commit

Cherry-picking allows you to apply a specific commit from one branch to another.

Steps:

1.Find the commit hash of the commit you want to copy:

git log

2.Cherry-pick the commit:

git cherry-pick <commit-hash>

10. Git Stash

If you want to save your current work without committing it (perhaps to switch branches), use Git stash.

Steps:

1.Save uncommitted changes:

git stash

2.Reapply the stash:

git stash apply

11. Undoing Commits

You can undo a commit while either keeping or discarding the changes.

Undo the most recent commit (keep changes):

git reset --soft HEAD~1

Undo the most recent commit (discard changes):

git reset --hard HEAD~1

12. Checking Out Previous Commits

To temporarily switch to an older commit, you can check it out.

Steps:

1.Find the commit hash:

git log

2.Checkout the commit:

git checkout <commit-hash>

Conclusion

Following best practices in naming your pull requests and commits can make your Git workflow much cleaner and more manageable. Combined with mastery of essential Git commands, you'll maintain a more organized and collaborative codebase.

Happy coding!