Title Text
Title Text
Title Text
Title Text
OTher Concepts And Tools
VERSION CONTROL SYSTEMS
VERSION CONTROL SYSTEMS
WITHOUT Version Control
Without a way to track the changes in our code, a few issues take form:
- What is the latest version?
- New features introduced errors. What now?
- Two developers working on the same code. How do they merge their work? How do they prevent conflicting alterations?
- Local machine dies. What happens to the work?
WITH VERSION CONTROL
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.
BENEFITS OF VERSION CONTROL
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.
TYPES OF VERSION CONTROL
Local VCS
A simple database that keeps all the changes to files under revision control.
TYPES OF VERSION CONTROL
Centralised VCS
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.
TYPES OF VERSION CONTROL
Distributed VCS
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.
GIT BASICS
A Little History
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
GIT
Speed
Simple design
Strong support for non-linear development
Fully distributed
Capacity to handle large projects efficiently
GIT
GIT
GIT SETUP
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 johndoe@example.com
$ git config --global core.editor vim
$ git config --list
$ git help <verb>Check this link for a VIM tutorial.
Live coding
Creating and using a Git repository
Live coding
Cloning a Git repository
Live coding
Viewing the commit history
Live coding
Undoing work on Git repository
Live coding
Working with remote repositories
GIT BRANCHING
Branching in Version control Systems
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.
Creating Branches
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?
Creating Branches
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.
Changing between Branches
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>
Live coding
Git branches: basic example
Other Branch Functionalities
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
Managing REmote Branches
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:
- delete the old remote branch
- push the renamed local branch again.
Managing REmote Branches
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.
Live coding
Git branches: local and remote management
GIT Merge
Merging branches
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.
Merging branches
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?
Merge Conflicts
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.
Merge Conflicts
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.
Live coding
Git branches: merging
Version Control Systems
By Soraia Veríssimo
