A Simple Guide to Using Git in Your Team’s Projects
In this post, I’ll tell you some useful things about using Git as a version control system to handle our projects with speed and efficiency.
Just a few helpful things about Git that I got while working on my team’s project
In collaborative projects, it is necessary to use a version control system. I also used a version control system in my 2021 PPL projects using Git. My team is working on this project with agile development. After working on the project, there are a few things that I think need to be known for using git in agile development.
1. When Doing Project Initialization
When starting a project we need to initialize an empty repository by creating a folder for the project and running git init . However, when I am working on my project, I use git clone to initialize my local repository because the project previously was initialized and stored in a remote repository. The git clone <repository url> command is used when the repository already exists and is stored in a central or remote repository. Git clone is a command that copies or clones our remote-repository to the local-repository on our computer. Both commands are generally a one-time operation.
2. While Working in the Project Repository
When I work on the repository, I discovered several things that we need to understand to work effectively.
Make Some Branches
We need to create multiple branches to make it easier for us to work collaboratively. In my project repository, there are multiply branches for developing, staging, and working on features in the project. This very useful to reduce confusing conflicts when working on a feature task and want to save it in a remote repository.
To see all existing branches, we can use git branch -l and when we want to view the remote-tracking branches, we can use git branch -r. When we want to see the current branch, we can use git branch --show-current. When we want to create a new branch we can run git checkout -b <branch name>, This command will create a new branch containing documents and information on the current branch. Finally, we can use git checkout <branch name> to switch branches and git branch -r <branch name> to delete a branch.
There are two branches that you can use to correct job errors. First, Coldfix Branch that stores a repository before a commit is pushed. Second, the Hotfix branch, which is a new branch created from the Master Branch if a bug or error occurs in the Master.
Save Our Work
When working on tasks, we often only save our changes locally by “save file” even though it doesn’t save any new changes to our work in HEAD in the repository. HEAD is the most recent version of our repository. We can use the git add and git commit commands to save changes to the working tree to make it the latest version of the branch in our repository.
We can use git add * to add changes to all files to the staging area and git add <file name> to add only specific file changes to the staging area. Sometimes, I run git remove <file name> when there are files that I don’t add to the staging area. Then, I have to use git commit-m <commit message> to record all changes in the staging area to the repository. Commit messages can be filled with changes we have made. It is better to use tags to make it easier for other people that read the commit we did to work collaboratively. The necessary tags are [RED] for commits containing unit tests but no implementation code yet, [GREEN] for commits containing unit tests and implementation that be able to pass unit testing in the [RED] phase. [REFACTOR] for commits that contain implementation fixes to previously created code, and [CHORES] for commits from implementations that are not related to functionality.
I usually run git status to see the working tree status. The working tree status contains the current branch and files that have changed.
When Working With Remote Repositories
Collaborative work means that we will often deal with remote repositories. Therefore, we need to set up our remote repository with git remote add origin <server>. Origin is the name of the remote we want. In my project, my friend made a new remote in order to save the local repository to the repository in GitLab. This was done because our university servers were down so GitLab.cs.ui could not be opened and prevented us from doing our work. Because of that, my team members created another remote in the local repository to keep it working.
Then, we can use git push origin <branch name> for sending changes to remote and git pull origin <branch name> to retrieve changes from the remote. Sometimes when I usegit pull, there is a conflict because I haven’t committed to the local repository. When I still don’t want to save my changes, I usually run git stash to save changes in my dirty working directory into the stash-state, and after doing git pull from remote, I will run git stash pop to revert or apply the changes I previously saved. Because of that, my team members created another remote in the local repository to keep it working.
When we want to merge two branches we can use git merge <branch-name-1>. It will concatenate the <branch-name-1> with the current branch and make a new commit for the merge command. If you don’t want to make new commits and only want to combine a few commits into a new base commit, you can use the command git-rebase .
There are other commands you can use to see in detail what changes have occurred between two Git reference points. the command is git diff. An example of this command when comparing between the working directory and last commit with git diff HEAD and for comparing staged changes and last commit with git diff — cached .
Understanding the Difference between Git Reset and Git Revert
When we notice a mistake in a commit, we will try to restore the previous commit. There are two ways to restore the previous commit, git reset and git revert. Usually, when I make a mistake in the commit and the branch hasn’t pushed to the remote, I will use git reset to cancel the commit that I have done. We can add --hard to return the file to its last commit state or — soft to keep the changes made in git reset. As for git revert, I use it when the branch with the error is already on the remote and has been pull by someone. Git revert will create a new commit containing the changes made to the previous commit you wanted.
In cases where you haven’t commit and are just run git add, you can use the git clean command to delete files from your working directory.
These commands are very useful when you are working with agile. When something goes wrong in your code/work and you need fast development, you can use this command to return your code to the previous commit stage so you can start over from the beginning of your work. git revert also helps you to restore previous commits so that they can be pulled by other members to continue.
I usually use a git log to see the commit history and help figure out the commits I want to reset. I also use git reflog to see a log of changes to the local repository HEAD.
3. Using Extensions in the Code Editor
In working on a project, we need to use extensions in our code editor because these extensions will help and make it easier for us to do our tasks. I also use this in my project, I add several extensions to my visual studio code. there are several useful extensions for git, such as GitLens and Git History. I use Git History to see the commit history for my branches. The advantage of this extension is that we can do git reset --soft, git reset --hard, git checkout -b, git revert, git merge, and git rebase on the desired commit easily.
This extension is important because it will make it easier for you to see the existing commit history and be able to see the file changes that have been made.
These are all things I got over the past two years using git to work as a team. Later, I will add new helpful tips when I find other useful things in my work. :D
