#Is This a Good Use of VCS Branching and Merging?

1 messages · Page 1 of 1 (latest)

coarse elbow
#

I'm getting ready to release a new demo for my game next month and am working on some final features ahead of time. I'm currently trying to implement a leaderboard system using the gamejolt API as well as perform bug fixes in the main portion of the game.

My game is using git version control but I'll admit my experience with branching and merging is very limited (my knowledge on the subject is lacking so I usually avoid it out of fear, lol), but I was reading some articles about git branches and realized the scenario I'm in right now might be the perfect situation for it.

I was thinking about making a "leaderboard" brnach so that I can begin testing all of the leaderboard functionality and then also making a "bugfix" branch so that I can work on bug fixes in a separate environement at the same time. Once I've completed the goals of both branches, I can then merge them with my main branch.

I wasn't sure if this would be a correct usage of git branching and wanted to check with other developers to be sure.

reef raft
#

Sounds good to me.

#

But "bugfix" is too general imo.

#

It's better if you group together some similar bugs and make a branch for them.

coarse elbow
#

Okay. I'm trying my best to keep the parts of the game I touch separate but when merging is there any chance changes from separate branches might not play nice together?

#

So for example, if I fix a bug in a file in the bugfix branch but then edit that same file in my leaderboard branch, could that cause some kind of conflict?

reef raft
#

Yes.

#

That needs to be resolved manually.

#

Merge conflicts are not that big of a deal.

coarse elbow
#

Gotcha

ionic scaffold
#

ok a bit into common branching strategies -- there's something called "git workflows", there are several of them, and normally you follow one of those workflows to avoid any confusion through the entire team.

i will explain the feature branch workflow briefly for you, because that one is used most widely.

basically you never code in the main/master branch
first thing you do in a new repo is: create a branch called "dev" (or "develop", "development", whatever you prefer).

Here's how it works:

  • small things, that are not dangerous or have a very low chance to be cancelled/reverted are done directly in the "dev" branch
  • bigger things/stories/features are done in a feature branch. this means:
    • you create a new branch FROM DEV for a new feature (like "leaderboards") and develop the feature there
    • when you are finished and satisfied you MERGE the feature branch back to dev

repeat this for all features you do. this way you keep your dev branch save.

#

Next thing: "what is the master/main branch for, then?"
A common use for this is, that this is the "release" branch.
So, whenever you release a new version (i.e. push it to steam/itch/...), you merge your dev down to master and TAG it with the version number or you create a branch from master after merge that is named like the version number.

especially for bigger projects, where several versions are alive at the same time (like 50% of your customers still run v1.5, 30% are on 1.7 and only 20% already converted to your latest 2.0 release)
the benefit of this is: hotfixes!
Imagine you run into a critical bug in production on your 2.0 version, but your dev branch is already deep into the 2.1...

  • you then switch to your 2.0 branch, create a branch "hotfix" from there, fix the bug and then you merge the fix into 2.0, 1.7, 1.5 AND dev branches! (yes you can merge ANY branch into ANY other branch! thats the greatest feature of git!)
  • this way you can update historical versions and perform a rollout of... like version 1.5.1 and 1.7.1 and 2.0.1 without any clashes on the master, dev and any feature in development.

So, in compact form:

  • master is your release branch, you NEVER develop there - it contains the very latest version, ready for QA/Release
  • from master you branch into DEV and from there for each feature. Finished features are merged back into dev (and the feature branch is deleted)
  • to create a release:
    • merge DEV into master
    • TAG and branch master named like your version (i.e. "1.0")
    • This version branch is "frozen" - you NEVER code there, but you branch away for hotfixes
    • hotfixes are always merged into any version branch that it shall get PLUS master PLUS dev

that's it basically.
Hope that helps.

#

here's a taglist of my raptor repo, so you get the idea:

# 
--- gml-raptor branches ---
* dev
  main
  origin/HEAD -> origin/main
  origin/dev
  origin/main
--- gml-raptor tags ---
1.0
1.1
1.2
1.2.1
1.2.2
1.3
1.4
1.5
1.6
2.0
2.0.1
2.0.2
2.1
2.2
2.3
2.4
2.5
2.6
---finished---
coarse elbow
ionic scaffold
#

You're welcome. This is part of my teaching job, so I could take a bit of the text from my scriptum for my students. Hope it helps -- if you have any additional questions, just ask!

coarse elbow