Git - Best Practices

<slideshow style="nobleprog" headingmark="⌘" incmark="…" scaled="true" font="Trebuchet MS" >

title

Git Best Practices

author

Lukasz Sokolowski

</slideshow>

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
    • but DO NOT REWRITE THE PUBLISHED 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)