Lets Git Together
•Download as PPTX, PDF•
2 likes•249 views
The document provides an overview of Git, including its history and development, how it compares to other version control systems like SVN, basic Git commands and workflows, branching and merging, resolving conflicts, and best practices. It discusses how Git is decentralized, offers offline support, and fast/reliable. It also recommends some GUI tools for visualizing Git repositories and resolving conflicts.
More Related Content
What's hot
What's hot (19)
Similar to Lets Git Together
Similar to Lets Git Together (20)
Recently uploaded
Recently uploaded (20)
Lets Git Together
- 1. $> git init
- 2. Short History Linus uses BitKeeper to manage Linux code Ran into BitKeeper licensing issue Liked functionality Looked at CVS as how not to do things April 5, 2005 - Linus sends out email showing first version June 15, 2005 - Git used for Linux version control
- 3. Centralized VC vs. Distributed VC Central Server Remote Server
- 4. SVN vs. Git SVN Server Git Server
- 5. SVN Centralized Checkouts Branching Conflict Resolution No Offline support Simple and easy to learn
- 6. GIT DeCentralized Fast, Reliable, Consistent Branching / Checkouts Conflict Resolutions Offline support Wide range of deployment hooks
- 7. SVN Commands co - checkout list add commit update Git Commands init clone status add commit push pull / fetch
- 9. Git Work-flow Remote Server Working copy Stage Area > git add file-name
- 10. Git Work-flow Remote Server Local Repo Working copy Stage Area > git commit -m ‘message’
- 11. Git Work-flow Remote Server Local Repo Working copy Stage Area > git push origin master
- 12. Cloning a repository > git clone url > git clone git@github.com/username/myproject.git > git clone https://github.com/username/myproject.git > cd myproject
- 13. Git config Global configuration > git config --global user.name your.name > git config --global user.email your.email Project configuration > cd myproject > git config user.name your.name > git config user.email your.email
- 14. Creating a new Repo Initialized empty Git repository in ~/myproject/.git [master (root-commit) 7106a52] my first commit 1 file changed, 1 insertion(+) create mode 100644 README.txt > mkdir myproject > cd myproject > git init > touch README.txt > git add . > git commit -m 'my first commit'
- 15. Adding a remote server > git remote add origin git@github.com/username/myproject.git > git remote -v origin git@github.com/username/myproject.git (fetch) origin git@github.com/username/myproject.git (push)
- 16. Adding a remote server > git remote add origin git@github.com/username/myproject.git > git remote -v origin git@github.com/username/myproject.git (fetch) origin git@github.com/username/myproject.git (push) > git remote add production git@github.com/live/myproject.git > git remote -v origin git@github.com/username/myproject.git (fetch) origin git@github.com/username/myproject.git (push) production git@github.com/live/project.git (fetch) production git@github.com/live/project.git (push)
- 17. Adding files Will stage your file to be committed Conventionally `git add .` should be avoided Will stage all your deleted files to be deleted from repository > git add -u > git add [file-name | dot(.)]
- 18. Commit files Will commit your file to your local repository With inline message Equivalent of [git add . + git commit -m] > git commit > git commit -m ‘message’ > git commit -am ‘message’
- 19. Pull Will pull latest commits from the remote repository and try to auto merge them > git pull remote branch > git pull origin master
- 20. Push Will push your commits to the remote repository Another dangerous command. Overrides any previous commit/changes > git push remote branch > git push origin master > git push -f origin master
- 21. Branching Branches in Git basically is a collection of commits By default ‘master’ branch is available in all repositories > git branch > git branch new-branch > git branch -D your-branch lists all branches creates new branch deletes a branch
- 22. master A > git commit –m ‘my first commit’ Branching
- 23. master > git commit (x2) A B C Branching
- 24. bug123 master > git checkout –b bug123 A B C Branching
- 25. master > git commit (x2) A B C D E bug123 Branching
- 26. master > git checkout master A B C D E bug123 Branching
- 27. bug123 master > git merge bug123 A B C D E Branching
- 28. master > git branch -d bug123 A B C D E bug123 Branching
- 29. Advance branching and merging
- 30. Branches Illustrated master A B C D E F G bug456
- 31. master A B C D E F G bug456 > git checkout master Branches Illustrated
- 32. master A B C D E F G > git merge bug456 H bug456 Branches Illustrated
- 33. master A B C D E F G bug456 Branches Illustrated
- 34. master A B C D E > git rebase master F G bug456 Branches Illustrated
- 35. master A B C D E > git checkout master > git merge bug456 F G bug456 Branches Illustrated
- 36. More git commands Shows difference between working copy and last revision > git diff [file-name]
- 37. More git commands Shows difference between working copy and last revision Shows a complete history of commits with dates and author-name > git diff [file-name] > git log
- 38. More git commands Shows who/when made changes to a file line- by-line > git blame [file-name]
- 39. More git commands Shows who/when made changes to a file line- by-line Renames a branch > git blame [file-name] > git branch -m <old-name> <new-name>
- 40. More git commands Remote branch tracking Updates your local repository with remote branches > git fetch
- 41. More git commands Stashing takes the dirty state of your working directory - that is, your modified tracked files and staged changes - and saves it on a stack of unfinished changes that you can reapply at any time. > git stash
- 42. > git status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: index.html # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # # modified: lib/simplegit.rb
- 43. > git stash Saved working directory and index state "WIP on master: 049d078 added the index file" HEAD is now at 049d078 added the index file (To restore them type "git stash apply")
- 44. > git status # On branch master nothing to commit, working directory clean
- 45. > git merge issue53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.
- 46. > git merge issue53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. Merge Conflict
- 47. > git merge issue53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result. Merge Conflict
- 48. How to solve it?
- 49. <<<<<<< HEAD:index.html <div id="footer">contact : email.support@github.com</div> ======= <div id="footer"> please contact us at support@github.com </div> >>>>>>> issue53:index.html
- 50. <div id="footer"> please contact us at email.support@github.com </div>
- 51. <div id="footer"> please contact us at email.support@github.com </div>
- 52. Installation Windows http://git-scm.com/download/win Linux $ sudo apt-get install git (Ubuntu) $ yum install git (CentOs) Mac http://git-scm.com/download/mac
- 53. Best Practices Do not work on Master branch Synchronize daily Follow feature-wise branching Avoid force push Do not work on servers e.g FTP
- 54. Tools ● Following are few very necessary tool for working with git > sudo apt-get install gitg > sudo apt-get install git-gui > sudo apt-get install meld
- 55. GitG (gitg)
- 58. Thank You - Waqar Baig Special credits to Rails Team
Editor's Notes
- Now lets see what this visually looks like. On my first commit I have A. The default branch that gets created with git is a branch names Master. This is just a default name. As I mentioned before, most everything in git is done by convention. Master does not mean anything special to git.
- We make a set of commits, moving master and our current pointer (*) along
- Suppose we want to work on a bug. We start by creating a local “story branch” for this work. Notice that the new branch is really just a pointer to the same commit (C) but our current pointer (*) is moved.
- Now we make commits and they move along, with the branch and current pointer following along.
- We can “checkout” to go back to the master branch. This is where I was freaked out the first time I did this. My IDE removed the changes I just made. It can be pretty startling, but don’t worry you didn’t lose anything.
- And then merge from the story branch, bringing those change histories together.
- And since we’re done with the story branch, we can delete it. This all happened locally, without affecting anyone upstream.
- Let’s consider another scenario. Here we created our bug story branch back off of (C). But some changes have happened in master (bug 123 which we just merged) since then. And we made a couple of commits in bug 456.
- Again, to merge, we checkout back to master which moves our (*) pointer.
- And now we merge, connecting the new (H) to both (E) and (G). Note that this merge, especially if there are conflicts, can be unpleasant to perform.
- Rebase flow - Let’s go back in time and look at another approach that git enables. So here we are ready to merge.
- Instead of merging, we “rebase”. What this means is something like this: 1. Take the changes we had made against (C) and undo them, but remember what they were 2. Re-apply them on (E) instead
- Now when we merge them, we get a nice linear flow. Also, the actual changeset ordering in the repository mirrors what actually happened. (F’) and (G’) come after E rather than in parallel to it. Also, there is one fewer snapshots in the repository.