THE JOY OF “GIT”

OBJECT ORIENTED PROGRAMMING – ESPE, JORGE EDISON LASCANO

BASED ON THE SLIDES OF
STEPHEN CLYDE PH.D., UTAH STATE UNIVERSITY
 MANAGING SOFTWARE DEVELOPMENT ARTIFACTS
The primary assets of any software development organization
are its software and associated work artifacts
Some common artifacts: Coordination Problems Individual? Team?
• Source code
• Build scripts
• Implementation notes
• Test cases
• Deployment scripts
• Data files
• Design documents
• Requirement definitions
• And more
VERSION CONTROL SYSTEMS
• A Version Control System (VCS) is a software system that helps
teams and individual developers manage change to the work
artifacts

Workspace
(holds what the developer
is currently working only)

Workspace Repository
(holds what the developer VCS (keep track of all work
artifacts, with a complete
is currently working only)
change history)

Workspace
(holds what the developer
is currently working only)
VERSION CONTROL SYSTEMS
• There are many open source and proprietary VCS’s currently
available, e.g., CVS, SVN, Mercurial, and Git
• They differ in terms of
• How the repository is structured
• Where it is kept
• The kinds of files that can be tracked
• Whether developers must “checkout” or “lock” a work artifact working on it
• When and how work artifacts are checked in
• How conflicts are resolved
GIT
• Git is an open-source distributed VCS, and perhaps currently the most
popular
• Git can track changes for any kind of file
• Workspaces hold a clone or replica of the full repository and a staging
area, as well as working files

Workspace

Working Staging Repository Remote

(clone) Git Git
Files Area Repository
GIT
• Because Git is a peer-to-peer distributed system, a remote
repository can be treated just like a workspace.
• For this reason, both the local and remote workspaces are often
simply called repositories

Repository Repository

Working Staging Clone Clone Staging Working

Files Area Git Git Area Files
BASIC GIT OPERATIONS

init
Repository Repository
Working Staging Clone Clone Staging Working
Files Area clone Area Files

pull

merge

add

commit
push
NON-BARE VS. BARE REPOSITORIES
• Bare Repositories are used as central or shared repositories
• Developers cannot make changes directly in bare repositories
Non-Bare Repository Bare Repository
Working Staging Clone Clone Staging Working
Files Area Area Files

pull

merge

add

commit
push
ADVANCED GIT OPERATIONS

• We’ll only use the following basic operations: init, clone, pull, merge,
add, commit, and push
• We will not cover
• Branch
• Tags
• Checkout
• Fetches
• Reset
• And other advanced operations
GIT SOFTWARE
• GitHub
• https://github.com/

• Git comes with a command line interface

• There are GUI front-ends (e.g., SourceTree, GitX, and gitext) if you
want to find, install, and learn one on your own
SERVICE PROVIDERS FOR REMOTE GIT REPOSITORIES

• Popular Git Service Providers: • You may use any Git service
• GitHub provider, but I prefer GitHub
• Bitbucket
• CloudForge
• CodeBase
• GitLab
• RocketGit
• And more
GETTING STARTED WITH BITBUCKET OR GITHUB
• Install git on computer(s)
• Visit
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUK
Ewic5MGp3O3UAhVTxCYKHdDoCUEQFgg-MAE&url=https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fgit-
scm.com%2Fdownloads&usg=AFQjCNHZLDrEFiZHXrz1JGq57NFHFrcfkA

• Visit https://education.github.com/
• Register for a free account (with your institutional email)
• Using the on-line interface, create a repository
• This does a “git init –bare <your repository>” , set up bare repository that you own and control
• Clone that repository to your own system
• Open a terminal window
• Change directories to the parent directory that you want to hold the project’s repository
• Copy the HTTPS URL for your repository from the GitHub webpage
• In the terminal window, type: git clone <paste the URL>
BEST PRACTICES FOR USING GIT

• Commit and push changes frequently, but not every written line
• Typically, commits should involve one or a small number of related
changes. But not every line of code.
• Don’t wait until you’re done with a project
• Don’t separate commits for unrelated changes
• Enter a meaningful and concise comment with each commit, that
will help you remember what the changes were for and why you
made them
WHY USE GIT IN OOP

• Access examples and starting code for homework assignments

• Track changes to your artifacts
• Protect your work artifacts from accidental loss
• Start to build a portfolio of software projects that will become part
of your resume
• Learn a valuable skill that will be useful in future classes and that
employers expect you to know