Git - Best Practices

title

Git Best Practices

author

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
    • 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)

Some cheats

git checkout file_name VS git restore file_name
git reset file2 VS git restore --staged
git reset --hard HEAD VS git reset --hard cbd123 (not HEAD)
git branch nb 84fe ; git checkout nb VS git checkout -b nb 84fe VS git switch -c nb 84fe
git branch --no-merged --merged ; git branch --verbose --all

Some hands-on

• fetch-reset-stash-pull-stash way

fetch-reset-stash-pull-stash

• one line history, no issues like with rebasing

echo same >> js/logo_jq1.js           ## changes by me, same filo and line as 'wc1' coder's
git commit -am "mine better always!"  ## the usual snapshot
git push                              ## will be rejected, because 'wc1' pushed before me 
git fetch                             ## instead of 'git pull', so no eventual conflict(s) processing yet
git reflog                            ## checking where are we, good habit just before resetting
git reset --soft HEAD@{1}             ## vivisecting last rev (or usually the one which serves the potential confl, but NOT PUSHED yet!) 
git status                            ## to look around and double-tripple check if we have what we need
git stash                             ## hiding the changes 'under the carpet' for the later good
git pull                              ## or 'git merge FETCH_HEAD', depending on the business context
git stash apply                       ## restoring the leftovers (-;
git status                            ## using our 'bestie', habitually (=
git commit -m "mine is always better" ## after solving the confl
git stash drop                        ## cleaning, cleansing