CODEWITHSUNDEEP
gitversion-control
Schilcote
Schilcote

Reputation: 2394

When and how to branch Git, when making major alteration to structure of program

I'm working on a video game that does a large amount of procedural content generation.

Right now, I'm transitioning from a model of "generate everything before the game starts" to a "generate things when I need them, then remember it for later". Since the generated data already takes twenty seconds to generate 100 entities when it will at release time need to generate three hundred billion, and is not nearly as complex as it will be when the program is feature-complete, the latter approach seems to be the only way to proceed.

I use Git for version control, and I'm very new at using it. Since this will obviously be a major change in the structure of the program, and since I'd like to be able to review/copy from the old monolithic code when writing the distributed generation algorithms, I'm thinking it would be wise to create a new branch to contain the reworked code, then somehow "merge" that branch back into the master when done.

Can this be done, is it a good idea, and how would I go about it?

Upvotes: 1

Views: 52

Answers (2)

Brian Lewis
Brian Lewis

Reputation: 5729

I would read up on branching here: http://gitref.org/branching/

What you are proposing makes sense and should be fairly trivial.

To list your branches:

git branch

To create a branch:

git branch foo

To merge that branch into the current branch:

git merge foo

To switch to a different branch, just check it out:

git checkout bar

Upvotes: 1

Aaron Digulla
Aaron Digulla

Reputation: 328624

Modern version control becomes more simple to understand when you think of it as a filesystem.

In this scenario, a branch is a copy of the source into a new folder. Afterwards, you can modify each without influencing the other. You can use tools to compare the two folders. You can delete one folder or create a new copy of one of them (for a total of three).

In the filesystem scenario, you often make a copy (or backup) before a big change so you can a) easily go back, b) continue to work on the original until the new feature has matured and c) you can compare old and new (answering questions like: Okay, I did change this completely ... how did that work originally?)

So yes, it's a good idea, Git has lots of support for this (the technical term is "feature branch"). Martin Fowler gives a good introduction.

Upvotes: 0

Related Questions