gittortoisegitchangelist

Using Git to separate code changes when working on more than one issue

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:

  1. How to separate my current set of changes, which comprise 18 files in total. Should I make two branches from the entire current state, Branch for Ticket #1 and Branch for Ticket #2, and then somehow remove #2's changes from branch #1 and visa-versa?

  2. For new situations where I already have some code changes for just one ticket and I must start work on a different ticket, what steps should I take so that I can still easily go back and forth between the two and ideally see all changes combined? Would it go like this? Create a branch for the current ticket's changes; create a new branch off of master for the second ticket's changes and switch between them as I switch work?

Solution

  • 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.

    1. I would do it like this:

      1. Assume that you are on the branch master
      2. create a branch for Ticket#1, git checkout -b ticket1
      3. Stage the changes that belong to that ticket git add file1
      4. git commit
      5. Switch back to master git checkout master (the file modifications regarding Ticket#2 are preserved)
      6. create a branch for Ticket#2, git checkout -b ticket2
      7. Stage the changes that belong to that ticket git add file2
      8. git commit
      9. Now you can freely switch between the tickets using git checkout ticket1

    2. Yes. In git it is safe, easy and fast to switch branches. So it totally makes sense to switch between branches for different tasks.