Reputation: 1
I created a file in master branch (I didn't add it, much less committed it). Then I created a branch and switched it and created a file with another name there (I didn't add or commit the file either). When I went to give an ls (dir) the file created when I was logged in the master was appearing in the branch that I created. Upon returning to master, the file I created in the branch was appearing in master. Only after I went to each branch did I add it and only after I committed each file to its specific branch did the file created in the master stay in the master and the one in the branch stayed in the branch. It wasn't enough to just add the file to its respective branch, I had to commit for it to separate. I thought this was kind of "Vegas", what I create on the branch, stays on the branch, but apparently I'll always have to add and commit for git to physically separate the files, right?
Is it possible to change this behavior of the routine so that everything I create while using a branch is only accessible in that branch without adding or at least committing before?
I think that during the development of a software I will want to change the content several times before making the first commit and the file that may not even make sense appear there in another branch, confusing when I want to check something in the other branch.
Upvotes: 0
Views: 45
Reputation: 51840
apparently I'll always have to add and commit for git to physically separate the files, right?
Yes. git
expects the user to take an explicit action to create commits.
This mainly helps in identifying what constitutes a suitable content to be committed, and also into writing a relevant commit message. I would strongly advise to follow this general practice, it is definitely a good habit to take and to make your repo useful.
Is it possible to change this behavior of the routine so that everything I create while using a branch is only accessible in that branch without adding or at least committing before?
There could be ways to do that, but again, I would advise you to follow the way git
was designed : create the commits yourself, so that you have a better view (a view at all, actually) of what's inside them.
git
will help you only if you store things in it -- in other words: if you create commits. The way the standard git commands are designed, this requires that you take a conscious action, to select the content you want to store (e.g: git add ...
) and commit (git commit
) with a message which hopefully will help you understand what's in it.
I still create quick commits with random messages such as "wip" or "blaaa" on occasions, and in my experience I always find myself saying "why did I do such a stupid thing ? what did I have in mind when I wrote this code ?" if these stay around for a few days.
I would rate the Time To Unusefulness (TTU) of such commits to ~ 5 days :)
I mentioned "what constitutes a suitable content to be committed" : be very liberal about it. git
will help you in backing up and restoring content only if you commit to it, so don't wait to have the perfect content before committing.
One first workflow is:
With a bit more experience you will find that git offers many ways to rewrite commits and shoot you in the foot to death get a more logical sequence of commits after the facts.
Upvotes: 1
Reputation: 30868
These files are untracked. They don't belong to a specific branch yet. Untracked files are in the working area (worktree). By default, a repository has only one worktree. When we switch branches, the current branch is checked out into the working area if there is no conflict. The branches share the same working area. Therefore, the untracked files are mixed together.
One of the possible solutions is to create a separate worktree for each branch. Worktrees share the same .git
. We can run git commands in each worktree. For example,
git worktree add /path/to/worktree foo # create a worktree for branch foo
git worktree remove /path/to/worktree # remove a worktree
git worktree list # list worktrees attached to the current repository
git worktree prune # prune worktree entries that have been removed by other means like "rm -rf /path/to/worktree"
Note that /path/to/worktree
should be out of any other existing repository. Git allows only one worktree for one branch, but we can create multiple worktrees for the same commit-ish (except a branch in short) if needed. You can add that file with different contents in each branch's worktree, and keep it untracked. Remember to back up untracked files when you are to remove a worktree or a repository.
Upvotes: 0