-3

We cannot switch branches in Git without committing the changes or stashing them. What is the bigger picture behind this and why did Linus take this approach while designing Git?

If switching branches cause local changes showing up across branches, What is the point in branches as they are expected work in isolation ?

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
nehem
  • 12,775
  • 6
  • 58
  • 84
  • You *can* switch branches without first committing: see http://stackoverflow.com/q/22053757/1256452. But: why do you claim that branches "are expected to work in isolation" in the first place? See also http://stackoverflow.com/q/25068543/1256452 – torek Jan 13 '17 at 02:04
  • I agree with @torek. I'd like to understand what you mean by "work in isolation". – siride Jan 13 '17 at 02:07
  • Ever used Pythons virtual envs? Branches can be thought the same until you deliberately want to merge them. – nehem Jan 13 '17 at 02:12
  • @itsneo: a branch is simply a tracking of a history of changes, of which there can be many separate histories side by side. It is not an entire environment. You should read more about the fundamental model of Git and perhaps it'll make more sense. – siride Jan 13 '17 at 05:08
  • @siride I hear you and understand the what it is, but the question is revolving more on WHY. – nehem Jan 13 '17 at 05:26
  • @itsneo: you mean why did they design Git that way? That's not really a question I can answer. I can answer that *if* you understand how branches and objects and heads work under the hood, it'll be clear why branches don't do what you think they do. As to why that was designed, I literally cannot answer that. – siride Jan 13 '17 at 15:33

1 Answers1

-2

We cannot switch branches in Git without committing the changes or stashing them.

Actually you can force switching branch, but then you lose any uncommitted changes on current branch. It should be very unusual if you want to lose your current work just to switching branch. Why not commit it first to current branch, or at least stash the changes so you can come back?

Anyway to force switching branch, you can:

1)

git checkout -f <new_branch>  // will lose any uncommitted changes on <old_branch>

or,

2) 

git reset --hard <commit-hash-id-of-new-branch>  // will lose any uncommitted changes on <old_branch>
artm
  • 17,291
  • 6
  • 38
  • 54
  • The question is not to learn about how to switch, Instead to understand the design between such a reality :( – nehem Jan 13 '17 at 02:01
  • 1
    If you switch branches, you do not lose uncommitted changes. They stay there and Git attemps to apply them to the new branch, potentially resulting in a conflict. – siride Jan 13 '17 at 02:06
  • @siride even without `stash` ? – artm Jan 13 '17 at 02:08
  • @siride: Normally if there would be a conflict, Git simply refuses the `git checkout`. You can use `-f` as @artm suggests to overwrite, or `-m` to request that Git attempt to merge the files. – torek Jan 13 '17 at 02:08
  • That's the worst part, why would git apply changes? It's like merging just switching branche, that's not what the user will usually intend for. – nehem Jan 13 '17 at 02:10
  • 1
    @itsneo not sure what design you are asking about. It's common to any version control that you save/commit your work before changing branch – artm Jan 13 '17 at 02:12
  • Imagine a scenario I'm working on 1 project in 2 features and 2 bugs and another buddies cherry picked bug. My list of branches grow up quickly as git encourages branching often but switching between branches I need to remember the stashes of each(whether I did or not). I don't want to commit something until something is worth committing. – nehem Jan 13 '17 at 02:17
  • @siride you said "do not lose uncommitted changes" - does that work without `stash`?? – artm Jan 13 '17 at 02:35