Without a way to track the changes in our code, a few issues take form:
Version control is the practice of tracking and managing changes to software code.
Version Control Systems are Software tools that help software teams manage changes to source code over time.
Complete, long-term change history of every file - includes creation and deletion of files, as well as edits to their contents.
Branching and merging - creating a "branch" in VCS tools keeps multiple work streams independent from each other while providing the facility to combine that work back together.
Traceability - tracing each change, annotating it with a message that describes its purpose and intent, and connecting it to project management and bug tracking software, can help with root cause analysis and other forensics.
A simple database that keeps all the changes to files under revision control.
A single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.
Clients don't just check out the files' latest snapshot; they fully mirror the repository, including its entire history.
If any server dies, any client repository can be copied back up to the server to restore it. Every clone is a full backup of all the data.
Linux Kernel is an open source software project, with thousands of collaborators.
1991-2002 changes were passed around as archived files
2002 - started using BitKeeper (proprietary)
2005 - BitKeeper's free-of-charge policy revoked; Linus and the community decided to develop their own tool
Strong support for non-linear development
Capacity to handle large projects efficiently
After installing git in your machine, you'll want to do a few things to customise your git environment.
$ git config --global user.name "John Doe" $ git config --global user.email firstname.lastname@example.org $ git config --global core.editor vim $ git config --list $ git help <verb>
Check this link for a VIM tutorial.
Creating and using a Git repository
Cloning a Git repository
Viewing the commit history
Undoing work on Git repository
Working with remote repositories
Branching refers to the creation of a new line of development, separate from the main line.
This can be used to work on a new bug fix or feature without affecting the main line in the process.
Compared to other VCSs, Git has a branching model that is quite lightweight, as branches are movable pointers, which are moved as new commits are created.
By default, repositories have a "master" branch - now more commonly called "main" branch". This is created automatically with the git init command.
In order to create a new branch, the git branch <branch-name> command can be used. It will create a new branch, which will point at the commit of the current branch.
At this point, we will have two branches pointing at the same commit. How do we know and change in which branch we are working on?
The HEAD file is a reference to the current branch. When a new branch is created with the command git branch <branch-name> the HEAD remains in the previous branch.
The git checkout <branch-name> command allows for switching between pre-existing branches.
It is also possible to create and automatically change to a new branch with git checkout -b <branch-name>
Git branches: basic example
The git branch command can be used for other functions:
git branch or git branch --list provides a list of existing branches
git branch -d <branch-name> deletes a branch
git branch -m <branch-name> renames the current branch
git branch -m <old-name> <new-name> renames another branch
The previous commands work with branches at a local level.
In order to apply these changes to the remote repository, we must push the changes:
git push <remote-alias> <branch-name> pushes a copy of the branch to the remote repo URL, saved in the remote alias (the alias is commonly origin)
In order to rename a remote branch, the process is a bit different. After renaming the local branch:
In order to delete a remote branch:
git push <remote-repo> --delete <branch-name>
This action does not affect the local branches associated with the deleted branch of other people. They can create a new remote branch, or recreate the same using push.
Managing remote branches can also be performed in the browser.
Git branches: local and remote management
Once we have finished the work of a specific branch, we will want to bring the new changes to the main line (or to another branch), by merging them.
Specifically, a target branch is merged into the current branch, by finding a common base commit and combining the changes into a new merge commit.
Unlike others, merge commits have two parent commits.
Before performing a merge, it is important to check if:
- We are at the branch that will receive the merge
- There are no "uncommited" changes
- Both the receiving and merging branches are up-to-date
After these checks, the merge can be performed, using the command git merge <merging-branch>
What happens if each branch has different changes in the same part of a file?
In these cases, Git identifies the merge conflicts, which must be resolved before creating the merge commit.
The files with merge conflicts can be checked with git status, and can then be solved with any editor or Git GUI (or even in the Git bash).
The sections with merge conflicts are identified as follows:
This is our text file. <<<<<<< main This was the 2nd line, on the receiving branch. ======= This was the 2nd line, on the merging branch. >>>>>>> feature branch This is the third line, no changes here.
Content of a simple .txt file, where the second line was different in both branches.
To solve the conflicts, the files in question must be updated in order to contain the changes of either or both branches.
The undesired changes (and the symbols used for the merge conflicts) must be removed.
After all conflicts are solved, the merge commit is created as any other commit, by using git add to add the now-solved files and then git commit.
This is our text file. This was the 2nd line, on the merging branch. This is the third line, no changes here.
Content of the simple .txt file, where we kept the changes from the merging branch.
Git branches: merging