GNU/Linux Desktop Survival Guide by Graham Williams
Desktop Survival Project Home Preface Advocacy History Distributions Installing GNU/Linux Basic Survival Wajig Applications AI, Machine Learning, Data Science Android - GNU/Linux Devices Audio Backup Booting CD Chinese ChRoot Clock Command Line Databases DIA Directories Disks EcoSysL Emacs Email Evolution Files File Systems Firewalls Floppy Disks FreedomBox Glade GNOME Graphics, Images, Photos Hardware Initialisations on Booting Installation Examples Internet IOT Java KDE Kernels Keyboard Konqueror KVM Switch LATEX Log System Login Magellan MATE Mathematics Memory Modems Mounting Devices MS/Windows Music MySQL Nautilus Networks Nextcloud Network File System NFS NT File System Oracle Packages Partitions Passwords PDF Power Management PPP Presentations Printing Python R Remote Desktops Rsync Samba Scanning Science Screens Security Spreadsheet SSH Swap Teradata Data Warehouse Themes TV Unity USB Version Control Video Virtualization Voice over IP WebCam WordPress Web Sites Word Processing and Printing X XML Troubleshooting Index

CLICK HERE TO VISIT THE UPDATED SURVIVAL GUIDE

Version Control

20190611 In this chapter we review the use of git for the control of versions of documents. The concept of version control is central to a software development project as well as data science and indeed almost any material generated on a computer.

The concept of source code version control is itself very old, dating from the original SCCS (Source Code Control System) and RCS (Revision Control System) I used in the 1970s and 1980s. The 1990s brought CVS (Concurrent Versions System) and SVN (Subversion). Recognising the need for a better supported distributed model of development Canonical (the developers of Ubuntu) developed Bazaar to set the standard for distributed version control systems. Since 2005 GIT provided the gold standard for the state-of-the-art.

Modern version control systems like git support distributed version control where multiple users collaborate through their own local working copies of the repository and branching from the main branch to ring fence specific development. Syncing with the central repository is maintained as required, using the concept of pull requests to review and integrate local changes back into the main branch of the origin.