ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I'm using git for my various home programming projects. I love the idea of version control and how much simpler it is to roll back to a previous version. I was going over advanced git commands and read about branching. I completely understand how that's useful if there's more than one person working on a project, but are there any benefits to branching if I'm the only person working on a project?
For example, I was writing some driver code for an input sensor. At a certain point, I wanted to move from interrupt-driven to a polling model. So before I went and started hacking away my working solution, I made a branch polling, and proceeded. Then, I could easily checkout the interrupt (well, main) branch if I needed a quick reference, or to actually use the project.
Although, that path leads you (hopefully) to having two finished versions of one working code base. At that point, you'd probably want to merge the second version back into main, under some separate directory.
Oh, ok. That makes sense. Especially the part about having access to the previously working version if you needed to use it while you were working on the other version. Is the reason for merging into another directory in order to preserve the old version?
Actually, I take that back -- maintaining separate versions of code in different directories is probably not good practice.
But yes, in my situation, I thought that there would be two distinct versions of a central file (driver.c) that could be useful, and wanted them both to be in main (once they were both working.)
Outside of the git discussion, the better way to have achieved this would have been to have one mode "fall back" to the other, within the same code base. That is, if interrupts were determined not to be available, the same code should have provided for polling. So in this case, I would still have made the experimental branch. Later, when I'd tested it, I could merge it back to main, and the code in main would have a super-set of its previous functionality.
But so anyway, my point is that branching is useful to separate development code from code that is relatively stable, so that you -- and others -- can continue to use the main branch in "production" while other relevant development histories are being contributed.