Git Flow and Its Implementation
Git Overview
If you study software development, you might ever heard about Git. Before you get deeper understanding about Git, you should know what pushes developers to start using Git and why you should use it. In its page, it is explained that Git started as a distributed version control system (VCS) to help developers work on projects efficiently. In the book that Git published, version control is a system that maintains records of changes to a file or a set of files so that you can refer to a specific version later. Among some sorts of VCS, Git uses distributed VCS. One of the advantages of using distributed VCS among the rest is that the repository is not stored in a single server but mirrored by all clients that use it. When the server that stores the server is down, any of the client repositories can be used as a backup to restore it.
Just like any methods or paradigms in programming, Git started by demand to work on projects more efficiently. The Linux kernel is an open source software project of a large scope. In the past, changes to the software were sent through conventional means like patches and archived files. In 2002, Linux kernel project started using distributed VCS called BitKeeper. In 2005, the relationship between Linux kernel community and BitKeeper company got worsened. As a result, developers couldn’t use BitKeeper freely anymore. This pushed the community (including Linus Torvalds, the founder of Linux) to develop their own system. Some of the aims of the new system are speed, simple design, strong support for non-linear development (thousands of parallel branches), fully distributed, and able to handle large projects like the Linux kernel efficiently. The new system then was created and named Git.
Git Basic Commands
In the book published by Git, these are some of the basic commands of Git.
- Getting a git repository
There are two ways to get a Git repository on your local device:
a. Initialize repository on an existing directory
For example, if you have ppl directory in your local device:
$ cd C:/Users/user/ppl
and type the following command on you terminal
$ git init
You will create .git subdirectory on the ppl directory. As the subdirectory was created, you’re now able to do git commands on the ppl directory through the terminal, for example:
$ git add *.c
$ git add LICENSE
$ git commit -m 'Initial project version'
b. Cloning an existing repository
If you have created online repository in gitlab or github, you can clone the repository to your local device. For example, if you have a repository named ppl, you can type on your terminal:
$ git clone https://github.com/libgit2/ppl
The command above will create ppl subdirectory on the current directory that you open on terminal. If you want to clone the repository by different name, for example ppl-frontend, you can type on your terminal:
$ git clone https://github.com/libgit2/ppl ppl-frontend
2. Recording changes to the repository
There are two kinds of file state in git, tracked and untracked. In short, tracked files are files whose changes are recorded by Git, while untracked files are the opposite.
To check the state of the files, you can use the command git status. If you don’t have any untracked files, you will get the following output:
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean
If you add a file, for example, README on your project and you don’t add it to the git, you will get the following output:
$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
README
nothing added to commit but untracked files present (use "git add" to track)
To add the file to the git, you can type on your terminal:
$ git add README
Now, you will get the file tracked by the Git. Finally, if you have passed all the tests in your local device (for test-driven development), you can commit and push. You have to make sure you make a meaningful message on the commit. For example:
$ git commit -m "Add README file"
3. Branching and merging
If you already have some files on master branch and you want to create a branch from the current branch, for example, branch development, you can type on terminal:
$ git checkout -b development
Switched to a new branch "development"
If you want to switch back to the master branch, you can type on terminal:
$ git checkout master
Switched to branch 'master'
If you have finished your task on the development branch and you want to merge it to the master branch, you can type on terminal:
$ git checkout master
$ git merge development
Updating f42c576..3a0874c
Fast-forward
index.html | 2 ++
1 file changed, 2 insertions(+)
If you no longer need the development branch and you want to delete it, you can type on terminal:
$ git branch -d development
Deleted branch development (3a0874c).
Sometimes, when you want to merge your branch to a branch that is used by many people, you will get conflict as you update a file that other people working in the branch also update. The conflict is going to look like this:
$ git merge development
Auto-merging index.html
CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.
Fortunately, when conflict happens, Git usually gives you clue on which part in the code is conflicting. The clue usually look like this:
<<<<<<< HEAD:index.html
<div id="footer">contact : email.support@github.com</div>
=======
<div id="footer">
please contact us at support@github.com
</div>
>>>>>>> development:index.html
The section from <<<<<<< HEAD:index.html
to =======
is the latest version of the master branch, while the section from =======
to >>>>>>> development:index.html
is the latest version of your current branch that you want to merge (development). You are free to choose which version that you want to keep. For example, if you want to keep your current branch version, you can replace above code with
<div id="footer">
please contact us at support@github.com
</div>
After you resolve the conflict, you can add the update to Git, commit, push, and merge with the master branch.
Git Implementation in My Project
In this semester, I am working on a project from my course in college. The project is named BisaGo. For more info about BisaGo, you can watch this video or read my review about the project. In the project, the flow of the Git is usually like this:
- I edit some parts of the code
2. Everytime I finish editing a file, I add the file to Git (so the changes are tracked)
3. For editing in different files, I do different Git commits
4. Since the project is test-driven development, I commit the failing code first (not pass the test cases), then commit the working one (pass the test cases).
5. After I make sure the codes pass the test cases in my local computer, I push the commit in my development branch (dev-ardian)
6. I request merge to the PBI branch and ask two of my teammates to approve my merge
In the end, I conclude that Git flow allows developers to code and upload their codes more neatly and efficiently. I hope my article about Git flow can help you accomplish basic understanding on Git flow.
Reference: