Best practice? Branching versus copying to start new mod

[jabelar]

So I have a handful of mods I like to publish and I also like to publish them for a few versions of Minecraft. I also have created a "starter" mod that is already set up with a lot of the tricks and utility classes in the way I like to organize my mod.

 

Until now, when I wanted to start a new mod I wouldn't do any git branching but would rather do file copy of my starter mod and make it a new repository. For different versions of the mod I would do the same (file copy and new repository).

 

This works pretty well but doesn't take advantage of ability to merge and cherry pick fixes and features across mods and across versions of mods. If I want to update something in one of my mods I have to cut and paste.

 

So I feel that there is some benefit in doing proper branching and release management. In other words, I think what I should do is instead of copying my starter mod I should create a branch for each mod and then create a branch from that for each version of Minecraft. 

 

Is that recommended?

 

My hesitation is that I just tried doing that and found that the amount of modification between versions of Minecraft is often quite large. Like if 1.13 comes along with "the flattening" I'll probably have so much recoding to do that I'm not sure managing it as a branch gives me much advantage. In the past things like the addition of blockstates, or changes to capabilities, are similarly pretty big changes. And frankly managing branches and merges can be a bit of a hassle.

 

So any opinions on this? Is it better to simply hand-craft a repository for each mod/version or do you guys find proper code branching and release management the way to go?

 

(Of course even if I do each mod separately I still use git to manage the development along the way, so I'm not debating the overall use of git.)

[Draco18s]

4 minutes ago, jabelar said:

So I feel that there is some benefit in doing proper branching and release management. In other words, I think what I should do is instead of copying my starter mod I should create a branch for each mod and then create a branch from that for each version of Minecraft. 

 

Is that recommended?

Ew, no. Don't do that.

Branches are for things like maintaining the source for the same mod across multiple versions of Minecraft, not for unrelated projects.

[jabelar]

4 minutes ago, Draco18s said:

Ew, no. Don't do that.

Branches are for things like maintaining the source for the same mod across multiple versions of Minecraft, not for unrelated projects.

Well the reason I even contemplated it is that my starter mod contains all my mechanisms I like -- all registrations and things are all set up, etc. Of course copying the files gives me all that too.

 

But even for different versions, do you recommend using branches or copy? I found that the amount of change is so large that the commonality is barely worth it. Once you change all the registration mechanisms (like the move to registry events), change achievements to advancements, IEEP to capabilities, go through and fix all the SRG name changes, get rid of hacks that are now handled by proper new Forge mechanisms, and so forth, seems like I have to touch almost everything anyway.

[Draco18s]

Clone the project.

If you want your starter mod to be its own project and treat it like a library, then treat it like a library: make your other mods depend on it.

[jabelar]

6 minutes ago, Draco18s said:

Clone the project.

If you want your starter mod to be its own project and treat it like a library, then treat it like a library: make your other mods depend on it.

Library idea is good for my utility classes, I will look at setting it up that way. But mostly my starter mod is more like a template -- already has all the classes and packages organized the way I like so for a new mod I can just get right into coding the new stuff. So probably just copying makes the most sense.

[Draco18s]

Clone/Fork the repository, (re)name it to your new project, and don't worry about it.

(Forking will leave a reference back to the original, if that's important to you--either for wanting the link or being aware and doing it manually because you don't want the link)

Edited July 30, 2018 by Draco18s

[JaredBGreat]

This does not sound like a good way to handle totally separate mods.  I do do that for different version of the same mod (Doomlike Dungeons has branches for different Minecraft versions, several of which may have the same mod version).  But separate mods should be separate.

 

IMO, if you really want to have some kind of starter base it should be a separate thing from any of the mods (while I do sometime move small bits of code around, I would never have thought to make mods as you are describing).  But then.  None of what I've copied was big enough to warrant a library IMO, and I try to avoid extra utility mods since when downloading other people mods I don't like having tons of extra dependencies, but that could be a solution.

 

Draco's idea makes a certain amount of sense to me, but GitHub doesn't seem to offer forking for your own project (or they've hidden it) -- I don't think they intended it to be used that way.  Perhaps you could do it locally on the command line though.  I'd just keep that base separate for any kid of project -- but then, I'm just a self-taught programmer with no formal training on standard ways of doing things and probably a few weird habbits (the way I use branches is also a little different from the most common use).

[Draco18s]

Or you can copy and paste the files on your computer and declare it a new repository.

[JaredBGreat]

1 hour ago, Draco18s said:

Or you can copy and paste the files on your computer and declare it a new repository.

That's what I would do with some kind of base.

[Aeronica]

Check out how rwtema handles Extra-Utilities

 

Personally I've attempted to use SourceTree and Perforce P4Merge to help with migrating changes between versions of a mod I made on 1.12, 1.11, and 1.10. But due to both method and field name changes, vanilla and forge changes it's always very messy. McJty uses his custom library to deal with the version differences. The best you can do is isolate the unique things your mod provides as best you can and put the version dependent things elsewhere.

Edited July 31, 2018 by Aeronica

[IceMetalPunk]

I know what you mean in terms of a "starter mod"; I've gotten into the habit of using one common base for my mods and just starting each new project with that base. In my latest project (which I've lost... but that's another story), I ended up just making the starter into a library anyway. As a kind of "core library" that the other mods can rely on, with block/item bases and registrations set up how I like them.

But I agree with the other comments here: don't use version control to split up projects. It's meant for revisions, reversions, and a commit history, which doesn't make much sense for inter-project work (for instance, you should never want to revert a new project back to  a commit before the base). That also means you don't need all the projects' histories in your tree, either. So I'd say just keep it at one repo per project, branching for various features and fixes, and then (if you don't want to make the starter into a library) copying the starter files manually for new projects and initializing them as a new repo.