Taller sobre Git (XPWeek 2013)


Published on

Taller sobre Git realizado para la XPWeek 2013

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

Taller sobre Git (XPWeek 2013)

  1. 1. Git WorkshopBy Israel Alcázar
  2. 2. First of all…Clear your mind
  3. 3. GIT BASIS
  4. 4. History1972: Source Code Control System (SCCS): Closed source,free with Unix1982: Revision Control System (RCS) : Cross platform.Open Source. More features and faster.They only could work with one file at the same time1986-1990: Concurrent Versions System (CVS):Concurrent users working on the same file. Open Source.
  5. 5. History2000: Apache Subversion. Snapshot of the directory notjust the file. Transactional commits.2000: BitKeeper SCM. Closed source, proprietary.Distributed version control.The community version was free. Used for source code ofthe Linux kernel from 2002-2005April 2005: The community version not free anymore
  6. 6. Git originIt was born in 2005, developed by the kernel linuxteam, leaded by Linus Torvalds.Tries to improve BitKeeper.
  7. 7. What is a DVCSA programmer,a repositoryEveryone has a local repositoryA programmer,a repositoryA programmer,a repositoryThey can share code
  8. 8. Git: Goals§  Fast§  Simplicity§  Multi Branches§  Distributed§  Able to manage big projects
  9. 9. Git: Hits§  Git was born in 2005§  GitHub starts in 2008 as a git repositorieshosting§  2009: Github 50000 repos y 100000 usuarios.§  2011: Github 2M repos y 1M usuarios
  10. 10. SnapshotsOther VCSStore info as a list of file-based changes
  11. 11. SnapshotsGit: Set of snapshotsTakes a picture of what all your files look like at thatmoment and stores a reference to that snapshot,
  12. 12. SnapshotsGit: Set of snapshotsIf files have no changes, Git doesn’t store the fileagain
  13. 13. Local operationsEvery operation is done in your local repository.You don’t need connection with some other server.You can work offline without problemsFaster than centralized repositories
  14. 14. IntegrityEverything is identified by hashes.It is impossible to change the content of any file ordirectory without Git knowing about it.Can’t lose information or get file corruption withoutGit being able to detect it.Checksum (sha1):24b9da6552252987aa493b52f8696cd6d3b00373  
  15. 15. InstallationYou can install your Git repo here:http://git-scm.com/downloads
  16. 16. Set Up GitIt’s time to configure your settings:UsernameEmail
  17. 17. Adding .gitignoreA gitignore file specifies intentionally untrackedfiles that git should ignore.Files already tracked by git are not affected.Located in the root folder.
  18. 18. Adding .gitignorePatterns#: Comments!: Negates the patternfoo/: Directory named foo (not a file foo)*: Everything*.html , !foo.html, /*.js
  19. 19. Create your first repository1) Create a specific folder where your repository isgoing to be created.2) $ git init
  20. 20. Create a repositoryYou can create or clone a Git repository:§  Create$ git init§  Clone$ git clone <remote-url>
  21. 21. Create a repositoryClone a repo:
  22. 22. GIT INTERNALS (I)
  23. 23. Internal AreasGit has the following areas:
  24. 24. Working Directory / WorkspaceThe filesystem where your files are managed!
  25. 25. Local repositoryThe Git repo in your local machine.You can create that repo with git init or git clonecommands.
  26. 26. Upstream repositoryThe remote repository where you can push or pullyour commits.Default name is ‘origin’
  27. 27. Staging Area / IndexIntermediate zone where next commit is prepared.
  28. 28. File Status LifecycleEach file in your working directory can be in one oftwo states: tracked or untracked.Tracked files are files that were in the lastsnapshot; they can be unmodified, modified, orstaged.Untracked files are everything else.
  29. 29. File Status LifecycleTracked  
  30. 30. StatusYou can check your repo status:$ git status
  31. 31. GIT INTERNALS (II)
  32. 32. HEADHEAD is a pointer that points to the currentbranch.When you change to a different branch, HEADchanges to point to the new one.The current HEAD is local to each repository,and is therefore individual for each developer.
  33. 33. HEADHands-on$ cd .git$ cat HEADref: refs/heads/master$ git checkout –b newFeature$ cat HEADref: refs/heads/newFeature
  34. 34. Double Dash --You can use -- to:§  Separate options from a list of arguments:$ git diff –w master origin -- tools/Makefile§  Separate an explicitly identify filenames# Checkout the tag named “main.c”$ git checkout main.c#Checkout the file named “main.c”$ git checkout -- main.c
  35. 35. Basic Flow: First Commit1. Adding a File to Your Repository§  One file$ git add <filename>$ git add *.c$ git add index.html§  A directory$ git add <directory>
  36. 36. Basic Flow: First Commit2. Commit One file$ git commit –m “message”If the file is managed by the repo:$ git commit –am “message”
  37. 37. Basic Flow: First Commit3. Remove a file from the staging area#Before first commit$ git rm --cached <file>#After first commit$ git reset HEAD <files>
  38. 38. Basic Flow: First CommitWorking  Area   Index   Local  Repository  git  add  <files>  git  commit  git  rm  -­‐-­‐cached  <file>  git  reset  HEAD  <file>  
  40. 40. Ref§  A ref is a SHA1 hash ID that refers to an objectwithin the Git object store. Although a ref mayrefer to any Git object, it usually refers to acommit object.§  A symbolic reference , or symref , is a name thatindirectly points to a Git object. It is still just aref.§  Local topic branch names, remote trackingbranch names, and tag names are all refs.
  42. 42. SymrefsHEADAlways refers to the most recent commit on thecurrent branch.When you change branches, HEAD is updated torefer to the new branch’s latest commit.
  43. 43. SymrefsORIG_HEADCertain operations, such as merge and reset,record the previous version of HEAD in ORIG_HEADjust prior to adjusting it to a new value.You can use ORIG_HEAD to recover or revert to theprevious state or to make a comparison.
  44. 44. SymrefsFETCH_HEADWhen remote repositories are used, git fetchrecords the heads of all branches fetched in thefile .git/FETCH_HEAD .FETCH_HEAD is a shorthand for the head of thelast branch fetched and is only valid immediatelyafter a fetch operation.
  45. 45. SymrefsMERGE_HEADWhen a merge is in progress, the tip of the otherbranch is temporarily recorded in the symrefMERGE_HEAD .MERGE_HEAD is the commit that is being mergedinto HEAD .
  46. 46. COMMITS
  47. 47. What is a commitA commit is used to record changes to arepository.When a commit occurs, Git records a “snapshot” ofthe index and places that snapshot in the objectstore.
  48. 48. What is a commitA commit is the only method o introducingchanges to a repository.Commits are often introduced explicitly by adeveloper but Git can introduce commits (as in amerge).
  49. 49. Format$ git commit -m “Message”$ git commit -am “Message”$ git commit -m “Message” <file>$ git commit --amend
  50. 50. Identifying CommitsEvery Git commit is a hex-digit SHA1 ID.Each commit ID is globally unique—not just forone repository, but for any and all repositories
  51. 51. Relative Commit NamesGit provides mechanism for identifying a commitrelative to another reference:^: One commit before (master^, master^^,HEAD^,etc)~: N commits before (master~2, HEAD~4)
  52. 52. Relative Commit NamesC~2              C^    C  C~3  C~1    C  is  a  commit  git  show-­‐branch  -­‐-­‐more=35  C^^    
  53. 53. Commit historyYou can see the history of commits:$ git log (same as git log HEAD)$ git log <commit-name>: The log starts at thenamed commit.E.g: $ git log masterhQp://www.kernel.org/pub/soVware/scm/git/docs/v1.5.0.2/git-­‐log.html  
  54. 54. Commit historySpecify a commit range (since..until)$ git log master~12..master~10Show only commits for a path$ git log -- <path>E.g. git log -- README3.txt
  55. 55. Commit historyShow commits with a regular expression$ git log --grep=‘reg-exp’--no-merges: Removes merge commitsShow changes during a time$ git log --since=“2.weeks.ago”$ git log --before={3.weeks.ago} --after={2010-04-18}
  56. 56. Commit historySpecify a format--pretty=short: Short format--abbrev-commit: SHA id abbreviation-p: Prints the changes introduced by the commit--stat: Enumerates the files changed in a commit
  57. 57. Commit historyShow the graph--decorate --graph --oneline
  59. 59. Fixing commits Flow1. Discard changes in a file in the index to thecopy in working directory$ git checkout -- <files>2. Reverting a file some commits before$ git checkout <commit-id> file
  60. 60. Basic Flow: ResetYou can reset some status of your repository:$ git reset$ git reset HEAD <file>$ git reset --soft <commit-id>$ git reset --hard <commit-id>$ git reset --mixed <commit-id>
  61. 61. Basic Flow: ResetWorking  Area   Index   Local  Repository  git  add  <files>  git  commit  git  reset  -­‐-­‐soV  HEAD^  git  rm  -­‐-­‐cached  <file>  git  reset  HEAD  <file>  git  checkout  -­‐-­‐  <file>  git  reset  -­‐-­‐mixed  HEAD^  
  63. 63. ConceptsA remote repository is a reference to anotherrepository.A remote is a shorthand name for a Git URL.You can define any number of remotes in arepository
  64. 64. Remotes$ git remoteadd: adds a remoterm: deletes a remoterename: rename a remote repo-v: list all remotes
  65. 65. RemotesIn addition to git clone , other common Git commands thatrefer to remote repositories are:§  git fetch: Retrieves objects and their related metadatafrom a remote repository§  git pull: Fetch + Merge§  git push: Transfers objects and their related metadata toa remote repository§  git ls-remote: Shows references within a remote
  66. 66. Tracking branchesUsed exclusively to follow the changes fromanother repository.Not merge or make commits onto a trackingbranch
  67. 67. Tracking branches$ git fetch <remote-repo>$ git checkout --track –b <local-branch> <remote-repo> / <remote-branch>
  68. 68. Push to a remote branchesPush$ git push <repo> <branch>Force Push$ git push –f <repo> <branch>¡Be careful forcing the push!
  69. 69. Fetch$ git fetch <repo> <branch>
  70. 70. Merge$ git merge <branch>New  commit  is  created  
  71. 71. Abort a merge$ git reset --hard ORIG_HEAD
  72. 72. Pull$ git pull <repo> <branch>Git Fetch + Git Merge à Exactly the same asdoing separated
  73. 73. MERGE
  74. 74. What is a mergeUnifies two or more commit history branches.Most often, a merge unites just two branches.Git supports a merge of three, four or manybranches at the same timeAll the branches to be merged must be present inthe same repository.
  75. 75. Merge examplesYou have to switch to the target branch andexecute the merge:$ git checkout destinyBranch$ git merge anotherBranch
  76. 76. Fast ForwardA simple linear history advancement operationFast forward has happened in origin from B to X
  77. 77. Fast ForwardIf another developer has pushed some changes (C,D) you can’t push with fast forward.You should merge your changes first.
  78. 78. Fast Forward Merging
  80. 80. What is a branchA separated line of development.A split from a kind of unified, primal state, allowingdevelopment to continue in multiple directionssimultaneously and, potentially, to producedifferent versions of the project.Often, a branch is reconciled and merged withother branches to reunite disparate efforts.
  81. 81. What is a branch
  82. 82. Branch names§  Default branch in a repo is “master”§  Use an arbitrary name§  / is allowed (not at the end)§  No slash-separated component can begin with a dot(. ). feature/.new is invalid§  Cannot contain two consecutive dots (..)§  Cannot contain whitespace, ~ , ^, : ,?, *, [
  83. 83. Creating branchesFrom the active branch:$ git branch <branch-name>: Only creates a branch$ git checkout -b <branch-name>: Creates andswitches to the new branch
  84. 84. Listing branchesList branches names found in the repository:$ git branch$ git branch –aLists all branches (also tracked branches)
  85. 85. Viewing branches$ git show-branch <branch1> <branch2>$ git show-branch bug/*Limits the result to the specific branches names.
  86. 86. Switching branchesYour working directory can reflect only one branch ata time.To start working on a different branch:$ git checkout <branch-name>
  87. 87. Delete local branchesYou cannot delete the active branch.$ git branch –d <branch>: Deletes if you have done merge.$ git branch –D <branch> : Force the action even though youhaven’t done merge.
  88. 88. Delete remote branches2.- Push changes$ git push <remote> :<branch>
  89. 89. Pull remote branchesWhen you clone a repository you can only clonethe master branch.$ git branch –a : View every branch you have got.$ git checkout -b <local-branch> <repo>/<remote-branch>: Pull a remote branch into alocal branch and switch it.$ git branch <local-branch> <repo>/<remote-branch>: Pull a remote branch into a local branch.
  90. 90. TAGS
  91. 91. Tags vs BranchesA tag is meant to be a static name that does notchange or move over time. Once applied, youshould leave it alone.A branch is dynamic and moves with each commityou make. The branch name is designed to followyour continuing development.
  92. 92. Tags vs BranchesYou can give a branch and a tag the same name.If you do, you will have to use their full ref namesto distinguish them.For example, you could use refs/tags/v1.0 andrefs/heads/v1.0
  93. 93. Commands$ git tag : List tags$ git tag –a <name> -m “text to …”: Create a tag$ git show <name>$ git push <repo> --tags: Sends all tags$ git push <repo> <tag-name>: Sends the tag
  94. 94. Types§  LightweightLike a branch that doesn’t change. A pointer to aspecific commit§  AnnotatedAre stored as full objects in the Git database. Theyare checksummed; contain the tagger name, emailand date. Can be signed and verified.
  95. 95. WORKFLOWS
  96. 96. Workflow1) Two main branches: Dev & MasterMaster  Dev  
  97. 97. WorkflowMaster  Feature  1  Dev  Tag  0.1  To  Prod  2) One feature / one branch (local)Accept?  Feature  2  Accept?  
  98. 98. Workflow3) Every bug is fixed in an isolated branchMaster  Ho]ixes  Dev  Tag  0.2  Inserts  bug  into  dev  Tag  0.1  To  Prod  
  99. 99. STASHING
  100. 100. DescriptionAn intermediate area where you can commitunstable code that you can not deal with.Use stash when you want to record the currentstate of the working directory and the index, butwant to go back to a clean working directory.
  101. 101. stashingA great way to pause what you are currentlyworking on and come back to it later.$ git stash: Stash your changes away$ git stash apply: Bring work backE.g: git stash apply stash@{1}$ git stash list: List of stashes
  102. 102. stashing$ git stash pop: apply the top stash$ git stash drop <id>: Manually delete stashes$ git stash clear: Delete al of the stored stashes.
  103. 103. Commands-  git stash list-  git stash save "mensaje”-  git stash pop-  git stash show stash@{0}-  git stash apply stash@{0}-  git diff stash@{0}
  104. 104. PreguntasIsrael  Alcázar  israelalcazar@gmail.com  @ialcazar