Git's Not What You Think It Is

Git's Not What You Think It Is

Slides from my talk at London Web Standards, June 2013

F28c4835c9e2277b6e04b86574532a2d?s=128

Abizer Nasir

June 17, 2013
Tweet

Transcript

  1. 2.

    Why Am I Here? • I’ve been convincing people to

    use try git since 2009. • I’ve since become a version control “rubber duck”.
  2. 3.

    What This Talk Is Not • A git tutorial •

    Reasons to use X over any other DVCS • A handy list of commands for you to use
  3. 4.

    What I Will Talk About • Some misconceptions about Git

    and some different ways of thinking about Version control. • I prefer questions at the end, but please don’t let that stop you if you really want to raise your hand.
  4. 6.

    Git Is A Safety Rope • Mark safe points as

    the code develops. • Easier to trash changes to a known point than to manually edit back to it. • Small, frequent changes that can be rolled up into more atomic commits. http://www.flickr.com/photos/mariachily/3382813383/
  5. 7.

    Git Is Communication • With your colleagues • With your

    clients • With your future or parallel self • A stored conversation about the history of a code base
  6. 8.

    Write Good Commit Messages • Short first line (less than

    50 chars) in the present imperative tense. • “change” not “changes” • A blank line: • Body, wrapped to less than 80 chars, that provides more information about the commit. • Describe what applying the change will do, not what was done to create the change.
  7. 9.

    Example Fixes issue #X in production ! This change uses

    a algorithm Y which is faster than than W. ! - I’m using a bullet point, for a list of changes. - I usually don’t need to list the changed files.
  8. 11.

    Help Git to Help You • Merge conflicts can still

    happen. Small commits that affect minimum subsets are easier to manage. • Git is not a substitute for project management. If many changes are happening to the same place in the same file, there will be conflicts. • Branches are cheap. Tags are cheap. Don’t be tempted to clean history too often. • Multiple repositories as backups are a good idea.
  9. 14.

    Changing History Is Bad When… • You change the history

    of any branch that somebody else is likely to have cloned and made changes to.
  10. 15.

    Changing History Is Not Bad When… • You are on

    a local branch that is not shared with anybody else. • You are on a branch that is synced with a private repository that only you use. • You roll up your list of small individual commits on your working branch into a larger atomic commit that you then push. • rebase is your friend. Seriously.
  11. 16.

    Reflog Is Your Lifeguard • Every change to HEAD is

    recorded. • State can be reconstructed using the shas.
  12. 17.

    Avoid pulling changes • Use `git fetch` and then inspect

    the upstream changes. • Use `git remote update` to fetch changes if the repository has multiple remotes. • Merge or rebase onto a temporary branch if you aren’t sure if the changes will apply cleanly.
  13. 19.
  14. 20.
  15. 27.

    Risks • Inexperienced team members (or clients) may mess up

    the repository. • History may be lost. • It could become hard to track development / test / production branches.
  16. 28.

    Protections • You don’t need to use every bit of

    git: add, push, commit, pull, fetch, checkout, status, are usually enough to get started • Git objects are immutable, changes are not irrevocable. Errors can be corrected. • Well named branches and a set of conventions are a great help. • Make people care, and they will care. Everyone wants to do a good job.
  17. 29.

    Git Flow • github.com/nvie/gitflow • datasift.github.io/gitflow • A set of

    scripts and workflows to define branching and merging. • Not everyone’s cup of tea but it helps when getting used to version control in a team.
  18. 31.

    Independent Branches • I’m sure you’ve seen the gh-pages feature

    on github • `git checkout --orphan <branchname>`
  19. 32.

    Branches Are Cheap • Never be afraid to create a

    branch. They are cheap. • Use some sort of naming convention so that you don’t get confused about them. • You can create a description for a branch • git branch --edit-description • If you want to park a branch - Create an annotated tag with a description.
  20. 33.

    Related Branches • Keep the main code in one branch.

    • Create a separate branch for a demo that uses the main code. • Use rebase liberally when only one branch is being used for development, but be sure to make it clear which the non-development branch is. • Use `cherry-pick` if changes are made in both branches.
  21. 34.
  22. 36.
  23. 38.

    132 Commands add am archive bisect branch bundle checkout cherry-pick

    citool clean clone commit describe diff fetch format-patch gc grep gui init log merge mv notes pull push rebase reset revert rm shortlog show stash status submodule tag gitk apply checkout-index commit-tree hash-object index-pack merge-file merge-index mktag mktree pack-objects prune-packed read-tree symbolic-ref unpack-objects update-index update-ref write-tree cat-file diff-files diff-index diff-tree for-each-ref ls-files ls-remote ls-tree merge-base name-rev pack-redundant rev-list show-index show-ref tar-tree unpack-file var verify-pack check-attr check-ref-format fmt-merge-msg mailinfo mailsplit merge-one-file patch-id peek-remote sh-setup stripspace daemon fetch-pack http-backend send-pack update-server-info http-fetch http-push parse-remote receive-pack shell upload-archive upload-pack config fast-export fast-import filter-branch lost-found mergetool pack-refs prune reflog relink remote repack replace repo-config annotate blame cherry count-objects difftool fsck get-tar-commit-id help instaweb merge-tree rerere rev-parse show-branch verify-tag whatchanged archimport cvsexportcommit cvsimport cvsserver imap-send quiltimport request-pull send-email svn
  24. 39.

    Porcelain / Plumbing add am archive bisect branch bundle checkout

    cherry-pick citool clean clone commit describe diff fetch format-patch gc grep gui init log merge mv notes pull push rebase reset revert rm shortlog show stash status submodule tag gitk apply checkout-index commit-tree hash-object index-pack merge-file merge-index mktag mktree pack-objects prune-packed read-tree symbolic-ref unpack-objects update-index update-ref write-tree cat-file diff-files diff-index diff-tree for-each-ref ls-files ls-remote ls-tree merge-base name-rev pack-redundant rev-list show-index show-ref tar-tree unpack-file var verify-pack check-attr check-ref-format fmt-merge-msg mailinfo mailsplit merge-one-file patch-id peek-remote sh-setup stripspace daemon fetch-pack http-backend send-pack update-server-info http-fetch http-push parse-remote receive-pack shell upload-archive upload-pack config fast-export fast-import filter-branch lost-found mergetool pack-refs prune reflog relink remote repack replace repo-config annotate blame cherry count-objects difftool fsck get-tar-commit-id help instaweb merge-tree rerere rev-parse show-branch verify-tag whatchanged archimport cvsexportcommit cvsimport cvsserver imap-send quiltimport request-pull send-email svn
  25. 40.

    You Don’t Need To Use It ALL • add •

    commit • fetch • merge • branch • checkout • push • status
  26. 42.
  27. 43.

    Start With The Basics • Use the basic commands to

    start with. Start using automation when you become comfortable with them. • Use a GUI if you have to. • If you want to do something complex, look it up and try to do it. Repetition builds knowledge. • Learn the Git object model, and everything becomes a lot clearer.