Git: How do I know if my open file is master or in a branch

Question

Lets say I have a local repo with a.sql file. I currently have the.sql file open on my laptop.

I now create a new branch. The.sql file is still open on my laptop.

If I make changes to the.sql file how do I know if they will be saved to the master branch or to the new-branch?

Thanks

Answer 1

Although the answer is written by @torek is in quite a detail. But to answer you quickly, I would say it depends on the conditions. Let us see those.

1. You are on the develop branch and .sql file open, you did not make any change to .sql file or any file under git invigilation and you created another branch out of develop .

   Well, in that case, you will switch to the new branch and all the new commits will go into your new branch.

2. You are on the develop branch and .sql file open, you made changes to one or more than one file(s) (which may include your .sql file) under git invigilation staying on the develop branch and you created another branch out of develop .

   Well, in that case, while switching you will get error from git asking you to either commit your temporary changes or git stash those. You do any of these two, and then you are again free to move to your new branch. The new commits will be counted under your new branch.

NOTE: My explanation is just to make you understand the things in layman terms. Git works slightly differently when you deep dive into it. :)

Answer 2

Files are, in a very important technical sense, not in any branch, in Git. In other words, you're asking the wrong question. You should be asking: Which commit(s), if any, contain this file? You can then refine the question to which commits contain exactly this version of this file or which commits have modified this file, as compared to their parent commit and so on.

(I suspect that one of these answers right now is that no commit contains that file, or that version of that file, but you have not given us enough to go on here, for me to be sure.)

The way Git works is a bit sneaky:

• Git repositories store commits , not files. Of course, each commit stores some files, so it's safe to say that Git stores files, right? Well, sort-of-right, but this will lead you down the garden path . Try to think of commits as a sort of unit. They're the unit-of-storage that you will work with, when you work with Git.

• The word branch itself is tricky: see What exactly do we mean by "branch"?

• The end result of all of this is that given a branch name like master , we have to first find one specific commit . Then we can decide whether some version of some file is in that specific commit, or not.

• In any case, the files that are inside commits are all completely, totally, 100% read-only. They're stored in a special format that only Git understands, and they're de-duplicated, because every commit stores a full copy of every file! The de-duplication makes this OK.

When you're actively working with a repository, you start by doing:

git checkout master

or git checkout of some other branch name. ¹ This checkout operation copies the frozen-format Git-only files out of some commit, expanding them into ordinary everyday files.

These ordinary everyday files go into a work area where you can work on them. Git calls this work area your working tree or work-tree . ² The files you can see and work on/with are in this work-tree. The work-tree is not part of the repository proper! Changes you make here are only stored here.

Note that this work-tree is an ordinary set of files and folders, so all of your computer commands that work on such things, work on it. This means you can create files that aren't in Git at all because they exist only in your work-tree, not in any commit.

Git makes new commits, not from the files that are in your work-tree, but rather from files that are stored in Git's index . The index is a bit complicated and I won't go into any most of the details here, except to note that a git checkout fills in both Git's index and your work-tree from the commit you've selected. This doesn't disturb any work-tree files that Git knows nothing about. Again, such files aren't in Git . They just exist in your work-tree.

If a file is in a Git repository, it's stored inside a commit, in the special frozen Git-only format. Doing git checkout will extract that file, resulting in two more copies: one you can't see in Git's index, ready to go into the next commit, ³ and one that you can see and work on / with, in your work-tree. When you have changed your work-tree copy, the updated file won't go into a new commit until you copy it back into the index, replacing the old index copy: that's what git add is for.

Git uses the phrase untracked file to mean a file that is not currently in Git's index, but is in your work-tree . The git status command will show such files as untracked . ⁴

---

¹ In Git 2.23 or later, you can use git switch here. It does exactly the same thing—it's just been split out of git checkout as git checkout did at least two separate commands' worth of different jobs. In Git 2.23, git switch does one job and git restore does the other one, instead of cramming both into git checkout .

² In Git 2.5 or later, you can add extra work-trees with git worktree add . It's best to have Git 2.15 or later for this because of a pretty nasty bug that wasn't fixed until then. (The bug only manifests if you leave an added work-tree around for at least two weeks, so if you have an old Git and want to use git worktree add for a quick fix, that's fine, just don't let it sit around for too long.)

³ Technically, what's in the index isn't a literal copy of the file, but rather a file name , a mode , and an internal Git object ID . But this only shows up if you dig into the index entries, using internal Git commands like git ls-files --stage and git update-index .

⁴ To make git status shut up about these files, you can list them in .gitignore . Note that listing a tracked file—one that is in Git's index—in .gitignore has no effect, though.