How I Use Git for My Projects
A developer and cybersecurity expert talks about how he uses git for personal and professional projects, his preferred ways of using git, and some security concerns.
Join the DZone community and get the full member experience.Join For Free
So, I use git all the time for any work that I do. Sometimes these are papers, sometimes they're simple programming proofs-of-concept, sometimes they're Jupyter notebooks, but I still need to keep these things someplace where I can get to them, and I don't want to lose them.
And I still use branches, even in these simple projects where I'm the only contributor.
This is one of the primary purposes of any distributed version control system, right? Keeping code safe and available? Branching and tagging don't really contribute much to availability, but they sure contribute to safety, no matter how small the project. In these cases, I tag when I accomplish very specific things, and I branch when I'm going off into left field on something. And these uses directly contribute to both my naming conventions and my merging strategy.
I usually use Git and GitHub. From Git, I can create a branch from any arbitrary tag, and create a tag from a branch. I usually only tag from my mainline development branch (e.g. master), but I will branch from master and merge from experimental branches. I don't branch very much. This leads to a structure that's centered around the master branch, with other branches that diverge and terminate (or are deleted) and other branches that diverge and are then merged back into the master branch. The tags I create almost always terminate — I rarely create branches from tags on simple personal projects. I just don't really find the need.
This basic structure is surprisingly resilient. I've used it for personal projects as well as development projects with small teams. The use patterns differ, in that I create branches more frequently from tags when maintaining a team repository, but the basic structure remains. Most work occurs on the master branch, which is tagged at release, with experimental work kept on divergent branches to keep the product base relatively stable. And merging is distributed and trusted to the team.
There are specific cases where this doesn't work well, though. We'll talk about this next.
Opinions expressed by DZone contributors are their own.