Download to read offline
Uploaded byJohn Tighe
Git 101 - An introduction to Version Control using Git
This document provides an introduction to version control using Git. It explains that Git allows for non-linear development through branching, which allows developers to work independently on different parts of a project. The document walks through setting up a local Git repository and making commits on different branches. It demonstrates how to merge branches together and delete branches that are no longer needed.
More Related Content
Similar to Git 101 - An introduction to Version Control using Git
Git 101 - An introduction to Version Control using Git
- 1. WP COS Meetup Git101- An Introduction to Version Control using Git 11/24/15
- 2. If you arenew to Version Control you are probably thinking it is something like WordPress post revisions or a daily back-up in that you save a copy of your project sequentially over time. (It’s very linear) And you would be partly right… What is Version Control? A B C D
- 3. The purpose ofsomething like revisions and backups is to restore your project to an earlier instance What is Version Control? A B C D Restore Each snapshot is an instance of a point in time. It is very linear. This is not the case with a Version Control System such as Git. ( Although you can use it that way.)
- 4. The purpose ofa Version Control System like Git is to assist you in the development of your project, not simply restoring it if issues occur. When Git stores a snapshop of your project (called commits) it also stores which previous instance you made changes to. Branching A B D G C E F H I This results in a non linear instance structure.
- 5. It looks complicated,but it results in an extremely powerful concept called Branching Branching is the heart and soul of what makes something like Git so powerful. Branching
- 6. Feature Branch Master Branch Branchingallows you (and others) to work on parts of your project independent of the other parts. Then, when you are ready, you can “merge” your part back into the main project. Branching A B C D E F- - - - - - - - - - - - - - - You can have as many other branches as you want, but you will always have a master branch
- 7. Basic Git Workflow Fromthe command line: Staging Area The staging area stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area. Working Directory (your Project Directory) The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. Basic Git Workflow: 1. Modify (add) files in working directory 2. Stage your modified files 3. Commit the staged files to the repo Git Repo Where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. Resides in the .git directory of your project root.
- 8. The easiest wayto install it is to use the Github Desktop app. https://desktop.github.com/ This will install the app and also provide a command line interface as well. (I’ll be using the windows version, but Mac version is fine) Git Basics
- 9. Create a localrepo Git stores everything in repositories. So we need to create one, in your Project directory create the repo: Note: 1. I’ll be using the command line, but everything I do can be done from the GUI. 2. The .git directory is hidden normally by Windows. Your project directory is called the working directory in Git From the command line: > git init
- 10. > git status Gitstatus tells you the status of the files in the working directory including what branch you are working on. We have no files so lets create a couple.
- 11. > git status Filesare either tracked or untracked. Untracked files - any files in your working directory that were not in your last snapshot and are not in your staging area. Tracked files are files git has or will save in the snapshot called a commit.
- 12. > git add<filename> Before we can take a snapshot of our project, we have to tell git what files to track. We do this with the add command: We could also use wildcards: > git add <filename> > git add *
- 13. > git commit Tocommit all the files in the your staging area to your local repo and take a snapshot of the current instance of your project, you commit. The message is important because it helps you recall what you did. Make the message mean something. > git commit –m “message”
- 14. > git commit Whenyou have added all the files in your staging area to the repo and there are no untracked files, your working directory is clean. There is nothing for git to do.
- 15. The Three Stagesof Files Important!! Git has 3 main states that your tracked files can reside in: Modified means that you have changed the file but have not committed it to your staging area yet. Staged means that you have marked a modified file in its current version to go into your next commit snapshot. Committed means that the data is safely stored in your local db (repo).
- 16. Basic Git Workflow Fromthe command line: Staging Area The staging area stores information about what will go into your next commit. It’s sometimes referred to as the “index”, but it’s also common to refer to it as the staging area. Working Directory (your Project Directory) The working directory is a single checkout of one version of the project. These files are pulled out of the compressed database in the Git directory and placed on disk for you to use or modify. Basic Git Workflow: 1. Modify (add) files in working directory 2. Stage your modified files 3. Commit the staged files to the repo Git Repo Where Git stores the metadata and object database for your project. This is the most important part of Git, and it is what is copied when you clone a repository from another computer. Resides in the .git directory of your project root.
- 17. Lets do somework Let’s modify our readme.txt file. To keep it simple lets just add a second line. Be sure to do a git add and commit.
- 18. Some more changes Let’schange the second line. Save, add, and commit it.
- 19. > Git log Wehave made a few commits at this point how do we see them? As you can see the commit messages start to play an important role. But what about those numbers before the commit messages. > git log –oneline Use the –oneline flag These are the ID’s git uses to keep track of the commits. (They’re actually each a hash, but that is another discussion)
- 20. Some more changes Let’sadd a third line line. Save, add, and commit it. Opps, that wasn’t right, now what?
- 21. Opps, now what? Wemade a mistake, what do we do? If it is simple like this, correct the file and save a new commit. But what if we had tried a whole new feature, with like 30 changed files, and we need to go back? We can reset git to the commit we want to revert to. > git reset --hard b2d50c6 B2d50c6 is the ID git uses to track commits.
- 22. There’s a betterway Remember we talked about branches? Up until now we have been making all our changes in our master branch. That really doesn’t leverage the true power of git; Branches. So let’s try again, this time using branches.
- 23. Branches Remember, branching allowsyou to work on parts of your project independent of the other parts. To create a branch: To switch to a branch: All at once: > git checkout <branch_name> > git branch <branch_name> > git checkout -b <branch_name>
- 24. More changes Lets addanother file, say details.txt Save, add and commit it.
- 25. Even More changes Letsmake a few more changes and commits. And lets use a better log > git log –oneline --decorate Now we know what branch the commit was on. HEAD is just a pointer to the current commit on the current branch.
- 26. Oh no, bugs Nowwhile we are working on details.txt we are told of a bug in readme.txt Lets fix that. But it isn’t part of what we are doing in this branch so lets create a new branch in which to fix it. But we are currently in myfirstbranch so we need to switch to master first, then create it.
- 27. Fix the bugs Wemade the necessary fixes and committed them.
- 28. Status We did abunch of things lets see what we have commits on three branches. We are on branch bugfixes. What happened to myfirstbranch?
- 29. Myfirstbranch It is stillthere, but we have to switch to it.
- 30. bugfixes Visually Visually it lookslike this. myfirstbranch Master Branch A B C D E F G H I
- 31. > Git merge<branch> Now we want to merge these bug fixes back into the master branch so we can give it to our client. Will merge <branch_name> into the current branch. So let’s switch to master and merge bugfixes. > git merge <branch_name>
- 32. Visually Now master andbugfixes are still independent of each other but look identical. bugfixes myfirstbranch Master Branch D E F G H I H I H & I are not new commits
- 33. Another change Let’s switchback to myfirstbranch and make a change to the readme.txt file.
- 34. > Git mergemyfirstbranch Now we want to merge myfirstbranch into the master branch. > git merge myfirstbranch
- 35. Visually Master contains allthe changes, merged. bugfixes myfirstbranch Master Branch D E F G H I H I E F G------------------------------------------------ -------------------------------------------
- 36. Deleting unnecessary branches Supposenow we try to re-factor myfirstbranch and it just isn’t working. We may have made a dozen commits to it but just no joy. What do we do? Simple we just delete the branch. Create a new one and try again. This preserves our master branch > git branch -D <branch>
- 37. Discussion & Bestpractices Those are the basics for using git. There is so much more. Public and Private on-line repositories Working in teams Git diff Advanced workflows Can anyone say Git201?