Version control in linux

How to Use Git Version Control System in Linux [Comprehensive Guide]

Version Control (revision control or source control) is a way of recording changes to a file or collection of files over time so that you can recall specific versions later. A version control system (or VCS in short) is a tool that records changes to files on a filesystem.

There are many version control systems out there, but Git is currently the most popular and frequently used, especially for source code management. Version control can actually be used for nearly any type of file on a computer, not only source code.

Version control systems/tools offer several features that allow individuals or a group of people to:

• create versions of a project.
• track changes accurately and resolve conflicts.
• merge changes into a common version.
• rollback and undo changes to selected files or an entire project.
• access historical versions of a project to compare changes over time.
• see who last modified something that might be causing a problem.
• create a secure offsite backup of a project.
• use multiple machines to work on a single project and so much more.

A project under a version control system such as Git will have mainly three sections, namely:

• a repository: a database for recording the state of or changes to your project files. It contains all of the necessary Git metadata and objects for the new project. Note that this is normally what is copied when you clone a repository from another computer on a network or remote server.
• a working directory or area: stores a copy of the project files which you can work on (make additions, deletions and other modification actions).
• a staging area: a file (known as index under Git) within the Git directory, that stores information about changes, that you are ready to commit (save the state of a file or set of files) to the repository.

There are two main types of VCSs, with the main difference being the number of repositories:

• Centralized Version Control Systems (CVCSs): here each project team member gets their own local working directory, however, they commit changes to just a single central repository.
• Distributed Version Control Systems (DVCSs): under this, each project team member gets their own local working directory and Git directory where they can make commits. After an individual makes a commit locally, other team members can’t access the changes until he/she pushes them to the central repository. Git is an example of a DVCS.

In addition, a Git repository can be bare (repository that doesn’t have a working directory) or non-bare (one with a working directory). Shared (or public or central) repositories should always be bare – all Github repositories are bare.

Learn Version Control with Git

Git is a free and open source, fast, powerful, distributed, easy to use, and popular version control system that is very efficient with large projects, and has a remarkable branching and merging system. It is designed to handle data more like a series of snapshots of a mini filesystem, which is stored in a Git directory.

The workflow under Git is very simple: you make modifications to files in your working directory, then selectively add just those files that have changed, to the staging area, to be part of your next commit.

Once you are ready, you do a commit, which takes the files from staging area and saves that snapshot permanently to the Git directory.

To install Git in Linux, use the appropriate command for your distribution of choice:

After installing Git, it is recommended that you tell Git who you are by providing your full name and email address, as follows:

To check your Git settings, use the following command.

View Git Settings

Creates a New Git Repository

Shared repositories or centralized workflows are very common and that is what we will demonstrate here. For example, we assume that you have been tasked to setup a remote central repository for system administrators/programmers from various departments in your organization, to work on a project called bashscripts, which will be stored under /projects/scritpts/ on the server.

SSH into the remote server and create the necessary directory, create a group called sysadmins (add all project team members to this group e.g user admin), and set the appropriate permissions on this directory.

Then initialize a bare project repository.

Initialize Git Shared Repository

At this point, you have successfully initialized a bare Git directory which is the central storage facility for the project. Try to do a listing of the directory to see all the files and directories in there:

List Git Shared Repository

Clone a Git Repository

Now clone the remote shared Git repository to your local computer via SSH (you can also clone via HTTP/HTTPS if you have a web server installed and appropriately configured, as is the case with most public repositories on Github), for example:

To clone it to a specific directory (

/bin/bashscripts), use the command below.

Clone Shared Git Repository to Local

You now have a local instance of the project in a non-bare repository (with a working directory), you can create the initial structure of the project (i.e add a README.md file, sub-directories for different categories of scripts e.g recon to store reconnaissance scripts, sysadmin ro store sysadmin scripts etc.):

Create Git Project Structure

Check a Git Status Summary

To display the status of your working directory, use the status command which will shows you any changes you have made; which files are not being tracked by Git; those changes that have been staged and so on.

Check Git Status

Git Stage Changes and Commit

Next, stage all the changes using the add command with the -A switch and do the initial commit. The -a flag instructs the command to automatically stage files that have been modified, and -m is used to specify a commit message:

Do Git Commit

Publish Local Commits to Remote Git Repository

As the project team lead, now that you have created the project structure, you can publish the changes to the central repository using the push command as shown.

Push Commit to Centrol Git Repository

Right now, your local git repository should be up-to-date with the project central repository (origin), you can confirm this by running the status command once more.

Check Git Status

You can also inform you colleagues to start working on the project by cloning the repository to their local computers.

Create a New Git Branch

Branching allows you to work on a feature of your project or fix issues quickly without touching the codebase (master branch). To create a new branch and then switch to it, use the branch and checkout commands respectively.

Alternatively, you can create a new branch and switch to it in one step using the checkout command with the -b flag.

You can also create a new branch based on another branch, for instance.

To check which branch you are in, use branch command (an asterisk character indicates the active branch):

Check Active Branch

After creating and switching to the new branch, make some changes under it and do some commits.

Merge Changes From One Branch to Another

To merge the changes under the branch test into the master branch, switch to the master branch and do the merge.

Merge Test Branch into Master

If you no longer need a particular branch, you can delete it using the -d switch.

Download Changes From Remote Central Repository

Assuming your team members have pushed changes to the central project repository, you can download any changes to your local instance of the project using the pull command.

Pull Changes from Central Repository

Inspect Git Repository and Perform Comparisons

In this last section, we will cover some useful Git features that keep track of all activities that happened in your repository, thus enabling you to view the project history.

The first feature is Git log, which displays commit logs:

View Git Commit Logs

Another important feature is the show command which displays various types of objects (such as commits, tags, trees etc..):

Git Show Objects

The third vital feature you need to know is the diff command, used to compare or show difference between branches, display changes between the working directory and the index, changes between two files on disk and so much more.

For instance to show the difference between the master and latest branch, you can run the following command.

Show Difference Between Branches

Summary

Git allows a team of people to work together using the same file(s), while recording changes to the file(s) over time so that they can recall specific versions later.

This way, you can use Git for managing source code, configuration files or any file stored on a computer. You may want to refer to the Git Online Documentation for further documentation.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

Linux Version Control & Configuration Management Tools

Configuration Management & Software Distribution Version-control tools are often used to store and control the configuration files (e.g. «AUTOEXEC.BAT» or «/etc/resolv.conf») for an operating system or software package. Administrators of large corporate networks turn to configuration management tools to guard against the accidental mangling of a config file, and to guarantee a uniform system configuration for a collection of workstations and servers. Configuration management tools are often integrated with software distribution tools, which automate the deployment and update of software packages across a large number of desktops.

Software Metrics When engineering or programming staff are making many changes during product development, management is often interested in statistics about the rate of change. Files which change a lot, repeatedly, over long periods of time, often indicate trouble spots. Software metrics are tools that can help locate trouble spots by generating statistics about code and changes in that code.

Bug Tracking and Problem Reports Because software change is often driven by problem reports, it is natural to integrate bug tracking systems with version control systems: this allows for a framework where changes resulting from a bug report can be easily located, and where some measure of certainty is provided that *all* changes have been integrated into a product release. This may not be an issue for small projects, but for anything much larger, say a half-dozen or more developers, few dozen released patches, and more than a few actively supported releases, such integration is mandatory.

General References

• A generic reference can be found at Andre’s Config-Mgmt Yellow Pages.
• Dave Eaton’s Configuration Management Tools Summary provides a thorough listing of products for all operating systems, some of which support Linux.
• The Project Management & Bug Tracking for Linux reviews bug tracking, call management, customer relationship management and project management tools for Linux.

Caveat Emptor

Open Source Version Control Tools

• gCVS is a graphical front end to CVS. Supports Linux, HP/UX, Win95/NT, Macintosh, and SunOS. Specifically designed to be easy to use; aimed at non-technical users, such as writers & the marketing department.
• RAD/CVS includes TCL/TK & Java interfaces to CVS. See the RADSoft page. The screen-shot looks rather impressive.
• TkCVS is another CVS GUI. See also the Tcl ftp site, and look for tkcvs.
• jCVS is a Java based graphical CVS client. The client runs on NT/W95 as well as Unix, as the screenshot illustrates.

Aegis Aegis is a «transaction-based software configuration management system», or, more simply, a source-code control system. GPL’ed, active project. (See also here.)

PRCS PRCS the Project Revision Control System, is the front end to a set of tools that (like CVS) provide a way to deal with sets of files and directories as an entity, preserving coherent versions of the entire set. Claimed to be easier to use than CVS, and higher performance too. Currently lacks network features, although these are being developed.

RCS RCS is an industry standard collection of tools providing basic file locking and version control mechanisms. Its strength and durability are indicated by the fact that almost all other version control tools use RCS as their low-level interface — RCS is the work-horse engine. RCS is low-level. Its not client-server. Its available on all Linux distributions.

SCCS An oldie but a goodie, SCCS is considered by many to be obsolete, but still has many active fans, and is in active development, in the form of GNU CSSC. Standards fans take note: the SCCS command line is standardized in the Single Unix Specification, Version 2

Commercial Version Control Products

ClioSoft SOS ClioSoft SOS is a revision control tool based on RCS. It is built around a client-server model, and works across the internet or on intranets. It has both a command line interface and a tcl/tk GUI interface. It supports all the basic operations and operates on directories as well. It has a bug tracking system incorporated into it. Popular in the ASIC and FPGA code development user community. Runs across Sun, Linux and Windows. It is simple and very straight forward with many pre-written scripts (e-mailing, snapshots, tags). Free for projects having 200 objects or less.

MKS Source Integrity The popular MKS Source Integrity version control system is now available from Mortice Kern Systems.

INTERSOLV PVCS PVCS provides software configuration management and version control. Runs under most all Unix’s, OpenVMS, Windows/NT, Windows 95, and OS/2.

Perforce Perforce generously allows you to try out their software before you buy. They allow non-commercial users of FreeBSD and Linux an unlimited free license. The design is client-server, and does not rely on a shared file system for distributed operation. The tool is an ASCII command-line tool, and although it include perl cgi scripts for invocation from a web browser, it does not have an X11 interface. Perforce provides RCS/CVS-to-Perforce conversion scripts.

CMZ CMZ Software Version Control and Configuration Management tool.

Razor Razor from Visible Systems Corp. Integrates with thier issue-tracking/workflow management system.

Configuration Management & Software Distribution

BEAM A tool for the automated distribution of software onto clusters of workstations. (ftp site).

rdist rdist is a low-level command for the automated distribution of files to remote computers. Most Linux distributions come with an rdist client. Check for «man rdist».

Host Factory Creating multiple, identical copies of a system can be hard work; it becomes even harder if patches and diffs need to be maintained. Multiply this by hundreds of computers . and Unix sysadmins go crazy. The Working Version company has created a system version control and distribution mechanism to manage entire installed system versions. In particular, their version-controlled file system (yes, literally, a file system . ) caught my technical eye. Pretty amazing!

Software Metrics

Document Management & Image Management

InterDMS InterDMS Internet Document Management System (in Italian . )

Casbah The Casbah project hopes to create an integrated content mangement / content creation / web development system for Linux.

. I saw a freeware document & image management tool for Linux, but misplaced the reference. Can you help?

docfs docfs — Unified Documentation Storage and Retrieval for Linux Systems appears to be a project to develop a document management system. With contributions from Martin d’Anjou

Источник