Tips to manage your git repositories like a pro
Tags: git, tutorial, productivity
Published: 2020-12-14 02:34:40

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 "YOUREMAIL@mail.com"
```

###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](https://www.buymeacoffee.com/danielsilva) ;)