I am new to git and am currently trying to learn as much as I can about it.
I think the concept of it is fantastic and extremely valuable to any developer's workflow.
I am a data scientist who programs in R, and due to the nature of my work, I work on several projects simultaneously for several people/departments.
I find that I often need to switch back and forth between said projects due to ad-hoc queries / people losing things / people urgently needing to know something, and as such it got me thinking what the best practice is around switching branches.
What lead me to ask this question was that I am finding (especially recently) that I tend to modify several files from several projects in a short amount of time (sometimes in 30 minutes I can modify files from six different projects), and then when I go to switch branches to work on something that I had scheduled to work on, I am presented with the problem of either stashing or committing my changes to the current branch before being allowed to switch.
The problem is that I only wish to commit some of those changes (usually just a single file) to the specific branch that I am currently working on, but of course I can't switch branches without either stashing - or discarding - my changes first.
As such, I want to know if it is good/best practice to immediately commit new changes on their respective branches as soon as I have finished with them and then switch back to my
other-work branch immediately afterwards, or whether there is another way that typically works best for the majority of people.
My question is this: should I switch branches each time I am finished with a project / set of changes, even if I change just a single file, or should I be doing something else?
For example, if I am working on
ProjectX and then somebody asks me to do something for them on
ProjectY, should I switch from
project-y-branch, make the changes, commit them and switch back to
project-x-branch and continue or is there a better way to handle such scenarios?
The idea I have in mind is so that when I check my working copy, there are only one or two files to commit to the branch that I am working on as opposed to several that aren't related to my current branch.
I appreciate that stashing is designed for this very purpose (at least I think that's what it is for - please correct me if I am wrong) but nevertheless I feel that it is better practice to (ideally) avoid stashing altogether.
I fully expect that committing and switching branches each time I am finished on an update/modification is a very simple and useful habit to adopt, but before I begin implementing said habit, I would really like to know if there might be a better way to handle this.
I have checked the potential duplicate of this question and it doesn't quite seem like the same problem because mine is not a case of experiencing bugs, but more a case of having to randomly change code from one or two projects (where I don't necessarily need to keep the changes) as they don't add value. The changes are small, such as extracting some other piece of information instead of / in addition to what they were already extracting.
I am new to git...Also, when I set this repo up some time ago (on the recommendation of a colleague) I had a single project in there; since then I have added several others and have only started working with git in the last two weeks. I considered creating new repos for each project and this is something that I may adopt soon. Nevertheless, this doesn't directly relate to my question; even if I did have different repos, I still want to know if it is best practice to commit changes to
project-x-branchbefore switching to
project-y-branchor to stash first.