Become a Git Superhero

Learn the secrets of Git and became a superhero!

Transcript

1. BECOME A Superhero
2. Jacek Spławski Front-end Web Developer
3. It’s so true…
4. • Free and open source distributed version control system. • Distributed Version Control Systems (DVCSs) which means that repository is fully mirrored and every copy is a full backup of all data. • Different workflows. Few words about Git
5. Once you start using it, you'll realise how shitty life was before it. — Some guy
6. HEAD / master / origin
7. HEAD HEAD is pointing to the current commit your repo is on - most of the time it is the latest one. In case when HEAD is pointing to the commit that is not the tip of any branch, we can talk about detached head. $ cat .git/HEAD
8. master Master means the main branch and it’s created by default when initialised repo. In many cases, master refers to the production branch.
9. origin Origin means the main remote repository.
10. master and origin are not obligatory elements of repository. In fact, they may have different names, meaning or don’t exist at all.
11. git init / git clone / git checkout
12. git init Gives you a possibility to create an empty repository or track changes in an existing project. Actually, it adds .git folder with all necessary metadata. Remote repositories should be created with the --bare parameter. Bare repository is a repo without working directory. In other words, you cannot edit and commit changes in that repository. $ git init <directory>
13. git clone Copies remote repository via HTTP or SSH on to the local machine and automatically creates a remote connection between local and central repository. $ git clone <repository>
14. git checkout Since version 1.6.6 you can use it in this form. If branch doesn’t exist, it will create a local branch and set its remote-tracking on origin/branch. In case if branch exist, it will switch to this branch. Checking commit or file updates the working tree. $ git checkout <branch, commit or file>
15. git status & git log
16. git status This command lets you see the state of the working directory. It will show you information about files that are staged, unstaged and untracked. It doesn’t provide you any information about committed project history. $ git status
17. git log This command allows you to list the project history. You can also filter project history, search for specific aspect and customise output using rich pallet of parameters. $ git log
18. git fetch vs. git pull
19. git fetch Use it each time when you want to update your remote-tracking branches. It gives you a fresh view on the remote repository status. It never changes your working directory. Many programs (e.g. SourceTree and Tower Git) fetches changes regularly and automatically in the background. $ git fetch <remote or branch>
20. git pull Downloads newest data from the remote server and incorporates them into your current working directory. In fact, it performs git fetch and git merge. There is an option to use rebase operation instead of merge. To do this, use --rebase flag. It’s recommended to use it on clean working directory before to avoid merge conflicts. $ git pull <branch>
21. git add / git commit / git push
22. git add Use this command to add file or whole directory to the staging area. Staging area is a list of files that you want to change in the next commit. This command has also an interactive mode which can be used with -p parameter. It doesn’t change repository until git commit. $ git add <file or directory>
23. git commit Think about this as a save option for your staged snapshot. Committed changes are saved in your local repository and they are invisible for other users until you push it to the remote repository. --amend parameter allows you to fix the latest commit. In fact, instead of creating new commit, it combine staged changes with the previous commit. $ git commit -m „<message>”
24. git push This command lets you send changes from your local repository to a remote repo. $ git push <remote> <branch>
25. git merge vs. git rebase
26. git merge In simply words, this is all about joining two branches together. Result of each merge is a new merge commit. Merge doesn’t change existing branches, so we are talking about non-destructive operation. On the other hand, if our development process is very active, we can have a lot of merge commits - impurity of pollution. $ git checkout <branch> $ git merge master
27. git rebase It’s another way to integrate changes between different branches. Rebase takes entire branch and moves it on the top of another branch. Rebase re-writes the project history so it must be use with great caution. The biggest advantages is that project history has linear characteristic. The major disadvantages is that you lose traceability. $ git checkout <branch> $ git rebase master
28. Rebase should be used only on local branches!
29. git revert / git reset / git clean
30. git revert Create a new commit which is a result of undoes a committed snapshot and apply it to the current branch. It doesn’t mess with revision history - it’s important for history integrity. It’s a recommended way of reverting unwanted changes. $ git revert <commit>
31. git reset Use it when you want to undo your changes and go back to the specific commit. Remember that all your changes will be loose and cannot be retrieve. You should never use it on commits that were pushed to the server. $ git reset
32. git clean Use it when you want to delete untracked files from your working tree. Be careful - this operation cannot be retrieve. If you want to check which files will be removed, use -n parameter. This will show you a list of files without removing it. $ git clean
33. But who, in these modern times, slept well? — Dexter Palmer, Version Control
34. git-yolo $ alias git-yolo=‚git commit -am ”`curl -s http://whatthecommit.com/index.txt`”’
35. Resources https://git-scm.com/docs/ https://www.atlassian.com/git/tutorials http://nvie.com/posts/a-successful-git-branching- model/ https://unsplash.com/
36. Questions?