0

I thought it would be possible in git to create a tree like this:

         ----b1
        /
---master
        \
         ----b2

First, I created a branch b1 using git checkout -b b1. Then made some changes there. They were left uncommitted. Then I switched to master branch using git checkout master. From where, I thought I would be creating branch b2 and work there. But checking out to master brought all the uncommitted changes from b1 with it. How can avoid this?

Sourav Kannantha B
  • 2,860
  • 1
  • 11
  • 35
  • 1
    Commit your work on b1 before switching branches. – Romain Valeri Oct 18 '21 at 09:38
  • Uncommitted changes do not belong to any branch. You could consider using `git stash`, or personally, I prefer `git worktree` when creating and working on branches simultaneously. – Richard Smith Oct 18 '21 at 10:00
  • Huh. Can't I do it without committing? Something such that it holds its state, and in future when I checkout back again, it restores its state. – Sourav Kannantha B Oct 18 '21 at 10:00
  • @RichardSmith Thanks. But, if I stash in one branch and then again stash in another, will those collide? – Sourav Kannantha B Oct 18 '21 at 10:03
  • 1
    Subsequent `git stash` invocations are pushed onto a stack, which can be listed using `git stash list`. From the list, you can see which branch you were working on when you made the stash. – Richard Smith Oct 18 '21 at 10:14
  • here is a similar question: https://stackoverflow.com/questions/2048470/git-working-on-two-branches-simultaneously – Nano Oct 18 '21 at 10:17
  • 1
    @SouravKannanthaB A commit is not forever. Commit on your branch, then when you later come back to work more on this branch, undo the commit while keeping changes (`git reset HEAD^`). – Romain Valeri Oct 18 '21 at 10:23

1 Answers1

1

The answer is simple, as already noted in comments: you must commit.

Can't I do it without committing? Something such that it holds its state, and in future when I checkout back again, it restores its state.

That something—the thing which holds state and restores it later—is called a commit.

You can use git stash ... but it works by making commits.

You can use git worktree, which may be the correct answer to your particular desired work-flow. The mechanism that git worktree provides is to add an additional working tree to some existing Git repository. This additional working tree does not affect any existing working tree, but there is a strong constraint on each added working tree: it must be on its own branch, or use Git's detached-HEAD mode. This constraint is met by your own starting requirements, so it's not a problem, but it is worth mentioning.

Each added working tree holds its own state. However, a working tree is not in Git, and cannot be extracted later from another clone. Only the commits are in Git. So eventually you must commit: the added working tree merely allows you to put off running git commit.

As Romain Valeri notes in a comment, you can "reset" a commit away to get rid of it. Git doesn't actually discard the commit immediately: Git has a mechanism for recovering accidentally-deleted commits, vaguely similar to the "waste basket" icons on many desktops. But it will eventually go away, and because commits are generally quite cheap (in terms of disk space), you can just ignore this and let Git clean it up on its own later.

torek
  • 448,244
  • 59
  • 642
  • 775