When I applied for my current project, I was asked what my Git workflow looks like. I was confused because I didn't understand at all what the interviewer wanted me to say. What is a Git workflow? Does she mean that I work on a branch and then merge it into the master?
Since this would be my first time working on a project in a professional team in a company, I was quite confused that there should be an extra generic term for just these two actions. How little did I know 😅.
It turned out that this was exactly what she wanted to know. She then explained to me in great detail what the Git workflow was for this particular project. Let's take a closer look.
Table of content
- Git workflow as I knew it at that time
- Workflow of the project and project setup
- How I start working on an issue
- Conclusion
Terms you should know before you continue reading
I use some terms interchangeably with each other. Let's clarify these beforehand so that your reading flow is not disturbed.
- Pull Request = PR
- user story = user task = issue
- master branch = main branch
- repository = repo
- acceptance criteria = AC
- Sensei = the developer with the greatest responsibility in the team
1. Git workflow as I knew it at that time (which I actually didn't 🙈)
When you work on your side projects, you usually write the code for a particular part in its own branch first before merging it into the main branch. At least, that's how I always do it.
But working on this professional project for one of the biggest companies in my home country, I realized that it can be way bigger and much more complex than I ever imagined.
However, all these steps are necessary to make sure that the code quality and functionality are proven before presenting the result to our stakeholders and Product Owner (PO). A lot depends on this online presence, so everything has to work on the first try as soon as the site goes online.
2. Workflow of the project and project setup
Every company or project has its own workflow. As I said before, our project is huge, really huge. That's why we work on two different repositories, one for the backend and one for the frontend, using different programming languages and tools depending on the repo. To host our code, we work with Gitlab.
Frontend repository
For the frontend I am working with
- VS Code IDE, writing code in SCSS
This repo is only for SCSS code and assets (like images, SVGs, icons). To deploy changes, I have to run the git run deploy command, which can take up to eight minutes each time 😵. So I mostly work with the web development tools of the browser to see my changes immediately and add them to the stylesheet later.
Backend repository
- IntelliJ Edu IDE
- Java, Freemarker, React and Angular
Since I only need to deploy some parts of the backend code depending on the user story (otherwise it just takes too long to deploy the entire repo each time for just minor changes, by that I mean up to 40 minutes 🤯), I work with IntelliJ Edu, which makes it easier to click on the specific folder to run the deployment instead of writing a command in the console in VS code.
Workflow
There are different responsibilities within the team:
- Frontend developers work mainly on issues related to the UI
- Backend developers work on issues regarding functionality
- Senior developers are allowed to merge the created branches into the test branch when they receive Pull Requests
- Sensei is solely responsible for merging the test branch with the master branch
- Sensei creates a PR from the master to the stage branch
- DANGER ZONE: Only developers of our client are allowed to work on the stage and prod branch
3. How I start working on an issue
As you can see in the figure above, I start creating my branch from the master by running git checkout -b tag/number_name.The tag is what I can see in the user story whether it is a bug, a new feature or a defect, e.g. The number is the number automatically assigned by the Kanban board using Jira (a project management tool) in ascending order. I assign the name myself after I learn what the story is about.
💡 Adding the issue number to the branch name is the most important part of creating the branch, because only then our Sensei can link the issues and know which branch can be merged or deleted (without asking each developer individually each time).
💡 Also, when I push my changes to the remote branch, I have to make sure that I add the issue number to the commit message, especially if I make changes to an issue in a branch that already exists. This is the only way Sensei will be able to find the changes to the issues themselves.
In the issue I find what my task is about and what the acceptance criteria are. If it is a new feature, I also find a Figma design to see what the result should look like.
In case of a bug 🐛, the current state and the desired state are described and pictures are added to illustrate the scenario.
When I'm done with my code, I merge it into the int branch and start running the Jenkins pipeline. Jenkins allows me to make sure my code is valid and does not break the int environment. The pipeline takes about 1 hour to finish.
If everything is okay, I create a Pull Request from my branch to the test branch and assign it one of the Seniors.
Waiting for my code to be reviewed ⏳
The senior reads my PR and tests the code. If everything is okay, they merge the changes into the test branch and start the Jenkins pipeline for the test branch. If not, I have to adjust my changes and go through the whole process again, 😵💫 i.e. make my changes to the original branch, merge it into int, start the Jenkins pipeline on int, create a PR to merge my branch into the test branch after everything seems fine.
If Jenkins in the test branch is happy, the testers will start testing my code to make sure everything works as expected. If it does, the changes from the test branch are applied to the master branch. If not, see the previous paragraph, both I and the seniors have to do all the steps again afterwards 😵💫😵💫.
Danger ☠️ Zone
My code made it to the master branch, finally 😮💨. Now only one developer is allowed to work on the master branch, our Sensei. When some changes of the current week are gathered on the master branch, Sensei makes the last changes and asks us to rebase our current branches once a week.
So we need to rebase all existing branches we are still working on to avoid future merge conflicts. Rebasing means that the branch I am currently working on gets all the changes from the master branch to be up to date.
Every two weeks (sprint), when many user tasks are merged into the master branch, Sensei creates a PR for the stage branch, which is hosted by our client's developers. No one from our team is allowed to work on these branches. What happens there is a mystery only Sensei knows about 🤐.
4. Conclusion
I'm learning a lot about Git on this project and using Git commands I never used before. Finally, I'm not afraid of these commands anymore. Working with the GitLens extension also makes it a bit easier and is one of the reasons I feel much more confident working with Git now. I feel like a Git Pro 😎.
I also never used the development tools that much before. There is so much you can do with it without writing a single line of code in an IDE.
I find this whole process very interesting, so this
What does the Git workflow look like for your projects?
will definitely be one of my future interview questions to my interviewer.
Thanks for your reading and time. I really appreciate it!
Top comments (0)