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:
• Source code
• Build scripts
• Implementation notes
• Test cases
• Deployment scripts
• Data files
• Design documents
• Requirement definitions
• And more
Coordination Problems
Individual?
Team?
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
(holds what the developer
is currently working only)
Workspace
(holds what the developer
is currently working only)
VCS
Repository
(keep track of all work
artifacts, with a complete
change history)
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
Files
Staging
Area
Repository
(clone)
Git
Git
Remote
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
Working
Files
Staging
Area
Repository
Clone
Git
Git
Clone
Staging
Area
Working
Files
init
BASIC GIT OPERATIONS
Repository
Working
Files
Staging
Area
Repository
Clone
Clone
clone
pull
merge
add
commit
push
Staging
Area
Working
Files
NON-BARE VS. BARE REPOSITORIES
• Bare Repositories are used as central or shared repositories
• Developers cannot make changes directly in bare repositories
Bare Repository
Non-Bare Repository
Working
Files
Staging
Area
Clone
Clone
pull
merge
add
commit
push
Staging
Area
Working
Files
git clone… à #CLEAN COPY
git add, git status, git commit, git push… à rejected
git pull … à CONFLICT
Fixing conflict … à edit the file and remove <<<<<<< HEAD … >>>>>>>
git add, git commit, git push… à #DONE
GITHUB
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, that may be needed to resolve conflicts
GIT SOFTWARE
• GitHub
• https://github.com/
• Git comes with a command line user interface
• There are GUI front-ends (e.g., GitHub Desktop, SourceTree,
TortoiseGit, Git Extensions) if you want to find, install, and learn
one of them on your own, go for it.
SERVICE PROVIDERS FOR REMOTE GIT REPOSITORIES
• Popular Git Service Providers:
• GitHub
• Bitbucket
• GitLab
• CloudForge
• GitBucket
• RocketGit
• And more
• You may use any Git service
provider, but I prefer GitHub
GETTING STARTED WITH GITHUB
• Install git on computer(s)
•
Visit
•
https://git-scm.com/book/en/v2/Getting-Started-Installing-Git
• Create your account using your personal email, if you don’t have one
•
Visit https://education.github.com/
• Register for a free account (with your personal email, and then add your institutional email to your
account)
• 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 (your computer)
•
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>
• Start practicing other git commands
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 A PROGRAMMING CLASS
• 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
STRUCTURE OF YOUR PROJECT REPOSITORY IN GITHUB
• 01-Definition: Document for the definition of your project, link to your youtube video (the
final one)
• 02-Requirements : SRS (IEEE-830) and other needed documents to gather customers’ needs
• 03-Documentation: Any document needed that is not a model or the requirements definition
• 04-UMLDiagrams
•
01-UseCases: vpp and pdf file
•
02-ClassDiagram: vpp and pdf files
• 05-UnitTests : test cases document, unit tests
• 06-Code : Netbeans, Visual Studio, any code
• 07-Other : Any other document
WHAT’S NEXT…
Programming Paradigms…