YET ANOTHER INTRODCTION AND AN EXAMPLE HOW NOT TO USE BAD PRESENTATION STYLES

Editor's Notes

• #3: Today we I’m going to talk through several core concepts within Git. How you can take advantage of it within your team. And a few powerful scenarios such as using git to handle deployments.
• #4: Git was originally created by Linus for work on the Linux kernel right around 2005. Although git has its origins in the Open source community, git is being used within close source projects also. This is just some of the many companies that are using git for both oss and closed sourced projects.
• #6: Git is a distributed version control system.
• #7: A directory content management system
• #8: A tree based history storage system
• #9: So what does it really mean to have a distributed version control system? Everyone on your team has a complete history of the code locally.
• #10: Just about everything in Git can be done offline. Not just that the system works well when it is offline. It is design from the beginning to have no real dependencies on a specific server. The only actions you do in git where you need a server is when you push or pull changes from other team members.
• #11: In git there is no central server required. So the authority is really determined by the conventions your team puts in place.
• #12: Given Git’s nature you can even share changes in a peer-to –peer nature. This does not happen often but Git does enable this ability. If your server is offline for some reason your team can still work.
• #13: This is over simplifying the story, but the basics are that centralized version control system define a central authority. I am not saying one system is better that the other, it is just that each model that its benefits. In the distributed model by definition everything is expected to be off line. To have a system that expects everything to be offline, you have to build in several local capabilities that are not required in a centralized model. Such as local branching. And to make branching fast and lightweight you better make merging great also. I won’t go into the guts of git that enables some of this capability in this talk, but if you are interested I will highlight some resources at the end of the talk where you can go deeper.
• #14: Ok lets get into branching.
• #15: For this you need to forget what your experiences with branching in centralized version control systems.
• #16: A Git branch is just a sticky note on the graph.
• #17: All work happens within this one location. When I first started using Git, it really freaked me out when I switched branches for the first time and things just disappeared. It took me awhile to really trust what was happening. So don’t freak out it is ok.
• #18: Switching between branches is just moving the sticky note around.
• #19: After you install git on your machine to get started you will need to initialize a repository. You can do this by going into your file system, creating a folder and doing git init within the folder. All the magic happens in the Dot Git folder. This folder IS GIT. You can copy this folder to another machine and it will work. When I first started playing with git, I had setup a new machine, and was having a hell of a time trying to figure out how I should move my git projects over to the new machine. It was kind of embarrassing. Eventually I just tried to copy it over and it worked. At this point you really don’t have much. You need to do your first commit to make this light up. You create a file. When then stage it, but telling git the track this file. In this case I told git to add all files. Then I was able to commit with a message say this is my first commit.
• #20: 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.
• #21: We make a set of commits, moving master and our current pointer (*) along
• #22: 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.
• #23: Now we make commits and they move along, with the branch and current pointer following along.
• #24: 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.
• #25: And then merge from the story branch, bringing those change histories together.
• #26: And since we’re done with the story branch, we can delete it. This all happened locally, without affecting anyone upstream.
• #27: 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.
• #28: Again, to merge, we checkout back to master which moves our (*) pointer.
• #29: 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.
• #30: Now we delete the branch pointer. But notice the structure we have now. This is very non-linear. That will make it challenging to see the changes independently. And it can get very messy over time.
• #31: Rebase flow - Let’s go back in time and look at another approach that git enables. So here we are ready to merge.
• #32: 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
• #33: 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.
• #38: But of course, most of you work on software with other people.
• #39: Since everyone on the team has a complete copy of the repository you can do things like this. But no one wants to keep track of changes this way.
• #40: This is where you add in a remote server.
• #41: There really is nothing special about the remote server. You can have more than one. But it enables a nice integration location, just like you are used to in the centralized version control
• #42: There are two ways to configure a remote within your local machine.
• #43: If you have an existing repository you can just add a git remote using Git remote add NAME. Origin is not a special name, it is just a common convention that gets used. You can name this anything you want.
• #44: If you don’t have a local copy of the repository you can clone the repository from the remote. Doing this pulls the full repository locally, and sets up the remote connection information.
• #47: Suppose we are here. We cloned master on (A) and have been fixing bug 123 in our story branch.
• #48: I’ll use the orange box to indicate where the master pointer is on the remote server. Here we are as before with our local master branch and the remote master branch both pointing at (A)
• #49: The changes on the Bug123 branch are only known to my local machine the remote server does not have these changes. Or the bug123 branch for that matter.
• #50: But in fact there are two versions of the orange master pointer. One is what we last know about the upstream master and the other is what is actually up there (which we don’t know about).
• #51: So if this is what we know, we can update our master to catch up. First we checkout master which moves our current (*) to there. Note that we are actually on our master, not the upstream one. That is always true. But the tracking branch is also pointing to (A) at this point.
• #52: Now we can do a pull on the origin (our source remote) and move both along to their new place.
• #53: I have not talked about Pull before. The pull command is combination of a fetch from the remote server and a merge of the changes. You can do these steps separately, but if you are not working on the branch you are pulling down, pull is just a nice way to get up to date.
• #54: Now we can do a pull on the origin (our source remote) and move both along to their new place.
• #55: Returning to our bug fix now by checkout on that, we have a similar problem to what we saw before. B-C-D-E all come before F and G. Merging would create issues, right?
• #56: So we use rebase to rewind and replay B-C-D-E after G.
• #57: Then we checkout back to master
• #58: And merge. Note that the orange (upstream) pointer is still “back there”.
• #59: And finally, because we want to publish these changes, we push to the origin, moving the orange pointer along.
• #60: Push will update the remote server. If you are out of date, Git will reject that push. Git will require you to merge locally, then push the results.
• #61: And finally, because we want to publish these changes, we push to the origin, moving the orange pointer along.
• #62: Delete the story branch and we’re good to go
• #63: Suggestion, update your local repository at least once a day. Makes it easier to see what is going on upstream.
• #67: The process of Creating a local branch, commit your changes, merge it into the shared branch and then deleting the branch…
• #68: Define branches for the next version of the product.
• #73: Say we want to start working on the next version of our Cool Project
• #74: Say we want to start working on the next version of our Cool Project. We will want to create a develop branch
• #75: To share this with the team we need to push it up to the remote
• #76: To share this with the team we need to push it up to the remote
• #77: Lets say there are some changes on develop from other team members. Until we do a pull we won’t see these changes locally
• #78: Pull some changes from other team members… you should be doing this at least once a day.
• #79: Now we have an idea. We create a working branch off of development
• #80: Now we have an idea. We create a working branch off of development
• #81: One of your teammates did a hotfix in production
• #82: Since we are keeping up to date. Just doing a pull or fetch now and then is a good idea.
• #83: Merge Idea into Develop. First we want to checkout develop
• #84: Since there was not any additional changes on develop we could easily merge idea into develop. – This is call a fast forward merge since git is really just moving the pointer to H
• #85: We can delete idea now
• #86: We now need to share develop with the rest of the team.
• #87: When we are ready to move the develop branch to production (master) we have two choices. We can go through the merge flow, or a rebase flow.
• #88: Move onto master
• #89: Move onto master
• #90: Move onto master
• #91: Rebase flow - Move onto master
• #92: Rebase flow - Move onto master
• #93: Rebase flow – Get Origin up to date
• #94: As with most things with Git, there are multiple ways to do something. Using a Merge flow verse a Rebase flow is a matter of taste, but as you can see the rebase flow looks cleaner and as you get into large projects the number of branches can get pretty messy. This is a simple example of rewriting history in git.
• #95: Git is really powerful, but when you start working with a team it is best to come up with a few conventions that you can agree upon. Are you going to treat master as a production branch. No work happen in master, everything happens in a combination of shared feature branches and personal local branches.
• #96: As we have seen git is pretty powerful to enable sharing of code between team members. But git can also be used to deploy to several services.
• #97: You can almost think of git as a protocol.
• #98: You can almost think of git as a protocol.
• #99: You can setup multiple remotes, each pointing at a specific environment.
• #100: Adding Post Commit hooks can automate deployments on changes.
• #101: Adding Post Commit hooks can automate deployments on changes.
• #102: Adding Post Commit hooks can automate deployments on changes.
• #103: Adding Post Commit hooks can automate deployments on changes.
• #104: Adding Post Commit hooks can automate deployments on changes.
• #105: Adding Post Commit hooks can automate deployments on changes.