August 4th, 2020
Git is a version control system (VCS), also known as a source code management (SCM) system. A VCS allows you to track changes to your code over time in such a way that previous versions are always available in case you have a need to go back. In larger projects VCS is very important in coordinating the work of multiple developers.
What experience, if any, have you had with a version control system?
Git has properties that make it quite amenable to this use:
git runs locally, no need for network access to use it on your own projects,
git works on a per project basis, no elaborate configuration and simple per project initialization.
git is completely free.
After each significant change to a file save a copy of it with a “special” name, i.e., suffix or prefix.
Issues with this approach:
Websites/Apps and programming projects can be composed of many files and sub-directories
Projects extend over many weeks via assignments that are due weekly
Learning Management Systems (e.g. Blackboard) are not oriented towards multi-file assignment submissions and may not permit file types that are important to this class such as .css, .js, .html!
Need a relatively easy, time-stamped, and private way for you share your work with instructor(s).
CS Oriented Audience Response System
Lots of small project directories for class examples
.gitdirectory within the project directory
Git allows you to take and keep permanent “snapshots” of you project at any point in time via an action called a commit. This is represented in the figure below from Git-Basics.
All these snapshots are saved in a very efficient form in the git repository. The git repository is simply a directory
.git that Git will maintain within you project directory. Do not delete this directory!
As the pro-git book (free) states:
You can always ask git about the status of your project, i.e., files in your working directory. Files can be in the following states:
Remote repositories are versions of your project that are hosted on the Internet or network somewhere. You can have several of them, each of which generally is either read-only or read/write for you. Collaborating with others involves managing these remote repositories and pushing and pulling data to and from them when you need to share work
Contain roughly the same information, remote can be shared
The concepts so far allow for a single “line” of development, however the power of git comes from its ability to branch off a new line of development from any commit point.
This is what allows you to go back to a previous “snapshot” in time of your project and start working from that point (you set up a new branch).
Branches in Git are inexpensive computationally and storage wise (this is not true of all VCSs), so we will use a new one for each assignment.
For personal projects
I set up a new branch either because I’ve messed up and need to start work from an old commit point, or I’m about to venture into the unknown, i.e., use a new library or framework, work on a new piece of functionality that I’m uncertain about.
You can always add, delete, or rename branches. Note that combining branches requires merging which we won’t cover here. See Basic Branching and Merging.
Branch names will be given to you and the exact name must be used so the grading tools I’ve written can find your work, wrong name ==> no grade.
All commits are get a secure hash and time stamp. We know when work was committed and will not grade late work (assignments, projects, exams)
You may commit and push as often as you like.
Git Visualizer. “Explore how Git commands affect the structure of a repository within your web browser with a free explore mode, and some constructed scenarios.”
Git works best with text files rather than binary files, though it can handle both.
I take “snapshot”, i.e., commit my work rather frequently, especially after I’ve gotten something to work! Hence multiple times a day would not be unusual.
When solving homework assignments I typically commit when I finish each problem or sub-problem.
When working for a company or on open source projects you typically start by cloning a remote repository. This is the approach we will use for our class repositories as explained in the Git for Class slides.
For a personal project that you may not share you can just use
git init in your project directory as explained in my Personal Git Tutorial.
||Put a project directory under version control|
||Lists the state of files in the working directory. The -s option produces a shorter output.|
||Adds files to the staging area. Common file wild cards are supported.|
||Commits staged files.|
||Stages and commits all modified tracked files.|
||Use the -m option with a double quoted string to set a commit message on the command line.|
||Used to rename a file in git and in your directory.|
||Puts the file fileName back to its condition after the last commit.|
||Puts all the tracked project files back to their state at the last commit.|
||Used to view the commit (snapshot) history.|
||Sets your tracked files to their state at a particular commit. Good for looking but don’t work on these files, set up a new branch for that.|
||List the names of all the available branches.|
||Lists all available branches and some info on their last commits.|
||Creates a new branch called branchName at the commit point indicated by commitHash.|
||Creates a new branch called branchName at the current “commit”.|
||Checks out the branch branchName into the workspace.|
||Creates a new branch called branchName from the current commit and checks it out to the workspace.|
||Use this to rename your branches.|