Tips to manage your git repositories like a pro

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.

1. GitFlow's the lit flow:

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.

2. The branch name is important:

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

3. Only merge to develop or master using Pull Request:

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 develop and master branch to anyone other than the project owner or admin and only accept merges to those branches by doing a Pull Request.

4. Keep your branches updated:

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.

5. Small and descriptive commits:

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 "[e-mail]"

6. Code review is important:

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 develop.

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 ;)