I remember implementing git on my team. I think it was over 6 years ago. At that time, a successful branching git model of Vincent Driessen it was necessary to read if you wanted to learn how to work effectively with git. Since then, I have followed the "Git Flow" style. But, last year, I was influenced by many community developers and I started using git in different ways depending on the projects I was working on.
Before entering the different branching styles, it is important to remember that, although many Git clients consider slashes ("/") as directory separators, there are no folders or directories in the git specification. You'll see it implemented in many UI clients, but I've never found it on console clients or on websites like Github or GitLab.
That said, let's explore some ways to organize the branches, so you do not get lost in a sea of code.
Although Gitflow does not mention branch folders, many developers use "Feature Branches", "Hotfixes" and "Release Branches" and create folders accordingly.
So basically, a GitFlow organization would have these three folders:
- hotfix[es]/ corrections
Since there is no public document that talks about this, I have seen some working copies using those plural folders and others in singular.
I found myself adding two more folders to my Gitflow repositories:
- Documents: for branches related to markdowns or release documents.
- Task: for branches that are neither functionality nor corrections. For example, clean up scripts or refactories.
I saw a lot in many projects. The branch-push-merge-prune is the anti-folder method. I am not saying that chaos is a way of organizing the branches. People who use this method prefer their work copy to be clean. They would simply branch out, push, create a pull request and then delete the branch (either manually or through git fetch prune) as soon as the PR is merged.
I found myself using what I call a model-based ramification model on a big project where I completely lost myself in a sea of functionality and fixes. So I started creating branches based on its modules.
You could mix Gitflow with this module-based approach, something like "backoffice / billing / fixes / billing-values", but it could be too much.
I saw for the first time Meir using this approach and I loved it. It's great for projects like Puppeteer-sharp in which the roadmap is clear.
In a version-based repository, each branch is created within a "vX.X" folder. The interesting thing is that it is time based, so it is easier to find the branches and it is also very easy to delete old versions with this simple git command:
git branch | grep -e "vX.X /" | xargs git branch -D
Again, this could be combined with the Gitflow folders, but …
If the ticket numbers (tickets, numbers or anything else you call them) are part of your team's language using a ticket-based system that could be the perfect solution.
You can use a folder, such as "ticket / 242" or "problems / 242", or simply call it "242".
If none of these systems is for you, you can follow it The idea of Nick and implement an Emoji based system 🙂
Two final thoughts to close this post. First of all, if you work on a team where you normally checkout every other branch, e.g. for local tests, I would recommend sharing the style with your team.
And finally, clean your work copy often. This will help you quickly find your branches and even speed up your local repo.
Do not stop writing code!
Originally published on harkoded.com
dev.to is the place where software developers stay in the circuit and avoid career stagnation.
Registering (for free!) Is the first step.