GIT Tutorial

Disclaimer: I do not have much experience working with GIT in larger groups so bear with me!

What is GIT?
  • GIT is a version control software.
  • It keeps track and logs changes made to files.
  • keeps a backup of each logged change so that if you break something, you can always go back to an older version
  • It also allows groups of people to work together on the same project (relatively) easily by storing the project files on a remote repository (server) and each user has a local copy (repository) of their own which they work on and send and receive changes to and from the remote repository

1. Master Repository: place where you upload your Committed files.
2. Local Repository: place on your computer where you save and work on files
3. State/Revision: basically a save file of your repository (they never overwrite)
4. Commit: store your files to a state/revision on your local repository . These commits serve as nodes.
5. Nodes: "save files" of commits to the repository. Nodes automatically Branch off of the Master Repository
6. Branch: both a verb and a noun, referring how GIT branches off nodes when users commit their files.
7. Head: most recent node on a branch
8. Merge: Combines 2 branch heads together into 1 branch (usually with the Master Branch)
9. Push: Uploads or sends all of your commits to the Master Repository
10. Fetch: Downloads all of the commits from the Master Repository to your Local Repository (DOES NOT MERGE)
11. Pull: Downloads all of the commits from the Master Repository to your Local Repository AND MERGES your most recent commit

Getting started with GIT

Okay, lets get started with GitHub

  • log into GitHub
  • Create a new repository
  • call it test
  • clone it in source tree
    • copy the clone URL in the bottom right corner of your repository page on GitHub then click clone in the top left corner of SourceTree

now Sourcetree…

Basics of SourceTree

  • File Status - you can view files to be added and ones that are not added to the commit
    • add one and add all check mark boxes
  • Log/history - view a list of the commits and changes from others
  • branches - displays your local branches
  • remote - displays the remote branches

Basic Workflow

  • add - adds things to the stage - the files to be commited
  • commit - adds things to your local repository.
  • push - pushes to the remote repository
  • pull - downloads commits from master and merges them to your most recent commit
  • fetch - same as pull without the merge. Kept in its own branch

GIT has three main states for files

  • commit - data is safely stored in your repo.
  • modified - you have changed the file but the file has not been commited to the repo or staged yet
    • the file will appear as unstaged in sourcetree
  • staged - the file is marked to be included in your next commit

note that there are some differences in GIT between other version control systems

  • ex: subversion, you only have to "add" your files once to let svn know they are under version control.
    • there are ways to make GIT behave this way as well
  • Git stores its files differently. Rather than noting the differences in files, GIT takes a "snapshot" of the files.
    • see resources section for more info on this
Basic Workflow Example
  • trev makes a file in his workspace
  • notice that the file appears with a blue ? mark symbol in the uncommited changes panel
  • trev adds it to his staged files area
  • trev commits these staged files to his local repository
  • trev pushes them to the remote branch
  • jill then comes and pulls from the remote branch
  • jill now has all the stuff that trev pushed to the remote branch
  • jill changes the file
  • jill adds the changes to her workspace
  • jill commits her changes and pushes the file to the remote repo
  • trev fetches the changes
  • trev checks out the fetched branch
  • trev decides he is cool with the changes
  • trev merges the fetched branch
Conflict example

Ideally, it would be nice if we could take turns pushing and pulling from the master, but things don't always work out that nice. Sometimes there are conflicts.

  • jill makes change, adds, commits, pushes
  • trev makes change at relatively the same time, adds, commits, pushes
  • trev gets message that he does not have some of the changes pushed to the remote branch
  • trev pulls
  • trev gets a conflict error
  • trev must resolve the conflict error
  • trev opens his file, manually changes conflict
  • trev adds, commits, pushes the change
  • looking at the log/history window, we can see that there were two branches that differed then merged together

Branches are useful for creating new features in projects that you want to keep separate from the main project. You can make a new branch, add files or changes to a file, commit, push and the new branch will not interfere with the existing branch

Creating Branches

  • select the node that you want to create the branch from in the log/history window
  • right click, create new branch, name it "feature" or whatever relevant name you want
  • make whatever changes you like, add and commit just in that branch if you want to, then when you're ready, merge.
  • merge will probably result in some conflicts
  • make sure your current selected branch is the one you want to merge into. click merge, choose a commit to merge into it (from the other branch)
  • to get rid of conflicts, manually open the file as before and change it until you're satisfied.
  • once you've merged the branch, if you don't plan on using it again, you can delete it.
  • note that this branch will remain local unless when you push, you select to push to its remote branch. If you do so, then a remote branch will be created and the branch will be pushed onto there.
Working as a group
  • Let's try working as a group now
  • must add people as contributors on GitHub to work on the same repository
  • add a file titled with your name
  • commit
  • push
  • cool now we each have our own file
  • now let's try working with unity
  • here's how to setup GIT to work with unity
  • basically, the only folders we need in our repository are assets and project settings
  • note: if you're reading this tutorial online, email me and I will add you as a contributor to the repo
Important Notes
  • once you understand the GIT workflow, you can easily transition over to the command line if you'd rather
  • before you start working, always pull
    • to get the group's latest changes and to prevent conflicts
  • in sourcetree, the log/history window shows a graph
    • in the graph, one node will have a white center. This is the node that is currently "checked out".
    • if branches diverge, they will be displayed in a seperate column as a seperate colour
  • if you try to pull and you have uncommitted local changes that would get overwritten by other people's commits, git will warn you that your changes will be overwritten and ask if you want to proceed
More Resources

General GIT/SourceTree Tutorial
How GIT works
Creating a new Branch
Merging GIT Branches and Resolving Conflicts
A (perhaps better) Explanation of Merge Conflicts
GIT command line CheatSheet
Opinion: Use Fetch and Merge Over Pull
And don't forget about Lynda!
SFU Lynda Register Link

GDC Group Project Discussion

Planning page

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License