I would bundle things up into commits more than branches. Branches are usually more for features. Say for example you want to add your camera controls, that could be a branch while you figure that out. In that branch maybe there's a commit for getting the camera to move. Then another one to add zooming. Perhaps another one where you tidied things up. At that point you can merge back into your development branch. If you branch too much you'll give yourself a hard time. I'd suggest reading up on branching strategies and seeing which one works best for your workflow.
You are way over complicating your branch strategy. As a single dev, just work off the dev branch. There is nothing stopping you from having multiple commits to it. It gives you the history and offsiite backup you need.
I agree with this. Personally, I only branch out if I'm about to make something I'm not sure it's gonna work, or something that will require a lot of changes. So that if it ends up not working, I can just discard the branch. I also never work on master or other branches when I'm working on a branch, as I like to avoid merge conflicts like the plague.
Yep, this. The further from Trunk that your branches go, the worse off you are, and if there's only one developer working in a Repo then there is precisely zero reason to ever create more than one branch for 95% of your normal workflow, with all the industry metrics pointing to those extra branches causing you nothing but hassle and slowing you down for no little good reason. The better idea is comment each checkin to Dev semanticly - "Major/Minor/Bug : Feature Title : Description", you can then see every checkin, what you did and why in one simple action. This also forces you to think in terms of "one checkin, one feature", which will also force you to finish stuff, keep things small, etc, etc. glhf :)
I think this is a preference thing, and learning how to deal with merging and conflicts earlier is going to be much simpler. As long as it doesn't induce a rage quit, and if it helps in feeling out a new process, I'd argue that merging feature branches is simpler. For me, I'm not making a bunch of branches for little things in one day (those would be commits), but I might make a few broken branches trying to figure out a new system.
@@skarutsExactly this. I've only ever branched off to make major changes that may not work. If I like the changes, and they work the way I'd like, I merge it back into the main branch. Otherwise, I just keep it separate and archive the branch.
RUclips's hard to keep up, I know from my brief experiments with it. I'm sure he's just swamped with his day job y'all. He will return when he's able. And I will watch it lol :)
I think I agree with the advice from some of the other commenters. Branches are good for situations where you want to experiment without messing up your main work, but most of the time when I'm developing something by myself I just commit to the main branch. The benefit of doing this is it's less restrictive. A lot the time when I'm developing, I don't actually work on a single feature to completion and move on to the next one in a linear fashion. I build up my project incrementally, sprinkling some enhancements here, and some fixes there. If you follow a strict branching scheme for each improvement, it might make things feel a bit awkward. You also might have situations where one branch is dependent on some code in another branch, (the player branch might depend on the "enemy" branch or "projectile" branch, or vice-versa) meaning you'll have to merge one onto the other in order to continue your work. Additionally, if you're not careful you could end up with merge conflicts if two branches have irreconcilable differences. It's not the devil some people make it out to be, but it is annoying. Godot's conflicts aren't that bad though since it's project files are mostly plain text. On a separate note, I want to point out that pull requests exist for collaborators to discuss changes before merging. Unless you need to check-in with yourself on your changes, this won't be necessary. You should be able to merge directly onto main through GitHub Desktop and as soon as you push, GitHub should update accordingly.
The main problems branches solve are about multiple developers accidentally stepping onto each other. For example if Sally introduces a bug that crashes the application on startup, John would be the butt of it. These problems don't exist when you're working alone. I hope that helps!
looks like you're off to a good start, the crazy merging stuff comes later on, but you'll know what you did when you get there, and compared to a few of the other engines, I've had less headaches with Godot and Git one thing to be aware of, Git tries to read all the non-text files as binary, depending on your graphics this may never matter at all, but at some point (in GB, depending on storage budget), I like to have git ignore a whole folder with all that stuff in it (to keep the repo smaller), then when I have a mostly working build, like a release candidate, I'll go ahead and zip up all the textures and stuff and set it aside in case I have a bug or something later and the graphics/sound/whatever have changed in the future dev version
This is a similar workflow as I have for my job, I would just say do not delete branches, you never know when having a old feature branch hanging around will come in clutch
If you're gonna work on multiple branches at the same time, and you're gonna make changes within the same file in both branches, then when you want to merge the second 1 back, you will probably get a merge conflict. So be sure to only use the text files, like tscn, and others (which start with a t in godot), and get familiar with understanding these a bit. so that when a merge conflict occurs, you know how to combine both versions in the correct way.
I personally only work off the main branch, considering I work alone. and commit like 1 time a day. The work I do can be various features all in 1 commit. of course, this makes it harder to track it, but I don't see much benefit in this. from the commit I can usually figure out what I've done, and this is certainly useful if you've made a weird bug. Sometimes I commit when I'm rone with a sub part, but I frequently have forgotten something, and do more commits, with a message like oops, or something. If you want to go back to an already pushed version, you can, it's just a bit difficult. I usually do a git reset --hard. ( but I'm sure there are safer options) When you have a live version, then you want to work with branches, just so you can fully work 1 thing out, before merging it back to main. But for your own little project, I usually don't bother with it. At work we do use branches per feature, as it's in a team, with reviewers and such. and there are seperate issues.
Whats painful are merge conflicts. If you jump between branches or work in a team, they will pop up. I always think "Yes... I'm sure I did everything right. There is no way something is going to break." and lo and behold nothing works. Btw is there a way to write you links to useful game dev resources? The last time I wrote a comment about a useful color palette website it was automatically removed.
If you get very proficient with git - to the point where "git rebase -i" or "cherry-pick" is a second nature to you - merge conflicts are no longer scary. At worst they can be messy, and you might need to look at the commits on that other branch to see what the author had in mind, but usually it happens all automatically, or can be easily resolved. Might be more difficult in case of a gui layout change (in a machine generated file) on both branches or both branches drastically changing the same function. But usually it's fine. But also, I don't use merge commits, I rebase everything instead. Both methods have pros and cons (like you can't/really shouldn't rebase a branch that has been shared already... though again, a dev proficient in git would be able to handle it).
Whether you have problems with git depends on two things, whether you have learned to use it correctly and understand how it works, and what tools you use, because, for example, I love using git and it works prefectively for me until Unity is involved. Fortunately, I don't have to use this engine's $h*ty editor lately.
Try to include your motivation for making a change in your commit title and description. In six months time, you will thank yourself when you scratch your head and wonder why the hell your player character has a capsule collision shape and not a rectangle.
Hey Lewis , hope you’re well. Miss the updates on your progress. Keep it up!
I would bundle things up into commits more than branches. Branches are usually more for features. Say for example you want to add your camera controls, that could be a branch while you figure that out. In that branch maybe there's a commit for getting the camera to move. Then another one to add zooming. Perhaps another one where you tidied things up. At that point you can merge back into your development branch.
If you branch too much you'll give yourself a hard time. I'd suggest reading up on branching strategies and seeing which one works best for your workflow.
You are way over complicating your branch strategy. As a single dev, just work off the dev branch. There is nothing stopping you from having multiple commits to it. It gives you the history and offsiite backup you need.
I agree with this. Personally, I only branch out if I'm about to make something I'm not sure it's gonna work, or something that will require a lot of changes. So that if it ends up not working, I can just discard the branch. I also never work on master or other branches when I'm working on a branch, as I like to avoid merge conflicts like the plague.
Yep, this. The further from Trunk that your branches go, the worse off you are, and if there's only one developer working in a Repo then there is precisely zero reason to ever create more than one branch for 95% of your normal workflow, with all the industry metrics pointing to those extra branches causing you nothing but hassle and slowing you down for no little good reason. The better idea is comment each checkin to Dev semanticly - "Major/Minor/Bug : Feature Title : Description", you can then see every checkin, what you did and why in one simple action. This also forces you to think in terms of "one checkin, one feature", which will also force you to finish stuff, keep things small, etc, etc. glhf :)
I think this is a preference thing, and learning how to deal with merging and conflicts earlier is going to be much simpler. As long as it doesn't induce a rage quit, and if it helps in feeling out a new process, I'd argue that merging feature branches is simpler. For me, I'm not making a bunch of branches for little things in one day (those would be commits), but I might make a few broken branches trying to figure out a new system.
@@skarutsExactly this.
I've only ever branched off to make major changes that may not work.
If I like the changes, and they work the way I'd like, I merge it back into the main branch. Otherwise, I just keep it separate and archive the branch.
RUclips's hard to keep up, I know from my brief experiments with it. I'm sure he's just swamped with his day job y'all. He will return when he's able. And I will watch it lol :)
I think I agree with the advice from some of the other commenters. Branches are good for situations where you want to experiment without messing up your main work, but most of the time when I'm developing something by myself I just commit to the main branch. The benefit of doing this is it's less restrictive. A lot the time when I'm developing, I don't actually work on a single feature to completion and move on to the next one in a linear fashion. I build up my project incrementally, sprinkling some enhancements here, and some fixes there. If you follow a strict branching scheme for each improvement, it might make things feel a bit awkward. You also might have situations where one branch is dependent on some code in another branch, (the player branch might depend on the "enemy" branch or "projectile" branch, or vice-versa) meaning you'll have to merge one onto the other in order to continue your work. Additionally, if you're not careful you could end up with merge conflicts if two branches have irreconcilable differences. It's not the devil some people make it out to be, but it is annoying. Godot's conflicts aren't that bad though since it's project files are mostly plain text.
On a separate note, I want to point out that pull requests exist for collaborators to discuss changes before merging. Unless you need to check-in with yourself on your changes, this won't be necessary. You should be able to merge directly onto main through GitHub Desktop and as soon as you push, GitHub should update accordingly.
The main problems branches solve are about multiple developers accidentally stepping onto each other. For example if Sally introduces a bug that crashes the application on startup, John would be the butt of it. These problems don't exist when you're working alone.
I hope that helps!
looks like you're off to a good start, the crazy merging stuff comes later on, but you'll know what you did when you get there, and compared to a few of the other engines, I've had less headaches with Godot and Git
one thing to be aware of, Git tries to read all the non-text files as binary, depending on your graphics this may never matter at all, but at some point (in GB, depending on storage budget), I like to have git ignore a whole folder with all that stuff in it (to keep the repo smaller), then when I have a mostly working build, like a release candidate, I'll go ahead and zip up all the textures and stuff and set it aside in case I have a bug or something later and the graphics/sound/whatever have changed in the future dev version
This is a similar workflow as I have for my job, I would just say do not delete branches, you never know when having a old feature branch hanging around will come in clutch
One of these days I'll give it a shot lol, it was nice to see that it's not as complicated as the horror stories make it out to be.
If you're gonna work on multiple branches at the same time, and you're gonna make changes within the same file in both branches, then when you want to merge the second 1 back, you will probably get a merge conflict. So be sure to only use the text files, like tscn, and others (which start with a t in godot), and get familiar with understanding these a bit. so that when a merge conflict occurs, you know how to combine both versions in the correct way.
I personally only work off the main branch, considering I work alone. and commit like 1 time a day.
The work I do can be various features all in 1 commit. of course, this makes it harder to track it, but I don't see much benefit in this.
from the commit I can usually figure out what I've done, and this is certainly useful if you've made a weird bug.
Sometimes I commit when I'm rone with a sub part, but I frequently have forgotten something, and do more commits, with a message like oops, or something.
If you want to go back to an already pushed version, you can, it's just a bit difficult. I usually do a git reset --hard. ( but I'm sure there are safer options)
When you have a live version, then you want to work with branches, just so you can fully work 1 thing out, before merging it back to main. But for your own little project, I usually don't bother with it.
At work we do use branches per feature, as it's in a team, with reviewers and such. and there are seperate issues.
Whats painful are merge conflicts. If you jump between branches or work in a team, they will pop up. I always think "Yes... I'm sure I did everything right. There is no way something is going to break." and lo and behold nothing works. Btw is there a way to write you links to useful game dev resources? The last time I wrote a comment about a useful color palette website it was automatically removed.
And good luck when the dependency you need is in another branch forked at different points in time. Keep it simple.
If you get very proficient with git - to the point where "git rebase -i" or "cherry-pick" is a second nature to you - merge conflicts are no longer scary. At worst they can be messy, and you might need to look at the commits on that other branch to see what the author had in mind, but usually it happens all automatically, or can be easily resolved. Might be more difficult in case of a gui layout change (in a machine generated file) on both branches or both branches drastically changing the same function. But usually it's fine.
But also, I don't use merge commits, I rebase everything instead. Both methods have pros and cons (like you can't/really shouldn't rebase a branch that has been shared already... though again, a dev proficient in git would be able to handle it).
Whether you have problems with git depends on two things, whether you have learned to use it correctly and understand how it works, and what tools you use, because, for example, I love using git and it works prefectively for me until Unity is involved.
Fortunately, I don't have to use this engine's $h*ty editor lately.
Try to include your motivation for making a change in your commit title and description. In six months time, you will thank yourself when you scratch your head and wonder why the hell your player character has a capsule collision shape and not a rectangle.
great advice and helpful for me thank you!