Just like in any team sport, working towards a common goal requires all team members to be in perfect sync. When collaborating on a project, putting a sound structure and workflow in place is the first step in achieving premium results. Over the years, our web development agency Chicago established a common-sense Git workflow that helped our team reach a higher level of productivity. This is why in today’s article, we’ll share our insights on how to use Git in a team. We hope that learning from our experience will help you align your team members on the same page and seamlessly navigate the collaboration process, saving you time and money along the way.
What is Git?
Git is a distributed version control system used for source code management. It allows a team of developers to work on the same code of the project, maintain the code, as well as track all the modifications of the code in project containers called repositories.
In layman’s terms, the process sees each developer using Git locally to track and save changes to their work and then utilizing source code management systems such as GitLab to merge their work into a single project.
What are branches in Git?
Branching is one of the most powerful features of Git. There are three types of branches when using Git as a team collaboration tool:
- Master branch (often called main or stable branch)
- Staging branch (sometimes called development branch)
- Feature branches
It is important to know that the master branch in the Git repository is a branch that is supposed to be a bug-free code. It is a deployable version of the code ready to go to the end-user. This is why working directly on the master branch and committing changes here is something we wouldn’t advise, since in case the master branch code breaks, it would break the code for all team members.
You can look at the branches in Git as separate copies of the codebase. These copies can be worked on separately and later merged into the master branch. This allows team members to work individually without conflicting with each other’s code. They can also test their changes against the source code (the master branch) and tend to any possible problems before merging their work into the project.
So instead of developing a feature on the master branch, you should be developing it on its dedicated branch. This is the version of the code that you can work on and make changes to it without compromising the entire project. While there is only one master and one staging branch, feature branches can vary in number. Once you’ve developed a feature on its feature branch and you’ve run tests on it and ensured everything works as it should, you can use Git to merge your feature branch into the main version of the code personified in the master branch.
Git tracks all changes made to each file. So if, for example, two of your team members work on the same file, each on a separate branch, but add completely different features to it (one adds feature A, the other one adds feature B), Git will be able to merge those files and the end-result will be the file that sports both feature A and B. On the other hand, if multiple team members modify a feature C of the same file, and those changes are in conflict, Git won’t be able to merge those files since it will not know which changes to save and which to discard. Instead, it will make an edited version of the file with all of the changes to feature C highlighted in order for you to decide what to include in the final version of the file.
How to create a feature branch?
We will continue our guide on how to use Git in a team by showing you how to create a branch that you can work on to avoid any code conflicts with your team members. There are two ways to do this.
You can use:
git branch your-branch-name
This way, you will create a new branch while staying on the current branch. Or you can create a new branch and immediately switch to it by entering:
git checkout -b your-branch-name from_this_branch (optional, if not given specifically, a new branch will be created based on the current branch version)
git switch -C your-branch-name from_this_branch
To rename the branch:
git branch -m new-branch-name
If you change branch name, but your branch is also present already in the remote (origin, for example), then you need to push the branch again upstream in order to be present on the remote, using:
git push -u origin new-branch-name
So, while the master branch and the staging branch are created once and stay in place throughout the whole process of the project development, the feature branches are created for the period during which a certain feature of the project is developed and later get merged into the staging branch.
You can always check which branch you are on by typing:
git branch
The staging branch
Git employs the concept of the two-stage commit. This means that when attempting to commit changes to the Git repository, you start by adding changes from the working directory (feature branches) into the staging area.
The staging area gives you the option to commit changes that are logically related and also check the staging version of your project online. In other words, while in the working directory, you can make changes to your files in whichever order you wish, and they don’t have to be related to one another. So, instead of committing all of the changes at once, you can stage those that are related.
A short overview of basic Git commands
- You may frequently want to save versions of your work. You can do this by staging the work you wish to save with git add and then entering git commit to tell Git to save those changes.
- If you wish to see what files Git is tracking, what files underwent changes, or what files have been staged for commit, use the git status command.
- To add an individual file to staging, use this command: git add your-file-name
- To remove a file from Git as well as from the branch, enter: git rm your-file-name
- If you have added all the files that you want to be saved to the staging, you can use the git commit command in this form: git commit -s -m “your message”. Leaving an explicit message visible in the commit history can help you review or roll back older files while it also provides useful info on the content of the code.
- You can check previous commits with the git log command. Even better git log -p
- To switch from one branch to another, use git checkout your-branch-name or git switch your-branch-name
- To view all existing branches, use git branch -a
- To delete a local branch, use git branch -d your-branch-name
- To delete a remote branch, use git push origin –delete your-branch-name
- To check the destination where your code is going to be pushed, use git remote -v
Feature development workflow
So far, we have covered the basics of Git structure and talked about ways to create a feature branch where you will be working on a certain feature of your project. In this section of our guide on how to use Git in a team, we’ll cover the actual feature development process. As we have already said, each team member will be working on their dedicated feature branch.
The first thing you need to do is check out your dedicated feature branch. You do this by entering:
git checkout -b your-branch-name
Once you’re there, you can implement the code to your file and develop the feature. The next thing you need to do is make the changes to your file available to all members of your team. In other words, you need to move the file into the staging area. In order to do so, enter the following commands:
git add .
git commit -m “commit-message”
git push origin your-branch-name
Note that origin is a reference to a repository on a remote computer from which your feature branch is created. What the last command line indicates is that you are attempting to push local code to the repository pointed to by origin. This way, you will create a new branch on that repository with the branch name you selected.
Once the file gets into the staging area, it gets committed with your commit message. While there are no strict rules to what your commit message should look like, in order to follow the best practices on how to use Git in a team, we suggest you all agree on a naming convention and stick to it. For example:
<type> (<specify-file-or-domain>) <comment>
Keep your branches up-to-date
More often than not, you’ll find it necessary to update the local version of the branch you are working on to stay in tune with the updates pushed to the remote branch by the members of your team. Before you go through with updates, we suggest you follow these steps:
- If one of your team members created a branch due to which it is not available for you locally, enter git fetch
- Navigate to the branch with git checkout your-branch-name
- If you made any changes to the files, do git commit or git stash (this option stores your changes so you can apply them again in later stages of development)
Now you are ready to update your local version of the branch with the latest changes. Using rebase command will put your commits on top of those on the remote branch:
git pull — rebase origin your-branch-name
In case you run into merge conflicts during the rebase, resolve them and continue as follows:
git add .
git rebase — continue
Use SourceTree (git GUI tool, easier to read commits that are conflicted in rebase step), a free tool to download
You can always abort your pull rebase action with the following command:
git rebase — abort
Once the process is finished, your commits will be listed on top of the commits made on the remote branch.
git stash – stash your changes
git stash pop – pop last stash changes
Your branch is now up to date with the remote branch along with your changes on top.
Keep your feature branch up-to-date with staging
During your work on a feature branch, it would be wise to keep it up to date with the staging branch if:
- You wish to make a pull request (PR) of your feature branch in order to merge it into staging, with all the recent changes from staging included, while avoiding merge conflicts
- You wish to include an update from the staging and continue working on the feature branch with no blocking issues
To do so, you need to follow this command line:
git checkout your-branch-name
git checkout staging
git checkout your-branch-name
git rebase staging
git push origin your-branch-name
In case you have previously pushed your branch to the remote repository, you’ll have to force push your changes since the history of the branch changed during the rebase process with the staging branch. However, you need to communicate with your team before you do so. In case someone else made changes to this branch in the meanwhile, doing a force push will overwrite them.
git push -f origin your-branch-name
Merge your feature branch into the staging branch
Using a pull request (PR) will allow you to merge all the changes made on your feature branch into the staging branch of the project. Once the branches are merged, you are free to delete the feature branch both locally and remotely.
While you have the option to do a merger without a pull request, evoking a pull request enables other members of your team to review your work on GitLab and other platforms. So, to follow the best practices of our guide on how to use Git in a team, once you’ve finished your work, push everything to your remote repository, open a pull request on GitLab, and discuss and review everything with your team. Once you conclude that everything is in perfect order, you can either merge your pull request directly from your GitLab interface or do it on the command line as follows:
git checkout staging
git merge –no-ff your-branch-name
git push origin staging
Your feature branch is now merged into the staging branch. Great job!
Final thoughts
Here is where we conclude our guide on how to use Git in a team. We hope that these lines helped you navigate the collaboration process with ease and establish a workflow for projects to come. For more news on the hottest topics in web development, or in case you are curious why we prefer custom-coded websites over themes and builders, check out our blog pages. Also, if there is any way we can help you level up your business, feel free to schedule a call.
