For context: I am working as a sole developer on a single project. I recently migrated my SVN repo to Git and the first thing I miss when working with TortoiseGit vs. TortoiseSVN, is changelists, which, in TortoiseSVN, let you group locally-changed files and name those groups, yet still see a list of all changes that are uncommitted. I typically do this when I find myself working on more than one ticket (bug or feature) at the same time before I am ready to commit anything.
Realizing the the Git way of doing things is definitely different from the SVN way, perhaps I should be committing changes locally or even creating a separate branch for each ticket and switching between them? I am just a little apprehensive since SVN often didn't branch/switch/merge well whenever I did anything out of the ordinary, like renaming (or was it moving) a file. Also, it's nice to see all of my changed files in a single, grouped list, which changelists give me but I don't see any way to do that in Git.
If, in the case described above, the generally-accepted answer is to use a branch for each ticket, I would like some guidance on the steps for the following two scenarios, please:
In git both creating and merging branches is fast and easy. Branching one of the great strengths of git.
So, best practice is definetely creating a branch for each task you embark on. Even small tasks! That will make it easier to work in a structured way, and the version tree will be easy to understand afterwards.
I would do it like this:
git checkout -b ticket1
git add file1
git checkout master(the file modifications regarding Ticket#2 are preserved)
git checkout -b ticket2
git add file2
git checkout ticket1
Yes. In git it is safe, easy and fast to switch branches. So it totally makes sense to switch between branches for different tasks.