Git is one of the most used tools for every programmer because it lets you store your code and version it, not only for your development team but also with a lot of developers that can (and probably will) improve your code or add documentation to it if the repository is public, and not do any change without your permission. So, I'll give you some pro tips to manage your git repository like a boss.
GitFlow is a git workflow (maybe a little too obvious, right?) that defines a strict branching model designed for project publishing and it's perfect when you're working with at least one more developer.
This can be done by installing
git-flow and starting the project with
git flow init that's just a wrapper for
git init and adding GitFlow, or, you can do it a little more casual and work it your own way but following the rules without using the GitFlow wrapper.
Gitflow is based primarily on two branches: develop that's the development branch where should have all the code that's not in production yet, and master that should have the code currently in production. Also, it provides tags to manage your branches that work as a folder system and will help you and your team to know what everyone is doing and what has to be done next. These are the tags and a little explanation about it:
- feature: This is for new things that will be added to new versions. This will be merged directly DEVELOP branch
- bugfix: This is for old things that don't work as expected on the actual version and will be added to newer versions. This will be merged directly DEVELOP branch
- hotfix: This is for old things that don't work as expected on the actual version and will be added to that version. This is for bugs that break the production version or an important flow of it and it's needed to be fixed for the app to work. This will merge directly to MASTER.
- release: This is to have the code for every release to easy access if it's needed a hotfix without having to do a cherry-pick of a specific commit.
The way to use these tags are:
git branch -b feature/your-branch-name
That will create your branch
your-branch-name as a new feature for the app without actually modifying the development branch to avoid conflicts between teams.
Try to keep your branch's name to describe what you're working on to help your teammates know what they have to review when they check your code.
git branch -b feature/add-button-action
If you're working with JIRA/SCRUMWISE/TRELLO or whatever software for task management, you should use the name of the ticket with the ticket code as your branch name.
Let's imagine that we need to fix something broken for the next app release, the ticket code is
APP-100 and the ticket name is
Fix buy button, then your branch name should be:
git branch -b bugfix/APP-100-fix-buy-button
Or even we have a release for the app, then the branch name should be:
git branch -b release/1.0.0
It's important to do Pull Requests instead of pushing directly to develop to avoid conflicts with other team members.
A good practice it's to block the
master branch to anyone other than the project owner or admin and only accept merges to those branches by doing a Pull Request.
To do this, at end of the day, do a rebase/merge from the
develop branch, it will keep your branch up to date and will decrease merge conflicts between the development team.
First, let's talk about what "small commits" means. This refers to don't do a single commit for a huge change on different files. For example, if you have 3 things to do: Fixing a typo in
file1, Adding a new feature to
file2, and fixing a wrong formula on
file3, you should make three commits, one for every fix to keep your git tree clean and descriptive, and if someone needs to cherry-pick something on a single commit, can see where they need to do it.
And, for the second part, always use a message to your commits that describe really what you're doing, this will also help your team to identify what's going on on the whole branch and make the git tree clean and easy to read. Following the same example, our commit message should be something like this:
git commit -m "Fixing typo on sample text for file1" // ... git commit -m "Adding sample feature for file2" // ... git commit -m "Fixing sample formula for file3"
Also, another thing important is to set the git configuration to add your name and your email to identify who did what. We can configure this using:
git config user.name "YOUR FIRST AND LAST NAME" git config user.email "YOUREMAIL@mail.com"
If a lot of people are working on the same code it's important to check what they do, if they're doing it right, if it's working properly and it's following the best practices to avoid making the project messy. If not, comment on the lines you think are not ok and request changes before merging branches to
Do you have other tips to improve your repository management? Leave it in the comments below.
I do this completely non-profit, but if you want to help me you can go here and buy me a coffee ;)