CS 458 - Week 2 Labs - 9:00 am lab - 2017-08-30
* Git - a popular distributed version control system
* invented by Linus Torvalds (yes, of Linux fame)
* GitHub - a website, a web-based HOSTING service for
software development projects that use Git
* can obtain a local version of git from a number of
places -- for example:
windows.github.come <-- Windows version, convenient installer
mac.github.com <-- Mac version, convenient installer
Linux? I think this works:
sudo apt-get install git
(Pro Git 2nd ed -- posted in course References --
has more installation info)
* we are FOCUSING mostly on command-line Git, to start;
* a typical command structure:
git <desired command> <arguments>
* you can access the man page for a particular
command with the approach:
man git-<desired command>
* you can CONFIGURE various bits of user info and settings
with:
git config ...
(so, get info on using:
man git-config
)
* IF you want to configure your user information
across all local repositories
git config --global <name> <value>
* you can (and should) set a name to be given
for credit when reviewing version history
git config --global user.name "your name"
git config --global user.name "Sharon Tuttle"
* also a good idea: set an email addres to be
associated with each history marker:
git config --global user.email "valid email addr"
git config --global user.email "st10@humboldt.edu"
* a couple more:
* automatic command line coloring (if terminal supports)
git config --global color.ui auto
* you can set a default text editor:
git config --global core.editor emacs
* to SEE your current config:
git config --list
* let's talk about line feeds!
this is the core.autocrlf config property
some of its possible values include:
* false <- the default, Git leaves line feeds alone
* true
* Git replaces CRLF with LF when putting files
into the git object database,
but when YOU grab something it turns all LFs
into CRLFs
^ this is the recommended setting for Windows
* input
* Git replaces any CRLFs with LF when putting
files into the git object database,
BUT it does not change them with grabbing
something
^ this is often used for Linux/Unix/Mac OS X
git config --global core.autocrlf <desired value>
* you can make a new repo from scratch!
git init <newproject>
* makes a new directory <newproject> and it has an
"invisible" subdirectory .git with the repo info
* what if you have a directory with stuff and you say,
hey, I want this to be a git repo!
* cd to that directory
* git init
* adds the .git directory to make this a git repo
* to add the current files to this repo (STAGE them)
git add .
* to COMMIT these now-staged original files,
git commit -m "initial import"
* to see your current repo status:
git status
* what if you are getting a repo from github?
* let's say there is one there -- 458lab01-2-demo
* (when you click the green clone-or-download button
in the GitHub repo,
and click the clipboard button,
you copy the GitHub repo's URL ---
and then on YOUR computer, you can type:
git clone <that URL>
for example,
git clone https://github.com/hsu-cs458-f17/458lab02-1-demo.git
* SO -- let's say you have a git repo, one way or another;
* do your work;
* a recommended commit philosophy:
* do small commits often
* BUT!!! try to only commit things that
COMPILE and WORK (try to leave the repo in
a good state)
* use "social mechanisms" to get people to do that
* another recommended philosophy:
work, then "stage", then commit
* change your files
* stage a file to be commited:
git add <desired_file>
* ...when you think all the files you want
for a commit are staged,
commit, giving a description of this version
git commit -m "description"
* use
git status
as much as you want to check out where you are
* AND if this is a cloned repo,
you can push the committed changes TO the
remote master, the repo you cloned from, using:
git push origin master
* git log
...lets you see a log of your commits
* git diff <file>
...lets you see the differences between a current
file and its commited version