Git as a Version Control
When working on a software development project, be it individually or collaboratively, there are many potential problems that may occur such follows:
- More than one person is working on a project, can it be done without much conflict?
- Software evolves and many versions will be developed. How to ease devs to maintain older versions, like to revert easily whenever there’s changes that causes problems?
- How to keep up to date with the latest code change by my friends? Since my work is dependent on his work.
These questions can be answered with git. Git is a software that can track changes especially to codebases, commonly used by programmers to work in team. It ensures speed, data integrity, non-linear workflows that really helps programmers to publish, document, and maintain updates of the team’s works.
If you are working closely with coding, be it for software development, data, or others, this software is a must-have tool. Not only for collaborative use, but also for personal use. For me, I did the following personal project :
- Teaching Code & Uploading Template Assignments
- Personal Website
- University Class Practices
Github vs Gitlab
GitLab and GitHub are collaboration platform that helps review and manage codes remotely. They protect the source code from bugs and conflicting issues. It makes easier to track changes in the code files. The most significant difference between the two is that GitLab supports DevOps and CI/CD tools.
Git Commands (+ My Implementation In Walkiddie)
Initialization
1.Git init
When you have an existing project on your local machine and you want to integrate it with git, do git init like this example.
Make sure that .git file is present after executing the command as a sign of initialization success.
2. Git clone
If you want to get another project from a remote repository like Github or Gitlab, you can do a git clone <remote url> like this.
Synchronization
3. Git Fetch
Git fetch and git pull commands are used to download commits, refs, and files from remote repository into our local repository. The difference is that git fetch doesn’t merge the change to your current branch, meanwhile git pull forces to merge any updates to your current branch. Example is provided in git pull section.
# Fetch all branches from remote repositorygit fetch <remote># Fetch specified branch from remote repositorygit fetch <remote> <branch>
4. Git Pull
Git pull will automatically merge the remote updates to your current branch. In the image below, I changed the readme.md in Gitlab. When I only did git fetch, the change didn’t take place, but when I did git pull, it overrides my local readme.md.
# Pull and apply changes from remote repository to local repository’s current branchgit pull <remote># Pull and apply changes from remote repository’s specified branch to local repository’s current branchgit pull <remote> <branch>
5. Git Push
Git push will publish changes you made locally to Gitlab. Here is the code example and syntax.
# Push specified branch to a remote repositorygit push <remote> <branch># Push all local branches to a remote repositorygit push <remote> — all# Push all local tags to a remote repositorygit push <remote> — tags
6. Git Remote
Developers need to manually pull upstream commits into their local repository or manually push their local commits back up to the central repository. The git remote command is really just an easier way to pass URLs to these “sharing” commands. If you’re all using the same remote, then everything (every code you push to that remote) syncs up.
If your local repository hasn’t connected yet with remote repository, add it to your remote list.
# Show list of our connection with remote repositoriesgit remote -v# Create connection with remote repositorygit remote add <name> <url># Remove connection with remote repositorygit remote rm <name># Rename a remote connection from old to newgit remote rename <old-name> <new-name># Show detailed configurations output with remote repositorygit remote show <name>
Undo Changes
7. Git Reset, Revert, Restore
When you make an undesirable change and want to undo that, there are 3 scenarios. First, you already pushed that change. Second, you only committed that change locally. Third, you just added the changes without committing it. For the first case, use revert, for the second, use reset, and the last one use restore.
When you just committed the changes, use git reset.
You can undo commits or changes that haven’t been pushed into remote repository with git reset command.# Undo last commit in local and keep the changesgit reset — soft HEAD# Undo last commit in local and restore the changesgit reset — hard HEAD# Undo the specified commitgit reset <COMMIT_HASH>
If you’ve already pushed your changes and other developers have pulled the changes, you need to git revert and push the changes.
git revert <COMMIT_HASH>When you only added the changes, use restore like follows.
# Discard changesgit restore .# Move from Staged area into Unstagedgit restore — staged .
Moving Branches
8. Git Checkout and Git Branch
By developing them in branches, it’s not only possible to work on both of them in parallel, but it also keeps the main branch free from questionable code.
Below are some useful syntax to list down all branches, create and delete a branch, and moving to different branch.
# List of all branches in our repositorygit branch -v# List of all branchesgit branch -a# Create branch from specified branchgit checkout -b <new-branch> <from-branch># Switch to another branchgit checkout <other-branch># Rename current local branchgit branch -m <branch># Delete local branchgit branch -d <branch># Delete remote branchgit push <repo-name> — delete <branch>
Below is the example of how I create a new branch called PBI-6_Homepage_admin and checking out to that branch from master, and then going back again. You can always check you current branch location with git status .
After finished the work in a branch, the developer usually create a Merge Request (on GitLab) or a Pull Request (on GitHub). This phase is where the collaboration take place because it may require each of us to comment or fix another person’s work. Although you can also set the number of reviewers required to 0.
9. Git Merge and Git Rebase
Both merge and rebase allows you to merge branches from Git. However, there is a slightly different outcome. You just need to know your need.
# Merge current branch with ANOTHER_BRANCH_NAMEgit merge <TARGET_BRANCH_NAME> <WITH_OTHER_BRANCH_NAME># Rebase current branch with ANOTHER_BRANCH_NAMEgit rebase <TARGET_BRANCH_NAME> <WITH_OTHER_BRANCH_NAME>git merge feature master
git rebase master feature10. Git Stash
Git stash command is used if you have changes and want to switch branches.
# Add changes into stash in the source branchgit stash# Apply changes in the destination branchgit stash apply
How Our Team Utilizes GitLab for Teamwork
- Issue Board
Issue board is very helpful to list down all the backlogs during sprint planning, adding descriptions of the work, adding weights, assigning works to members, and keep updates to our teammates work. We can also add issues that we encounter during project working and assign them to the person in charge accordingly.
- CI/CD
Every time we push our code to gitlab, continuous integration and deployment are taking place. On branch level, CI ensures that merging is successful, lint passed, all tests passed, and sonarqube works. Additionally, in staging, it does continuous delivery that notifies whether deployment fails or passes.
- Merge Requests
Merge requests are done at 2 levels. First is moving code from each branch to staging or development branch. And second, moving code from staging to master or final production branch. Everyone must make sure that pipelines are passed (including test) and peer-reviewed by minimum 2 teammates before merging to staging.
- Web IDE
What I find helpful about gitlab is that it provides online IDE. So, whenever I need to do a very small change to the codebase, I don’t have to do it locally and do all the git commands.
My Thoughts
Git and Gitlab has play a pivotal role in our team’s collaboration. Our team consists of 6 developers who works on many features each week. In many occasions, our task assignments were overlapping and highly dependent on one and each other. Thus, it is crucial to keep updates from other developers and ensuring no conflicts on production level. To avoid this, we stick with rule of 1 branch per feature, isolated. This methodology avoids confusing errors that are hard to trace the origins, because every code from each branch need to be reviewed before it is merged to staging. Also, due to CI/CD supports by gitlab, we can be notified if any errors occur on our test, assess code quality, and deploy the site safely.
