In the past few years, GIT has become the de-facto source control system for web development. However, it’s not an easy task to learn how to use GIT effectively if you want to create high-quality web applications and a reliable GIT Workflow.
That’s why there are several strong GIT Workflow available that can help you master this essential tool.
Steps we take for a reliable GIT Workflow
- Creating a repository
- Check staged, unstaged, and untracked files
- Create a changelog file for a strong GIT Workflow
- Create branches and naming conventions for a solid GIT naming system
1. Creating a repository
1. Login at GitHub and create a new repository
2. Follow the steps for quick setup:
git init – Create a new repository or reinitialize an existing one. This command creates .git folder in our current project directory
git add . – Adds all of the files from the current directory into the staging area. Those files are ready to commit
git commit -m “first commit” – Sends off files for safekeeping. In the message, we usually shortly explain what the changes in the files are.
git branch -M main – It forces the renaming of the branch to main
git remote add origin https://github.com/Eagle-IT-Solutions/plutori-blog.git -Git is a distributed version control system, as most of us are probably aware. Most of the work is done locally. Also, Git makes use of so-called “remotes” to communicate with the outside world. These are repositories that you can push your changes into (so that others can see them) or pull from (so that you can get others’ changes). This command adds a new remote called origin to the https://github.com/Eagle-IT-Solutions/plutori-blog.git repository. After that, instead of typing out the entire URL in the push command, we can simply push to origin.
git push -u origin main – The git push origin main command basically pushes the commits, in the local branch named main, to the remote named origin. When we run this, whatever we last synchronized with origin will be transferred to the remote repository, where other people will be able to see it.
2. Check staged, unstaged, and untracked files
We use git status to check which files are staged, unstaged, and untracked.
- Staged files are those files that are in the staging area ready to be committed. We used git add [file] to add a file to the staging area.
- Unstaged files are the files in our working directory that Git hasn’t recorded yet in its version history. We usually add them to the staging area or discard them.
- Untracked files are files that exist only locally and that are not in the Git repo. Untracked files will appear in Git status list, unless they have been added to an ignore list – .gitignore
Now we want to add all untracked files in the staging area, so first, we run: git add .
Then we add a commit message “Adding bootstrap auth scaffolding” and press enter. But when we pressed enter we might have provided a wrong or incomplete message. In order to change our commit message we use the following command: git commit –amend
This command opens, in our case, vim editor and lets us change the message. For that purpose, we do the following steps:
- Press “i” – to be able to insert/modify the commit message
- Change the commit message
- Press ESC
- Type :wq (Write & Quit)
Once we are done, we push to git.
3. Create a changelog file for a strong GIT Workflow
A changelog file is a crucial step in creating a reliable GIT Workflow.
You’re probably already familiar with the command git log – It prints 5+ lines per commit, including the date, the author’s commit message, and the commit id. It is presented in reverse chronological order, which makes sense in most cases because we are most interested in recent changes.
We wanted to show you how we make use of this command to create a changelog log file that we can modify according to our preferences, so we have all changes neat in one place.
- git log – as mentioned, this command returns a list of all the commits that have been made in a repository
- We can customize our log by providing some specifications, like in this example we have:
–date=local – this will show the timestamp in our local’s timezone
–pretty=format:’Date %cd %nDescription:%n%s%n—————————————–%n’
This specifies in which format we want the logs to appear.
In our case, we show the %cd (committer date), then %n (newline), after that comes the subject in a newline (%s) and we end the section of one message with what appears to be a horizontal line. To see more details about the pretty formats you can visit this link: https://git-scm.com/docs/pretty-formats - The last part of the command (> changelog.log), basically writes the output of the git log command to the changelog.log file
We can now easily modify the changelog if we need to make some corrections or comments.
4. Create branches and naming conventions for a solid GIT naming system
As we know Git stores data as a series of snapshots. When we make a commit Git stores a commit object that contains a pointer to the snapshot of the content we staged when we made the commit. This object also contains the author’s name and email address, the message we typed, and pointers to the commit or commits that came directly before this.
In Git, a branch is simply a movable pointer to one of these commits. In Git, main, in our case, is the default branch name. As we begin to make commits, we’ll be given the main branch that points to our most recent commit. The main branch pointer advances automatically every time we commit.
We usually use the following commands to work with branches:
git branch [branch name] – command used to create a new branch
git checkout [branch name] – command used to switch to the specified branch
But mostly we use one command to create a new branch and switch to it with one line:
git checkout -b [branch name]
Now that we went through the basics of how to create a branch, let’s talk about the naming convention we all follow in our company.
Probably, you are wondering why we need to use some “strict” rules for naming the branches. The answer to this question is not to put ourselves in a situation of confusion caused by improper naming. In addition, the name of the branch should be self-explanatory of what that fix or feature is about. That leads us to our next point: how we should name our branches? To explain the answer to this question we will pose some points:
- Determine the main point of the task: is it a bug fix? A feature? Or is it a work in progress?
- Once you identify that, you will put the right prefix of the branch, for example:
fix – if it’s a bug fix
feature – if it’s a feature
wip – if it’s a work in progress - Next, shortly describe what the change is about. When writing that short description we use ‘-‘ (dash) for spaces. Make sure that the “short description” is readable and up to the point.
Let’s suppose we have a blog and for the Post we want to allow the user to attach more than one image per post. We identified that this problem is a feature, now the next step is to think of a short, simple, yet understandable “description”.
Example of readable description: multiple-post-images
Example of unreadable descriptions: allowmultipleimagesforpost, in-the-post-add-more-than-one-image - Finally, having decided, on both, the type of the problem and the description we can merge them with / (slash) as a separator. So, the above-mentioned feature would be on a branch named as follows:
feature/multiple-post-images
Anyone who works in IT should understand how important working effectively with GIT is for maintaining reliable systems at all times without excessive effort. There are several easy steps anyone can take toward that goal including regular workspace planning and applying natural synergies between software development and GIT towards producing better results and a Reliable GIT Workflow every time you code!