Version Control & Git Flow

Version Control? Is that even needed?

Version control is a system that maintains and logs every history of changes that have been made to files and you can see it anytime. At a glance, it might seem weird and unnecessary to check any codes that have been created, changed, or removed previously. But it can be really important, you might accidentally delete an important part of code, have a conflict in a code made between teams, or have a second thought to return a removed function. Of course, all of them could be saved into a local backup, but it would totally hinder you and your team.

Limited space, hard to find a piece of code and not know if that has been removed yet, or wasting time to check the difference of the code after you put them together. It was all in the past, no need to waste your time and make it harder for your work. Those people who had the same problem with you in that aspect had the initiative to create this system to make their and your work easier.

Git, The Best Version Control System?

You may be familiar with git, with how common you can find them used across lots of projects you might be doing. Git is a free and open-source distributed version control system created by Linus Torvalds that was originally intended for Linux kernel development. Have you ever wonder why git used so often and if there is any version control other than git? There are lots more other version control:

• Subversion
• CVS
• Perforce
• Clearcase

But a lot of them are outclassed by git. There are some arguments about git being the best, but there is one thing for certain, it IS the most used version controller. With some argument of its superiority over others:

• Faster to commit, you work mostly locally and commit to git repository once in a while.
• No single point of failure, every developer has their own repository locally. They can still do commit locally even when something broke within the central repository.
• Available offline, git commit can be on hold offline until it is pushed to the git repository.

Git Command

Several commands commonly used in git:

• Git branch, show branches that exist in the git repository
  Branching facilitates the development and isolates it from other codes which not necessarily connected. It can effectively give a pointer for any changes.
• Git checkout, move to another branch or make a new branch, also can be used to accessing past commit temporarily.

git checkout <branch-name> # For switching to another branch
git checkout -b <new-branch-name> # For creating a new branch
git checkout <commit-number> # For accessing past commit

• Git clone, duplicate remote repository to local with the exact file placement. It can be done using HTTPS or SSH.

git clone <repo-location> # It can be found in git repo page

• Git commit, create a new commit with its comment.
  Commits are pretty useful to save changes you sure of and encapsulate codes you change altogether.

git commit # Will open your IDE for commit message writing
git commit -m "Your message" # Put commit message with the command

• Git merge, merge branches into one.
  Usually, when a function of a branch has been completed, it would be merged into the application.
• Git pull, pulling any changes made to git repository if there is any difference with the local repository.
• Git push, pushing any changes made locally to the git repository.
• Git rebase, move or merge commit sequence to tidy it up.

git rebase <base-branch>

• Git remote, view shortname list of every remote.
• Git revert, make a new undo commit of another commit while maintaining the commit history.

git revert <commit-number>

• Git stash, store any changes made locally without making a commit.

git stash # To put any change to stash
git stash pop # To re-apply stashed changes

Git Flow

In our project, we use three branches, master (production), staging, and product backlog. The Master branch is used when the product is completed. The staging branch is used to be the development branch, where every development function will merge before going to production usually happen when the product owner has agreed with the backlog. There are branches for every backlog and may have smaller branches for each user story.

Because in our project, we implementing TDD. There are naming rules for making a commit message. For starters, if start with “[RED]”, it would mean the commit is for failing test. If it starts with “[Green]”, it would mean the commit would have the test run successfully. And if it starts with “[CHORES]”, then it is a commit for any changes that won’t affect the program.

Experience

For our project, we use Gitlab as our version control. It’s really useful as we can actually check each other team progress and code proactively. Pointer or feedback for any change could be done in each merge request commits comments. And I may have done a bad practice of putting credentials inside a code file, and this could change and be removed permanently from git history.