Git: Working in Teams
Most of the time, working in teams to deliver a working product is the way to go, especially to a customer. The traditional way of waiting for an individual to finish their code and then passing to another individual is bothersome and time inefficient. More than that, a way to track what has been done or changed by the previous individual is not an easy thing to do. Therefore, a more modern way of working in teams is needed to solve the problem. This is where Git comes in handy, as it is the most used version controller.
Git is software for tracking changes in any set of files, usually used for coordinating work among programmers collaboratively developing source code during software development. Its goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different systems).
A lot of words right? In short, git is a Version Control System. A control system means that Git is a content tracker. The content stored in Git are usually codes due to the features it includes. A Version Control System tracks the history of changes made to a project. This is because code in Git usually changes over the time by individuals of a team.
How to use Git
Since Git is a practical tool, the best way to explain is by giving examples.
A complete guide on how to install Git is available on https://git-scm.com/book/en/v2/Getting-Started-Installing-Git .
To verify that Git has been installed, go into your command prompt and type:
Creating a Local Repository
In your computer, create a folder for your project. Let’s say, the name of the project is
Go into the directory you wish to create your project in, and use the following command to initialize the local Git repository:
Add some Code
README file is added first before anything else. A
README file describes the project. And since the main focus of this article is Git, we will not be covering a particular programming language. Create a file called
README.md and type what ever you want. Here is an example of the content:
# My First Project
My first ever project
Staging and Committing the code
Committing is the process in which the code is added to the local repository. Before a code is committed, it needs to be in the staging area. The staging area is to track files that are to be committed. Files that are not added to the staging area cannot be committed. This gives developers control over which files are to be committed.
Now let’s try to add our
README to the staging area:
git add README.md
You can also add multiple files to the staging area by leaving a blank space between each file like this:
git add file1 file2 file3
You can also add all files that have been changed to the staging area using:
git add .
To commit a file, use the command bellow:
git commit -m '<commit-message>'
By adding the
-m flag to
git commit , you can add just add a commit message into the command. Make sure the commit message is relevant to the change you made to the file.
Now, let’s say you want to add some more details about your project to the
README file like this:
# My First Project
My first ever project
This is a demo for Git
You can use
git status to find out about new or modified files and files that are in the staging area.
Since we just made a modification to our
README , after running
git status in the command prompt, the status shows that our
README file is modified and is yet to be added to the staging area. So we can do that now:
git add README.md; git commit -m 'add more details to README'
We can use
git log to print out all the commits up to the time the command was called. It shows the author of each commit, the date, and the commit message.
Git lets you branch out of your original code. This lets changes to the project be done in parallel. The default branch of a project is
master. To see which branch we are in, we can use
git status . We can also see what branches are in our local by using
git branch . To see remote branches, use
git branch -r . To see all branches, use
git branch -a .
Creating a New Branch Locally
First of all, be in the branch that you wish to be the parent of the new branch. In this case, the parent branch should be
master . Let’s say we want to create a new branch named
my-branch , we can used
git branch <branch-name> to create the branch and then checkout to the branch using
git checkout <branch-name> like this:
git branch my-branch
git checkout my-branch
Or we can also use a one-line command which will automatically checkout to the new branch:
git checkout -b my-branch
Now, modify the
README file in our new branch and commit it:
git add README.md git commit -m "my-branch commit"
Now that we’ve made a commit in our new
my-branch , our
my-branch is now ahead of the
master branch by 1 commit. To verify the commit in
my-branch , we can use
git log .
Now that our new
my-branch branch is ahead of
master branch. We can merge our changes made to
my-branch to the
master branch using
git merge . To merge
my-branch to the
master , we first have to checkout to the
master branch and the run
git merge :
git checkout master
git merge my-branch
The merge should be successful if there are no conflicts. If conflicts are present, we’ll have to resolve them first before the merge is done.
If we run
git log in
master branch, we should see the same number of commits as our
Remote Git Repository
We’ve only been working in the local repository. Each developer will work in their local repository but eventually, they will push their code into a remote repository. Once the code is in the remote repository, other developers can see and modify that code.
One of the most used remote repositories are GitHub. Go to the website and start a project. Give the repository a name and create the repository. It will create a remote repository in GitHub with the name we just specified.
In order to point our local repository with the remote repository, use the command:
git remote add origin <remote-repository-url>
Pushing to Remote Repository
Since our local branch has not existed in the remote repository, we add a
-u flag to the
git push command:
git push -u origin master
Else, if our local branch does not exist in the remote repository, simply use the standard push command:
git push origin master
Pulling Latest Changes
git pull is used to fetch the latest changes from the remote repository into the local repository. This is useful when multiple developers work on the same project as code in the remote repository will consistently be updated as time goes on.
git stash command takes you uncommitted changes (both staged and unstage), saves them away for later use, and the reverts them from you working copy. To re-apply your staged changes, use
git stash pop . To view stashes, use
git stash show .
Rebasing is changing the base of you branch from one commit to another making it appear as if you’d created you branch from a different commit. The primary reason for rebasing is to maintain a linear project history.
git rebase <base>will automatically take the commits in your current working branch and apply them to the head of the passed branch. Using the
git rebase --interactive <base> begins an interactive rebasing session instead of blindly moving all of the commits to the new base.
git revert command can be considered an improved ‘undo’ type of command. Instead of removing the commit from the project history, it figures out how to invert the changes introduced by the commit and appends a new commit with the resulting inverse content. This prevents Git from losing history, which is important for the integrity of your revision history and for reliable collaboration.
git revert takes a specified commit, inverse the changes from that commit and create a new “revert commit”.
To revert a commit, simply use:
git revert <commit-hash>
Git is a powerful tool for version control especially for teams developing software. It has the functionality, performance, security, and flexibility that most teams and individual need. Even though some might say it is hard to learn, Git still very capable and provides a lot of power to its user.
Thanks for reading!