I have my current programming projects saved on GitHub, however, I have everything under just one branch: master.
I do not quite understand how to work with branches. Git help doesn't actually help me, there's no useful informations on GitHub as well. What I'd really like is simple explanation on how to work with branches.
Here's the thing: I work with Discord bot development. The thing is there are number of different parts: commands, event functions, main skeleton of the bot, translations, etc. All those different parts are somehow linked to the skeleton, and have also same common files (repetitive functions for example). I need all those parts being available at the same time as I need to test the Discord bot straight away, I need to have possibly no conflicts between those branches, and of course I need the branches to not influence each other (meaning that changing files while changing brach checkout is unacceptable). Can I work with that somehow?
I've experimented a little bit with branches, but it seems too difficult for me, too complicated. So I deleted all branches (except for master), and also deleted GitLocalize repository linked to one of the branches, since I guess that won't work because the branch doesn't exist
Can someone please guide me through Git branches?
Re: Can someone please guide me through Git branches?
Branches are basically different paths the development of your code can go in. The most commonly used way is to create branches for implementing different features into your application and then merging the changes done in each branch back into one main branch.
So for example, we create a mod for Quake 3. We first check in the Quake 3 SDK code into Git under the master branch. If you would start implementing feature A and I would be implementing feature B, we both would create our own branch (copies of the master branch at a certain point in time) and you'd develop in your branch and I'd develop in my branch. Once you're done with development, you merge your changes back to the master branch and delete the feature branch.
For really small, one person projects, using branches is often not really necessary. It's just a great way to keep things apart that shouldn't intermix (or not yet). For example, we have a version 1.0 release of our mod and I start rewriting some essential part of the mod. However, we also planned a version 1.1 release which only fixes bugs found in 1.0. I would do development for my rewrite in a separate branch while you could continue fixing bugs in the master branch. That way, the master branch can be released as version 1.1 without having to wait for the rewrite to be done. Once the rewrite is done, I can merge my changes back to master and we can release the 1.2 version which does include my rewrite.
So for example, we create a mod for Quake 3. We first check in the Quake 3 SDK code into Git under the master branch. If you would start implementing feature A and I would be implementing feature B, we both would create our own branch (copies of the master branch at a certain point in time) and you'd develop in your branch and I'd develop in my branch. Once you're done with development, you merge your changes back to the master branch and delete the feature branch.
For really small, one person projects, using branches is often not really necessary. It's just a great way to keep things apart that shouldn't intermix (or not yet). For example, we have a version 1.0 release of our mod and I start rewriting some essential part of the mod. However, we also planned a version 1.1 release which only fixes bugs found in 1.0. I would do development for my rewrite in a separate branch while you could continue fixing bugs in the master branch. That way, the master branch can be released as version 1.1 without having to wait for the rewrite to be done. Once the rewrite is done, I can merge my changes back to master and we can release the 1.2 version which does include my rewrite.