Your SlideShare is downloading. ×
Introduction to Git
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Introduction to Git

400
views

Published on

A brief introduction to git commands and architecture with descriptive diagrams and explanations.

A brief introduction to git commands and architecture with descriptive diagrams and explanations.

Published in: Technology

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
400
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Up and Running with GIT Atish Goswami PHP Developer at SANIsoft
  • 2. What is Git • Keeps track of your changes  Especially text changes  Version 1, Version 2, Version 3 • Version Control System (VCS) • Source Code Management (SCM)
  • 3. Examples of version control (non-source code) • File naming (Budget_v4.xls, Logo_v2.gif) • Microsoft Word's Track Change • Adobe Photoshop's History • Wikis • Undo: control+z(windows), command+z(Mac)
  • 4. History • Source Code Control System (SCCS)  1972, closed source, free with Unix • Revision Control System (RCS)  1982, open source • Concurrent Versions System (CVS)  1986-1990, open source • Apache Subversion (SVN)  2000, open source
  • 5. Turn of Events • BitKeeper SCM  2000, closed source, proprietary  Distributed version control  “community version” was free  Used for source code of the linux kernel for 2002-2005  Controversial to use proprietary SCM for an open source project  April 2005: the “community version” not free anymore
  • 6. Git was born • April 2005 • Created by Linus Torvalds • Replacement for BitKeeper to manage Linux kernel source code
  • 7. What were the features • Distributed version control • Open source and free software • Compatible with Unix-like systems (Linux, Mac Os X, and Solaris) and Windows • Faster than other SCMs (100x is some cases) • Better safeguards against data corruption
  • 8. Git is a hit • Explosion in popularity • No official statistics • Github launched in 2008 to host Git repositories  2009: over 50,000 repos, over 100,000 users  2011: over 2 million repos, over 1 million users
  • 9. Centralized Version Control • Popular version controls of the past like RCS, CVS, SVN and SCSS • All of them use central code repository model  One central place where you store the master copy of the your code  Check out a copy of the code from the master repo  Work with the code, make changes and submit back to the master/central repository  Other users can also work from that repo, make and submit there changes  Users stay up to date with central code repository by pulling down and update any changes
  • 10. Distributed Version Control • Different users (or teams of users) maintain their own repos, instead if working form a central repository • Changes are stored as “changes sets” or “patches”  Tracks changes, not versions  Different from CVS and SVN, which track versions  Change sets can be exchanged between repositories • “merge in change sets” or “apply patches”
  • 11. Distributed Version Control • No single master repository; just many working copies  Each with their own combination of change sets • Imagine changes to document as sets A, B, C, D, E, F  Repo 1: A, B, C, D, E, F  Repo 2: A, B, C, D  Repo 3: A, B, C, E  Repo 4: A. B, E, F
  • 12. Advantages of DVS • No need to communicate with a central server  Faster  No network access required  No single failure point • Encourages participation and “forking” of projects  Developers can work independently  Submit changes sets for inclusions or rejection
  • 13. Who should use Git ? • Anyone wanting to track edits  Reviews a history log of changes made  view differences between versions  Retrieve old versions • Anyone needing to share changes with collaborators • Anyone not afraid of command-line tools
  • 14. Programmers and Developers  HTML, CSS, JavaScript  PHP, Ruby, Ruby on Rails, Perl, Python, ASP  Java, C, C++, C#, Objection-C  ActionScript, CoffeeScript, Haskell, Scala, Shell scripts • Not as Useful for tracking non-text files  Images, movies, music, fonts  Word processing files, spreadsheets, PDFs
  • 15. Git Installation
  • 16. Where to get Git  Mac • http://git-scm/download/mac  Windows • http://git-scm/download/windows  Linux • http://git-scm/download/linux
  • 17. Configuration  System • /etc/gitconfig • Program FilesGitetcgitconfig  User • ~/.gitconfig • $HOME.gitconfig  Project • my_project/.git/config
  • 18. Commands to Configuration  System • git config --system  User • git config --global  Project • git config
  • 19. Initializing a repository git init
  • 20. Process to follow  Make changes  Add the changes • git add [filename/directory]  Commit changes to the repository with message • git commit -m [commit message]
  • 21. Writing Commit Messages  Commit message best practices • Short single-line summary (less than 50 characters) • Optionally followed by a blank line and more complete description • Keep each lines to less than 72 characters • Write commit messages in preset tense, not past tense  “fix bug” or “fixes bug,” not “fixed bug”
  • 22. Writing Commit Messages  Commit message best practices • Bullet points are usually asterisks or hyphens • Can add “ticket tracking number” form bugs or support requests • Can develop shorthand for your organization  “[css, js]”  “bugfix:”  “#38456-”
  • 23. Writing Commit Messages  Commit message best practices • Be clear and descriptive  Bad: “fix typo”  Good: “Add missing > in project section of HTML”  Bad: “Update login code”  Good: “Changed user authentication to use Blowfish”  Bad: “Updates member report, we should discuss if this is right next week”
  • 24. One Good Example T23094 – Fixes bug in admin logout When an admin logged out of the admin area, they could not log in to the member area because their session[:userid] was still set to the admin ID. This patch fixes the bug by setting session[:userid] to null when user logs of the any area.
  • 25. Viewing Commit Logs git log commit 330ec85cb900530edbfa0ac73519f29b4150e436 Author: Atish Goswami <atishgoswami@gmail.com> Date: Wed Apr 23 02:15:47 2014 +0530 Fix login page html for responsive view
  • 26. Advanced Commit Viewing git log -n [limit] git log --since=[yyyy-mm-dd] git log --until=[yyyy-mm-dd] git log --author=”[name]” git log --grep=”[pattern]”
  • 27. Git Concepts and architecture
  • 28. Two Tree architecture
  • 29. Three Tree architecture
  • 30. Three Tree architecture
  • 31. Git Workflow
  • 32. Commit Hash Values (SHA-1)  Git generates a checksum for each change set • checksum algorithms convert data into a simple number • same data always equals same checksum  Data integrity is fundamental • changing data would change checksum  Git uses SHA-1 algorithm to create checksums • 40-character hexdecimal string (0-9,
  • 33. Referring to Commits
  • 34. The HEAD Pointer  pointer to “tip” of current branch in repository  last state of repository, what was last checked out  points to parent of the next commit • where writing commits takes place
  • 35. Making changes  git add [filename/directory]  git status  git diff  git diff --staged  git rm [filename/directory]  git mv [filename-old]<space>[filename-new]  git commit  git commit -am
  • 36. Undoing changes  git checkout – [filename]  git reset HEAD [filename]  git commit –amend -m “[Message]”  git checkout [commit hash] – [filename.txt]  git revert [commit hash]  git clean -n → Trial run  git clean -f → actual action
  • 37. git reset  --soft • Does not change staging index or working directory • git reset –soft [commit hash]  --mixed (default) • changes staging index to match repository • does not change working directory • git reset –mixed [commit hash]  --hard • Changes staging index and working
  • 38. Ignoring Files  Using .gitignore file in the root of the project directory  Project/.gitignore  Very basic regular expression • * ? [aeiou] [0-9]  Negate expression with ! • *.php • !index.php  Ignore all files in a directory with trailing slash • asset/video/  Comment lines begin with #, blank lines are
  • 39. What to ignore  complied source code  packages and compressed files  logs and databases  operating system generated files  user-uploaded assets (images, PDFs, videos)  Helpful Links • https://help.github.com/articles/ignoring-files • https://github.com/github/gitignore
  • 40. Globally Ignore Files  Ignore files in all repositories  Settings not tracked in repository  user-specific instead of repository-specific git config –global core.excludesfile ~/.gitignore_global
  • 41. Ignoring Tracked Files  Want it in your working directory  But don't want git track it any more git rm –cached [filename]
  • 42. Tracking Empty Directories • Git doesnot track directories • Git track files only and keep track of any directory required to track that file • Add empty or .gitkeep to empty directory
  • 43. Navigating to a Commit • Tree-ish  Full SHA-1 hash  Short SHA-1 hash • At least 4 characters • Umambiguous (8-10 characters)  HEAD pointer  Branch reference, tag reference  ancestry
  • 44. Ancestory • Parent commit  HEAD^, acf87504^, master^  HEAD~1, HEAD~ • Grandparent commit  HEAD^^, acf87504^^, master^^  HEAD~2 • HEAD^^^, acf87504^^^, master^^^ • HEAD~3
  • 45. Tree-ish • git help ls-tree • git ls-tree HEAD • git ls-tree master • git ls-tree master [directory] • git ls-tree master^ [directory] • git ls-tree [object hash]
  • 46. Getting More From Git Log • git log --online • git log –online -[no of commits to show] • git log –since=”[yyyy-mm-dd]” • git log –until=”[yyyy-mm-dd]” • git log –before=”[yyyy-mm-dd]” • git log –since=”2 weeks ago” --until=”3 days ago” • git log –since=”2.weeks” --until=”3.days”
  • 47. Getting More From Git Log • git log –author=”Atish” • git log –grep=”temp” • git log [sha hash from]..[sha hash to] –oneline • git log [sha hash from]..[leave empty to point HEAD] [filename] • git log -p -> Git Patch option • git log -p c4b913e.. index.html • git log –stat –summary • git log –format=[oneline|short|medium|full|fuller|email|raw] • git log –graph • git log –online –graph –all --decorate
  • 48. Getting More From Git Log • git show [sha value] • git show –format=online HEAD • git show –format=online HEAD^ • git show –format=online HEAD~2 • git show –format=online HEAD~3
  • 49. Comparing Commits • git diff [sha value] • git diff [sha value]..[sha value till] • git diff [sha value] filename • git diff [sha value]..[sha value till] filename • git diff –stat –summary 1506576..HEAD • git diff –ignore-space-change or -b • git diff –ignore-all-change or -w
  • 50. Git Branching • Branches are cheap  Try new ideas  Isolate features or sections of work • One working directory • Fast context switching
  • 51. Git Branching Commands • Show branches  git branch • Create branch  git branch [branch name to create] • Switch to a branch  git checkout [branch name] • Create and Switch in a single step  git checkout -b [new branch name] • Branch diff  git diff [branchname]..[other branch name]
  • 52. Merging Branches • Merge a branch  git merge [branchname to merge] • Fast Forward Merge • No Fast Forward  git merge –no-ff [branch name] • Only Fast Forward  git merge –ff-only [branch name]
  • 53. Resolving Conflicts • Abort merge  git merge --abort • Resolve the conflicts manually  Open files and see for changes to keep  git add [files that had merge conflict]  git commit → show a auto commit message • Use a merge tool
  • 54. Reduce Merge Conflicts • Keep lines short • Keep commits small and focused • Beware stray edits to whitespace  Spaces, tabs, line returns • Merge often • Track changes to master
  • 55. Stashing Changes • It is not like commiting • Helps keep your experimental files save • Does add anything to the log history • Its like a temporary storage space
  • 56. Stashing Changes • Adding/Saving a stash change – git stash save “[message]” • Listing Stashes – git stash list – stash@{n}: On [branchname]: [message] • View Stashes Changes git stash show stash@{n} → diff stat git stash show -p stash@{n} → patch stat
  • 57. Stashing Changes • Applying a stashed change → git stash apply [stash@{2}] → git stash pop [stash@{2}] • Deleting Stashed Items → git stash drop [stash@{2}] → git stash clear
  • 58. Remotes
  • 59. Remote Repos • Viewing remotes – git remote – git remote -v • Adding remote to local repo – git remote [alias] [url] • Removing remote from repo – git remote rm origin
  • 60. Remote Repos • Viewing remotes branches – git remote -r – git remote -a • Copying/Cloning Remote Repos – git clone [url] [folder to create] • Removing remote from repo – git remote rm origin
  • 61. Remote Repos • Pushing Changes – git push [remote] [branchname] • Syncing Remote with Local – git fetch [remote]
  • 62. Good Practices • Fetch before you work • Fetch before you push • Fetch often
  • 63. Merging Fetched Changes • Viewing/Comparing Remote with Local – git diff [remote]/[branchname].. [branchname] • Merging Changes Into Local – git merge [remote]/[branchname] • git pull = git fetch + git merge
  • 64. Working with remote branches • Checkout a remote branch – git branch [remote branch name] • Delete a remote branch – git push [remote] :[remote branch name] – git push origin –delete non_tracking