CVS
CVS may very well be where version control systems started. Released initially in 1986, Google still hosts the original Usenet post that announced CVS. CVS is basically the standard here, and is used just about everywhere – however the base for codes is not as feature rich as other solutions such as SVN.One good thing about CVS is that it is not too difficult to learn. It comes with a simple system that ensures revisions and files are kept updated. Given the other options, CVS may be regarded as an older form of technology, as it has been around for some time, it is still incredibly useful for system admins who want to backup and share files.
SVN or Subversion
SVN, or Subversion as it is sometimes called, is generally the version control system that has the widest adoption. Most forms of open-source projects will use Subversion because many other large products such as Ruby, Python Apache, and more use it too. Google Code even uses SVN as a way of exclusively distributing code.
Because it is so popular, many different clients for Subversion are available. If you use Windows, then Tortoisesvn may be a great browser for editing, viewing and modifying Subversion code bases. If you’re using a MAC, however, then Versions could be your ideal client.
Git
Git is considered to be a newer, and faster emerging star when it comes to version control systems. First developed by the creator of Linux kernel, Linus Torvalds, Git has begun to take the community for web development and system administration by storm, offering a largely different form of control. Here, there is no singular centralized code base that the code can be pulled from, and different branches are responsible for hosting different areas of the code. Other version control systems, such as CVS and SVN, use a centralized control, so that only one master copy of software is used.
As a fast and efficient system, many system administrators and open-source projects use Git to power their repositories. However, it is worth noting that Git is not as easy to learn as SVN or CVS is, which means that beginners may need to steer clear if they’re not willing to invest time to learn the tool
Mercurial
This is yet another form of version control system, similar to Git. It was designed initially as a source for larger development programs, often outside of the scope of most system admins, independent web developers and designers. However, this doesn’t mean that smaller teams and individuals can’t use it. Mercurial is a very fast and efficient application. The creators designed the software with performance as the core feature.
Aside from being very scalable, and incredibly fast, Mercurial is a far simpler system to use than things such as Git, which one of the reasons why certain system admins and developers use it. There aren’t quite many things to learn, and the functions are less complicated, and more comparable to other CVS systems. Mercurial also comes alongside a web-interface and various extensive documentation that can help you to understand it better.
Bazaar
Similar to Git and Mercurial, Bazaar is distributed version control system, which also provides a great, friendly user experience. Bazaar is unique that it can be deployed either with a central code base or as a distributed code base. It is the most versatile version control system that supports various different forms of workflow, from centralized to decentralized, and with a number of different variations acknowledged throughout.
One of the greatest features of Bazaar is that you can access a very detailed level of control in its setup. Bazaar can be used to fit in with almost any scenario and this is incredibly useful for most projects and admins because it is so easy to adapt and deal with. It can also be easily embedded into projects that already exist. At the same time, Bazaar boasts a large community that helps with the maintenance of third-party tools and plugins.
What is Git
By far, the most widely used modern version control system in the world today is Git. Git is a mature, actively maintained open source project originally developed in 2005 by Linus Torvalds, the famous creator of the Linux operating system kernel. A staggering number of software projects rely on Git for version control, including commercial projects as well as open source. Developers who have worked with Git are well represented in the pool of available software development talent and it works well on a wide range of operating systems and IDEs (Integrated Development Environments).
Having a distributed architecture, Git is an example of a DVCS (hence Distributed Version Control System). Rather than have only one single place for the full version history of the software as is common in once-popular version control systems like CVS or Subversion (also known as SVN), in Git, every developer's working copy of the code is also a repository that can contain the full history of all changes.
In addition to being distributed, Git has been designed with performance, security and flexibility in mind.
Why use git?
1. Its fast
2. You don't need access to a server
3. Amazingly good at merging simultaneous changes
4. Everyone’s using it
Install git tool on your system
Website: https://git-scm.com/
Windows:
Install git software
https://git-scm.com/download/win
Go to git scm download page, Select windows.
Open git installable and follow the Installation wizard, take all the default settings in the wizard.
# sudo apt-get install git (Ubuntu) or
# yum install git (Centos)
Local git areas & Basic Git workflow
Local git areas
In your local copy on git,
files can be:
– In your local repo
• (committed)
– Checked out and modified,
but not yet committed
• (working copy)
– Or, in-between, in
a "staging" area
• Staged files are ready
to be committed.
• A commit saves a snapshot of allstaged state.
Basic Git workflow
• Modify files in your working directory.
Stage files, adding snapshots of them to your staging area.
• Commit, which takes the files in the staging area and stores that snapshot permanently to your Git directory.
Initial Git configuration
As you read briefly in Getting Started, you can specify Git configuration settings with the git config command. One of the first things you did was set up your name and email address:
1. System level configuration
2. Global/User configuration
3. Repository / local level configuration
System level configuration
System level configuration are available for Entire System.
The first place Git looks for these values is in the system-wide /etc/gitconfig file, which contains settings that are applied to every user on the system and all of their repositories. If you pass the option --system to git config, it reads and writes from this file specifically.
Note: Generally this configuration is not recommended.it is always better to go with other two Global configuration and Repository level configuration
Global/User configuration
Global/User configuration are available for Current LoggedIn User.
If you pass the option --global to git config, it reads and writes from ~/.gitconfig file specifically.
Note:Better to go with other two Global configuration when you want to have setup for a user.
core.editor
By default, Git uses whatever you’ve set as your default text editor via one of the shell environment variables VISUAL or EDITOR, or else falls back to the vim editor to create and edit your commit and tag messages. To change that default to something else, you can use the core.editor setting:
$ git config --global core.editor vim
Now, no matter what is set as your default shell editor, Git will fire up vim to edit messages.
Repository / local level configuration
The git config command lets you configure your Git installation (or an individual repository) from the command line. This command can define everything from user info to preferences to the behaviour of a repository. Several common configuration options are listed below.
Define the author name to be used for all commits in the current repository.
Comments
Post a Comment