Git Best Practices

Question 1

Q: What is a good practice for commit messages?

Answer 1

A: Use clear, concise messages describing the purpose of the changes (e.g., “Fix login bug in authentication module”).

Question 2

Q: How should you format commit messages?

Answer 2

A: Use a short summary (50 characters or less), followed by a detailed description if needed.

Question 3

Q: Why is it important to make small, incremental commits?

Answer 3

A: It makes it easier to understand and debug the changes in the project history.

Question 4

Q: When should you use branches?

Answer 4

A: Use branches for new features, bug fixes, or experiments to keep the main branch stable.

Question 5

Q: What is the purpose of a branch naming convention?

Answer 5

A: It makes branches easy to identify, e.g., feature/login, bugfix/auth-error, or hotfix/v1.0.1.

Question 6

Q: How often should you pull changes from the remote repository?

Answer 6

A: Frequently, to stay up-to-date with the latest changes and avoid conflicts.

Question 7

Q: Why should you rebase instead of merge for small feature branches?

Answer 7

A: Rebasing keeps the commit history linear and clean.

Question 8

Q: When is it better to use git merge over git rebase?

Answer 8

A: Use merge for long-lived branches like main to preserve the commit history.

Question 9

Q: How can you avoid committing sensitive information?

Answer 9

A: Use a .gitignore file to exclude sensitive files and directories.

Question 10

Q: What is the best practice for managing .gitignore files?

Answer 10

A: Create project-specific .gitignore files and use a global ignore file for personal patterns.

Question 11

Q: Why should you avoid using git push –force?

Answer 11

A: It can overwrite changes on the remote and disrupt collaboration.

Question 12

Q: When is it acceptable to use git push –force?

Answer 12

A: On private branches that are not shared with others or when explicitly coordinated with the team.

Question 13

Q: What is a good practice for tagging?

Answer 13

A: Use tags to mark release versions (e.g., v1.0.0, v2.1.3).

Question 14

Q: How should you structure your branches in a large project?

Answer 14

A: Use Git workflows like Gitflow or trunk-based development to organise branches efficiently.

Question 15

Q: Why should you test code before committing?

Answer 15

A: To ensure that the code is functional and reduces errors introduced into the repository.

Question 16

Q: How can you ensure consistent code quality in a team?

Answer 16

A: Use Git hooks for pre-commit or pre-push checks, such as linting and unit tests.

Question 17

Q: What is the best way to handle merge conflicts?

Answer 17

A: Resolve them promptly, review the changes carefully, and test the code after resolving.

Question 18

Q: Why should you avoid committing generated files or build artifacts?

Answer 18

A: They can bloat the repository and are better recreated by the build system.

Question 19

Q: What is the purpose of a code review?

Answer 19

A: To ensure code quality and catch potential bugs or issues before merging changes.

Question 20

Q: Why should you periodically clean up old branches?

Answer 20

A: To keep the repository tidy and avoid confusion over obsolete branches.

Question 21

Q: How should you organise commits when preparing for a merge request?

Answer 21

A: Squash or rebase commits into logical, meaningful units for easier review.

Question 22

Q: Why is it important to use descriptive branch names?

Answer 22

A: It helps the team understand the purpose of the branch at a glance.

Question 23

Q: What is a good practice for managing remote repositories?

Answer 23

A: Regularly prune unused remotes with git remote prune origin.

Question 24

Q: How can you improve collaboration in a team using Git?

Answer 24

A: Use clear workflows, consistent naming conventions, and frequent communication about branch activity.

Question 25

Q: Why should you document your Git workflow?

Answer 25

A: To ensure everyone on the team follows the same practices and understands the process.