Version Control All The Codes

Learn the basic concepts of of version control using git and Github.

Thanks to Tower (a Git GUI) I also handed out cheat sheets. Get a copy here:
http://www.git-tower.com/files/cheatsheet/Git_Cheat_Sheet_grey.pdf

Note: The message around what git-blame is and why it's awesome does not appear in this static version since it was improvised. Short version: Git-blame provides an annotated, line-by-line commit history for the file. For best results, click the "Blame" button when looking at any file on Github to unleash the awesomeness that is git-blame.

Transcript

1. VERSION CONTROL ALL THE CODES
2. @theophani TIFFANY CONROY My name is Tiffany, and I work as an interaction designer and front-end developer at SoundCloud here in Berlin.
4. USE VERSION CONTROL I'm going to convince you to use a formal version control system for everything you do. Proper version control is too easy and too valuable not to be using for everything. If you aren’t already using any version control and aren’t sure what you use,
5. USE GIT use git. I’m not going to spend anytime trying to convince you. If you want to hear why, come talk afterwards.
6. USE GITHUB http://github.com also, use Github. I’ll explain why to use Github later on.
7. My assumptions about you: There are three groups of people here
8. Use version control regularly 1. Those who use version control regularly.
9. Have used version control ever 2. Have used version control ever.
10. Have used some sort of versioning 3. Have used some sort of versioning. Hands up if you think I forgot to include anyone in this chart. You may think I forgot this group:
11. Have used some sort of versioning Have never used any sort versioning people who have never used version control. But I don't think that anyone here has never used version control.
12. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control.
13. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control. As we make revisions, we create a linear history of our changes.
14. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control. As we make revisions, we create a linear history of our changes.
15. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control. As we make revisions, we create a linear history of our changes.
16. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control. As we make revisions, we create a linear history of our changes.
17. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control. As we make revisions, we create a linear history of our changes.
18. If you have ever done this: [used ⌘Z or CTRL-Z], then you have used version control. As we make revisions, we create a linear history of our changes.
19. When we use UNDO, we back out of the changes we’ve made to get to another earlier state we preferred.
20. When we use UNDO, we back out of the changes we’ve made to get to another earlier state we preferred.
21. From that point in our past, we can move forward into a new, alternate future. But when we create the new future, we completely lose the edits we undid.
22. From that point in our past, we can move forward into a new, alternate future. But when we create the new future, we completely lose the edits we undid.
23. What if that forever-lost version turns out to have been better than the new thing you created? With very few exceptions, when using the UNDO function, we do not have access to the edit TREE. When we back out of a change this way, using UNDO, it's forever. But what makes the direct past more valuable than an alternate future? Nothing. But with UNDO, we are forced to choose before we know. So, this is a solved problem. We've all done this at some point:
24. So, this is a solved problem. We've all done this at some point, which is just another form of version control. This happens when we reach a stage in our work where we want to make fundamental changes, like deleting huge sections, or re-writing sections, but we are afraid of losing our existing work. We want to make bold changes without risk.
25. Version control gives you freedom to try new ideas because it liberates you from the fear of losing your work This is true if you are writing an essay, or poetry, or code or making art. EVERYTHING you do can benefit from using version control, not just code. You already rely on being able to go back in time to an earlier state. With version control, and it's far less work to get full control over what gets saved.
26. TERMINOLOGY Having more than one competing version of the same thing is called having *branches*. Creating a new branch is called *branching*.
27. A saved earlier version you feel you has enough value to keep is called a *tag*. A tag is a safe place you can go back to.
28. A *commit* is a unit of change in your code. It's also a safe place you can go back to, but it doesn't have the same significance as a tag.
29. All the history of your changes is called a "repository" or simply "repo" for short.
30. WHEN SHOULD I USE VERSION CONTROL? The thing that might be holding you back from using version control is wondering when to use it. The problem with version control is that by the time you realize you want to take advantage of it, it's too late. Version control is like insurance: you have it all along for that moment of crisis when you need it. I'm going to show you situations that you have all experienced, and tell you how to use version control in each of them.
31. ## This looks great! I should save a copy It may not occur to you to use version control until after you've started working on a project, and at some point think “This is great so far! I'd love to save a copy of this thing just like this because it's [working, beautiful, one complete part done]”.
32. ## This looks great! I should save a copy And when that happens, you should create a repository, and save your first version into the newly created repository. ## Okay, now I have a new thing I want to save.
33. ## Okay, now I have a new thing I want to save. If the new thing you want to save is definitely better than the previous thing you saved, then just save the new version with a description of the change. This is the best approach when you want to *replace* the previous version. Don't worry: you always *can* go back to the older version, but it might not always be easy. ## Oh, I'm not actually 100% sure this new thing is an improvement.
34. ## Oh, I'm not actually 100% sure this new thing is an improvement. No problem! If you ever want to save a version that is sort of an experiment that you aren't totally committed to yet, create a BRANCH and then commit to that instead. Keep working in that manner, branching every time you aren't sure.
35. ## I branched a while ago, but now I'm sure this is better. If you are working alone and in a linear order, then no problem. All the edits up to the point are all there. By convention, the "main" branch in git is the so-named "master" branch. If you prefer, you can merge your best branch back into master.
36. ## I branched a while ago, but now I'm sure this is better. [If you prefer, you can merge your best branch back into master.]
37. Let’s imagine this instead. You are working along, any think: ## Shit, the changes I made suck. I want to go back in time to an earlier version. This is when version control shines. THIS is why you are using version control.
38. TO DELETE EDITS: git reset --hard If you completely don't want ANY of the changes that you made since the last commit, use "git reset --hard".
39. Anything that is not committed when you do a hard reset will be gone. Usually, this is not what we really want to do. Usually we want to keep the version we created and try again with an older version.
40. If you want to go back to an older version but KEEP all your edits, just in case,
41. then commit any changes,
42. checkout the older commit, branch from that point, and work forward again on the branch.
43. branch from that point,
44. and work forward again on the branch.
45. TO TRY AGAIN: Create a branch from an older commit, and work from there. In summary, TO TRY AGAIN: Create a branch from an older commit, and work from there.
46. ## Which commit do I want to go back to? In order to be able to “go back” to an earlier commit, you need to be able to tell the commits apart from each other. Luckily, they have identifiers:
47. b1df5f0f767dfab8824fc3010606e36e0f399c54 d6aa65f4c8a6431f1e21500e3d499cc48c357e29 958323054dacdd16d92fc4eb93209616f290d5a8 e570d75648f4b4a68520afdb45852d92532a03b5 ada992d17022c71e34cd510992ecb651dc880be8 Okay, so those aren’t that useful.
48. b1df5f0 HEAD@{0}: commit: how to connect to the channel 643f106 HEAD@{1}: commit: added timezone support 26cf918 HEAD@{2}: commit: links to more advice dd71a0e HEAD@{3}: commit: typo!! 641ac84 HEAD@{4}: commit: minor header style changes These descriptions are MUCH more useful. With a version control system, when you save a revision by making a so-called commit. With each commit you must describe the change in words and save that description along with the change itself. The description of the change is called the "commit message". A commit is the *change* between revisions plus the *description* of that change. Additionally, it includes the author of the change (you, in our discussion), when it was made. Each commit knows what its parent commit is. And the parent knows its parent. And so on. And so the collection of commits is a history of the project up to that point in time. Then you can read through the commit messages and know the history of the repository. In this way, you should not have to look at the changes directly in order to understand what was done, or why, or by whom.
49. TO SEE DIFFERENCES: git diff [version1] [version2] Though you may need to look at the difference between two versions to know what is interesting. For that, we need the concept of a diff, short for difference, which is just that: a way of showing you the difference between two versions.
50. [EXAMPLE DIFF]
51. ## I have some great ideas in two different branches that I want to combine. You can always merge one branch into another branch.
52. new-styles new-text Example: say you have two branches, "new-styles" and "new-text". You want to combine these two versions. We call that “merging branches”. You always merge a branch INTO another branch.
53. new-styles new-text So if you want to combine new-text and new styles, you can merge "new-styles" into "new- text"
54. new-styles new-text You can also do the reverse: you can merge "new-text" into "new-styles".
55. new-styles new-text Afterwards, you will have a "new-text" branch that is unchanged …
56. new-styles new-text … and a "new-styles" branch which is actually the original "new-styles" plus all the changes from "new-text". You can see how this might be confusing, for a couple reasons. First is the way the diagram looks. It’s not a straight line, but the combination of two branches.
57. new-styles new-text which is why it is usually drawn more this. This version shows the commits from new-text branch (on the left) being applied “afterwards” (above) the ones in “new-styles”, but in parallel. The other reason it is confusing is because there is a branch called “new-styles” which is really a combination branch.
58. new-styles new-text new-styles-and-text To avoid this sort of confusion, you could have first created a third branch called “new-styles- and-text” from “new-styles”
59. new-styles new-styles-and-text new-text and then merged “new-text” into it. So this is perhaps even MORE confusing to look at.
60. new-styles new-text Let’s go back to just two branches again. You can also, if you decide both branches are great, merge BOTH into master.
61. new-styles new-text master [that’s where master currently ends] so when we merge both branches into master,
62. new-styles new-text master the tree, the history, is a lot easier to understand …
63. new-styles new-text master … and is usually shown more like this.
64. ## I want to access this repository from another machine You are working all nicey-nice on your work machine, and you realize you want to be able to keep working from your machine at home.
65. How can you get your repository from one machine to the other? If you want two copies of the same repository on two machines, technically, you could share directly between them. Assuming you have a copy on two machines A and B:
66. B A
67. B A push to B B is remote from A From the perspective of A, B is "remote" and you "push" to it.
68. B A A is remote from B pull from A From the perspective of B, A is "remote" and you "pull" from it.
69. B A C In practice, everyone puts a third copy somewhere and then keeps both machine A and machine B in sync with the other copy. That third copy is kept somewhere that is easy to access using any internet connection.
70. B A C From machine A, you push to C, and then on machine B you pull from C.
71. B A C Later, if you make changes on machine B, you pushes changes back to C, and pull onto A.
72. B A C “origin” By convention, that third remote location is usually given the name "origin" regardless of which machine had the original version of the repository on it. This convention can be confusing for beginners, so you should be aware of it. So, the best way to share between two copies is to actually have a third copy somewhere on the publicly accessible internet.
73. B A Github Enter Github. Github is a lot of things, but at its core, Github is a place on the internet where you can store copies of your git repository so that you (or anyone else you allow) can keep in sync with.
74. Github is free and has a free GUI application for Mac that you can use to manage all your git repositories on Github. With a free Github account, all your repositories are public, which means that anyone can see them and so of course can get a copy. If you want to have private repositories, then you need a paid account.
75. github.com github.com If all you remember is this URL, then I’ve done my job.
76. B A So now that we have introduced the idea of sharing a repository across two (or more!) machines, we can also address another situation: ## My friend is going to help me on my project, and we to work in the same repository.
77. your friend you If you friend also has a Github account, this is dead easy: Give your friend edit access on the repository (you can do this from the admin area of the repository on Github). Your friend then "clones" the repository, and after making changes "pushes" back to Github. If you make changes, you also push to Github. Anytime you want to get back in sync, you pull instead of push. Sometimes, you must pull before you push, because your version is an older version that the version on Github.
78. back-end front-end ## I did some work in a branch called "front-end" and my friend did work in a branch called "back-end". We want all the changes to be in the master branch.
79. back-end front-end master Just merge both into the master branch! Done!
80. YOUR EDITS YOUR FRIEND’S EDITS ## Blarg. We both made changes on the same file. [describe the picture]
81. YOUR EDITS YOUR FRIEND’S EDITS RESULT + = git is really good at understanding that both of sets of changes on a single file are wanted, especially if the changes are on different lines. Try merging both, since it may work right away. IF those changes are on the same line in the file, or for some other reason git is confused, git will combine all the changes, and warn you that there was a conflict.
82. Content that was merged without a problem before the conflict. <<<<<<< HEAD [The edits from the branch you merged into are in this space] ======= [The edits from the branch you merged in are in this space] >>>>>>> incoming-branch Content that was merged without a problem after the conflict. Then you can open the files and manually delete the unwanted changes. This is how that looks.
83. Content that was merged without a problem before the conflict. <<<<<<< HEAD [The edits from the branch you merged into are in this space] ======= [The edits from the branch you merged in are in this space] >>>>>>> incoming-branch Content that was merged without a problem after the conflict. What are seeing is the combined edits, plus some helper text that git has added so you can easily find the conflict and correct it. The helper text is the two rows of arrows and the double line separating the two sections.
84. Content that was merged without a problem before the conflict. The edits from the branch you merged into and from the one you merged in are now both in this space. And we delete the helper text extra things git added Content that was merged without a problem after the conflict. So you make updates, and remove the helper text. Then we commit this change and complete the merge.
85. Now we know enough to ask the most important question that we can ask ourselves that version control can answer:
86. WTF? What the fuck is going on with this code?
87. diff commit history We’ve seen two ways so far to understand what is going on.
88. diff commit history git-blame git-blame is AWESOME
89. git-blame This concept is your best friend.
90. [example git-blame]
91. Git Workshop (2H) 10am, Saturday August 25th Pythagoras Stage campusparty.opentechschool.org Learn more
92. THANKS! TIFFANY CONROY @theophani Follow me for slides and links https://speakerdeck.com/u/theophani