Version Control Systems in Software Development

 
Git & Version Control
 
1
 
Kevin Scannell, David Ferry
CSCI 5030 – Principles of Software Development
Saint Louis University
St. Louis, MO 63103
 
Version Control 101
 
Project files (source code, etc.) are stored
in a “repository” and are shared with all
developers.
 
All changes are “committed” to the
repository with a descriptive log message.
 
Developers work independently, but
commit meaningful increments back to the
project when they are finished.
 
CSCI 5030 – Principles of Software Development
 
2
 
Historic Reasons for Version Control
 
Shared, up-to-date code base
There is no “master” copy of the code
Multiple programmers can work on the same code
simultaneously
Committed code is always backed up
Tracks and attributes all changes to code
All changes have a log message that records why the
change was made
These are things that programmers did before
version control, just manually
 
CSCI 5030 – Principles of Software Development
 
3
 
Modern Reasons for Version Control
 
Modern techniques have evolved around the use of
version control.
Allows branching of project – e.g. stable branch,
experimental branch, specific release branches
Feature branches – can develop each feature in it’s
own branch with “pristine” code base. When feature is
done and tested it is merged
Allows “diff” between any two versions of code
Allows debugging and “root cause analysis.” Can find
the exact commit (and why) that introduced a bug
Allows “blame view” – can see files with each line
annotated by the person who added it and the log
message
Bigger systems (like GitLab) incorporate project
planning, code reviews, etc. into repository
 
CSCI 5030 – Principles of Software Development
 
4
 
Scope of Version Control
 
Meant for source code
Works really well for plain text files
Also: data files, config files, build scripts, test code,
documentation, READMEs, license, the project
web site, etc.
Again, works great when things are plain text
Generated products are not stored
E.g. object files and other intermediate build results, including
final binary
Other project’s source code and libraries are up for
debate
Replicating where code lives is usually not great
What if your build script automatically fetches remote libraries
if they’re not present on your system?
Dependencies and version numbers should at least be
documented
 
CSCI 5030 – Principles of Software Development
 
5
 
Centralized VC Systems
 
First VC systems were centralized “client-
server” systems.
Only one official master copy
All clients communicate to-from that
official master
The official master has control: e.g. can
enforce policy by “locking” files, etc.
 
These are systems such as CVS and SVN
 
CSCI 5030 – Principles of Software Development
 
6
 
Distributed VC Systems
 
Distributed VC adopts a peer-to-peer model
Every copy of the repository contains the entire
repository and its entire history
No master copy- all copies are equal
Don’t confuse “master branch” in Git with a “master
repository”
Developers can work locally using VC features
without having to talk to any upstream VC server
Multiple local copies can all have revisions, must be
manually synchronized (e.g. with git pull)
Allows for different workflows that don’t make
sense in centralized VC
Integrator workflow, dictator & lieutenants, etc.
 
CSCI 5030 – Principles of Software Development
 
7
 
Git
 
Linus Torvalds in 2005 (where else have I
heard that name…?)
Needed a fast, distributed, and safe
version system for the Linux kernel
StackOverflow survey in 2018 said 88% of
professional developers used Git in their
work (next highest was SVN at 17%)
 
CSCI 5030 – Principles of Software Development
 
8
Git in a Picture (e.g. at SLU)
CSCI 5030 – Principles of Software Development
9
Remote
(origin)
Working
Copy
Local
Local
Working
Copy
git.cs.slu.edu
Machine 1
Machine 2
 
Ex: on machine 1
git pull origin master
<make changes>
git commit * -m “xyz”
git push origin master
 
Git in a Picture (e.g. at SLU)
 
CSCI 5030 – Principles of Software Development
 
10
Remote
(origin)
Working
Copy
Local
Local
Working
Copy
 
git.cs.slu.edu
 
Machine 1
 
Machine 2
 
Ex: on machine 1
git pull origin master
<make changes>
git commit * -m “xyz”
git push origin master
 
Basic Git Terminology
 
origin – the remote repository that you originally cloned the
project from
master – the master branch
remotes – copies of the repository that are stored on a
remote server (contrast with local copies that are stored on
each developer’s machine)
working copy – the file system where developers look at
and modify code on their own machine (but is not the local
repository)
branches – “copies” of the master branch used for
developing new features
forks – real copies of the repository used for developing
new features
 
CSCI 5030 – Principles of Software Development
 
11
 
Common Git Commands
 
git clone – fetch a new repository and create
a new working copy of that repository
git add – add files to version control
git commit – save changes to the local
repository
git push – send changes from the local
repository to a remote
git fetch – update your local repository
without modifying the working copy
git pull – update your local repository and
merge those changes with the working copy
 
CSCI 5030 – Principles of Software Development
 
12
Slide Note
Embed
Share

Version control systems like Git play a crucial role in modern software development by enabling developers to store, manage, and track changes to project files efficiently. They allow for shared code bases, multiple programmers working simultaneously, commit logs, branching strategies, and more. These systems provide benefits for both historic and modern reasons, offering features like bug tracking, root cause analysis, and project planning integration. Version control is primarily meant for source code but can also handle various other file types effectively, excluding generated products. The evolution from centralized to distributed systems has revolutionized how teams collaborate on software projects.

  • Version Control Systems
  • Software Development
  • Git
  • Source Code Management
  • Collaboration

Uploaded on Sep 15, 2024 | 0 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Git & Version Control Kevin Scannell, David Ferry CSCI 5030 Principles of Software Development Saint Louis University St. Louis, MO 63103 1

  2. Version Control 101 Project files (source code, etc.) are stored in a repository and are shared with all developers. All changes are committed to the repository with a descriptive log message. Developers work independently, but commit meaningful increments back to the project when they are finished. CSCI 5030 Principles of Software Development 2

  3. Historic Reasons for Version Control Shared, up-to-date code base There is no master copy of the code Multiple programmers can work on the same code simultaneously Committed code is always backed up Tracks and attributes all changes to code All changes have a log message that records why the change was made These are things that programmers did before version control, just manually CSCI 5030 Principles of Software Development 3

  4. Modern Reasons for Version Control Modern techniques have evolved around the use of version control. Allows branching of project e.g. stable branch, experimental branch, specific release branches Feature branches can develop each feature in it s own branch with pristine code base. When feature is done and tested it is merged Allows diff between any two versions of code Allows debugging and root cause analysis. Can find the exact commit (and why) that introduced a bug Allows blame view can see files with each line annotated by the person who added it and the log message Bigger systems (like GitLab) incorporate project planning, code reviews, etc. into repository CSCI 5030 Principles of Software Development 4

  5. Scope of Version Control Meant for source code Works really well for plain text files Also: data files, config files, build scripts, test code, documentation, READMEs, license, the project web site, etc. Again, works great when things are plain text Generated products are not stored E.g. object files and other intermediate build results, including final binary Other project s source code and libraries are up for debate Replicating where code lives is usually not great What if your build script automatically fetches remote libraries if they re not present on your system? Dependencies and version numbers should at least be documented CSCI 5030 Principles of Software Development 5

  6. Centralized VC Systems First VC systems were centralized client- server systems. Only one official master copy All clients communicate to-from that official master The official master has control: e.g. can enforce policy by locking files, etc. These are systems such as CVS and SVN CSCI 5030 Principles of Software Development 6

  7. Distributed VC Systems Distributed VC adopts a peer-to-peer model Every copy of the repository contains the entire repository and its entire history No master copy- all copies are equal Don t confuse master branch in Git with a master repository Developers can work locally using VC features without having to talk to any upstream VC server Multiple local copies can all have revisions, must be manually synchronized (e.g. with git pull) Allows for different workflows that don t make sense in centralized VC Integrator workflow, dictator & lieutenants, etc. CSCI 5030 Principles of Software Development 7

  8. Git Linus Torvalds in 2005 (where else have I heard that name ?) Needed a fast, distributed, and safe version system for the Linux kernel StackOverflow survey in 2018 said 88% of professional developers used Git in their work (next highest was SVN at 17%) CSCI 5030 Principles of Software Development 8

  9. Git in a Picture (e.g. at SLU) git.cs.slu.edu Ex: on machine 1 git pull origin master <make changes> git commit * -m xyz git push origin master Remote (origin) Machine 1 Machine 2 Working Copy Working Copy Local Local CSCI 5030 Principles of Software Development 9

  10. Git in a Picture (e.g. at SLU) git.cs.slu.edu Ex: on machine 1 git pull origin master <make changes> git commit * -m xyz git push origin master Remote (origin) Machine 1 Machine 2 Working Copy Working Copy Local Local CSCI 5030 Principles of Software Development 10

  11. Basic Git Terminology origin the remote repository that you originally cloned the project from master the master branch remotes copies of the repository that are stored on a remote server (contrast with local copies that are stored on each developer s machine) working copy the file system where developers look at and modify code on their own machine (but is not the local repository) branches copies of the master branch used for developing new features forks real copies of the repository used for developing new features CSCI 5030 Principles of Software Development 11

  12. Common Git Commands git clone fetch a new repository and create a new working copy of that repository git add add files to version control git commit save changes to the local repository git push send changes from the local repository to a remote git fetch update your local repository without modifying the working copy git pull update your local repository and merge those changes with the working copy CSCI 5030 Principles of Software Development 12

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#