Essential git for developers


Published on

Slides from my talk at ALT.NET Cork.
Unlike centralized version control systems, the distributed nature of Git allows you to be far more flexible in how developers collaborate on projects.In this session I'll take you through a quick tour of the essential git commands with some demos.We'll cover branching and merging strategies, pull requests ,working on open source (GitHub etc), git clients and git deployments to the cloud.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Essential git for developers

  1. 1. Essential Git For Developers CORK ALT.NET DECEMBER 2013
  2. 2. What is Git? Distributed version control system Open source ,written in C Linus Torvalds 2005 to maintain the linux kernel
  3. 3. Why Git? •Focuses on content not files •Opt in when it comes to commits •Open, not closed– open source model of working is baked into the software •Distributed - works almost entirely offline •It changes how you work – commit more often, making code reviews easier •Browsing history is lightening fast •Non-linear development
  4. 4. Centralized vs. Distributed Centralised Distributed History only on the server Complete history of the repo locally Commit changes online only Nearly every operation is local (offline) you can commit locally & branch locally Down tools if server is down No hassle if server is down, redundant by default Branching is difficult Branching is really easy & lightweight Branching is no longer a dirty word Everyone commits to main repo ,typically you check More flexible workflows, you commit changes more in when your work is complete regularly
  5. 5. Demo – create a repo and add some files
  6. 6. Commands • $git init • $git add <fileName> • $git commit –m <commit message> • $git status • $git log • $git command --help
  7. 7. Staging Working Directory git add Staging Area git commit Repository
  8. 8. File Status
  9. 9. Git stores snapshots, not differences
  10. 10. Demo – working with remotes
  11. 11. Commands • $git remote add <name> <url> • $git push <remote name> <local branch name> • $git clone <path to repo>
  12. 12. Git on the Server Protocols –SSH , HTTP ◦ HTTP - slower but allows anonymous access to the files ◦ SSH - faster but everyone needs a unique SSH key Hosting Options ◦ Self Hosted (GitLab CE) ◦ GitHub, BitBucket & many more …
  13. 13. Demo – web hook integration
  14. 14. $git pull command $git fetch + $git merge = $git pull
  15. 15. .gitignore file Tells git to ignore specific files / folders
  16. 16. Branching • Think of a branch as simply a movable pointer to one of the commits in your repository • $git branch < new branchname > • $git checkout <branchname> • $git merge <branchname>
  17. 17. Fast forward merge Before merging After merge
  18. 18. 3 way merge Before merging After merge
  19. 19. Demo – branching and merging
  20. 20. Git-Flow •Vincent Driessen's branching model •Defines a branching model designed around the project release, suitable for managing larger projects / large teams
  21. 21. TIME
  22. 22. Rebasing “Take my commits and replay them after the HEAD of another branch.” • take all the changes that were committed on one branch and replay them on another one. • Moves a branch to a new base commit • Completely rewrites history! • Don’t do this on a shared branch
  24. 24. Forking & Pull Requests
  25. 25. Demo – exploring the repo history
  26. 26. Debugging git blame $git blame [-L ine1,line2]] <file> • Lets you see when each line of a method was edited and by whom
  27. 27. Debugging git bisect $ git bisect start $ git bisect bad HEAD $ git bisect good 1b6d
  28. 28. Cherry Picking If you want to get one single commit out of a branch $git cherry-pick <sha-1_commit>
  29. 29. Git on Windows GUI Clients Shells SourceTree (free) Bash GitHub for Windows Posh-git Git GUI for Windows Powershell TortoiseGit Cmd
  30. 30. Advice for getting started •Learning curve •Start with the command line, not the GUI • Agree a good branch strategy with your team up front • (Almost) every should be short lived, and kept up to date with master •Commit often, perfect later & user meaningful commit messages
  31. 31. Thanks for listening! twitter : @AIDANJCASEY