Git - Best Practices

From Training Material
Jump to navigation Jump to search

Git Best Practices
Lukasz Sokolowski

Git Best Practices ⌘

  • Dividing work into repositories
  • Selecting the collaboration workflow
  • Choosing which files to keep under version control
  • Working on a project
  • Integrating changes
  • Other

Working on a project ⌘

  • Working on a topic branch
    • long-running public branches
    • short-lived private branches
  • Deciding what to base your work on
    • never merge a less stable branch into a more stable branch
    • bugfix, new feature, corrections and enhancements
  • Splitting changes into logically separate steps
    • If your description gets too long
    • and you begin to see that you have two independent changes squished together

Working on a project (con't) ⌘

  • Writing a good commit message
    • Should not require other devs to read actual changes to find out what the commit intends to do
    • Why
    • How
    • Alternate solutions (considered but discarded, etc)
    • Issue descr (number, pattern, etc)
  • Preparing changes for submission
    • Consider rebasing to do final-clean up of the history

Integrating changes ⌘

  • Submitting and describing changes
  • Change review
    • Wrong problem
    • Does not work
    • Fails best practices
    • Does not match reviewer preferences
  • Responding to reviews and comments

Other ⌘

  • Recovery is almost always possible
    • commit or stash before 'git reset --hard'
    • use reflog
    • messed wc? - do -i add, reset, checkout
    • use a lot 'git status'
  • Don't change the published history
    • use 'git revert' if necessary
  • Numbering and tagging releases
    • Choose proper convention

Other (con't) ⌘

  • Automate what is possible
    • facilitate your dev standards with client-side hooks
      • or enforced them with server-side hooks
      • hooks can protect against rewriting history
    • consider third-party solutions
      • to enforce rules for access control (gitolite, gitlab)
      • for code review (Gerrit or the pull requests of GitHub, Bitbucket, or GitLab)