0

Every time when I try push single file to new branch, git all files from folder. When I delete all files from repo using git rm --cached -r . and upload this single file one more time it's fine. But when i try upload some files to another new branch, it's push new files + files from last push.

I used this comands:

git init
git remote add origin master
git branch test
git checkout test
git add <file>
git commit -m "blahblah"
git push origin test

Of course in the meantime I used git status command to check current files, but it's show only <file> that I want. I don't know why it's push all files, not only <file>.

torek
  • 448,244
  • 59
  • 642
  • 775
tymeq
  • 49
  • 1
  • 2
  • 5
  • did you do git push -u origin test to push it to the remote? – Josh Adams Sep 21 '18 at 17:59
  • 1
    Are those the only commands you used? Because it looks like you didn't clone anything and you didn't fetch from the remote, so you won't see the files that already exist on the remote. The usual workflow is to clone a repository (which automatically sets your origin remote). Then locally you could delete all the files and commit that... – krsteeve Sep 21 '18 at 19:45

1 Answers1

1

Git does not push files. Git pushes whole commits.

A commit is a snapshot of the entire source tree: all the files. That's what git push transfers: one or more complete snapshots.

When you use git checkout branch, Git translates the branch name to a specific commit, and then extracts that entire commit—all of its files—into your work-tree. This is kind of the point of commits: they represent a set of files that all go together. Use file-set-A to do thing A on branch A; use different file-set-B to do thing B on branch B; and so on. If there is a bug in the set-of-files that is the current tip of some branch B, you extract the complete set, fix the bug, add the fixes, and run git commit to say: Now branch B means this new commit I just made—using all of these files. The new commit represents the new snapshot that does thing B.

Hence, git push pushes all the new snapshots that you made, that the other Git does not have already. They add the new snapshots to their collection of "all snapshots ever made".

Note that the opposite of push is fetch, not pull! This wrong-verb thing is due to a small mistake Git made early on, that we all have to live with now. Using git pull means run git fetch, then run git merge. That's an extra step that git push does not (and cannot) do. We fetch, then merge, then push; then we fetch, merge, and push again as necessary. The pull verb combines the two, but it turns out there's often something to do between those two actions, or instead of using merge. When there isn't—when it's OK to fetch-and-immediately-merge—then git pull is more convenient. But I advise learning them separately at first.

For much more about this, once you're ready, see What does GIT PUSH do exactly?

torek
  • 448,244
  • 59
  • 642
  • 775
  • *"A commit is a snapshot of the entire source tree: all the files"* AFAIK a commit is a snapshot of the file changes (changeset), like a delta. Isn't that right? – everton Sep 22 '18 at 04:50
  • 1
    @everton: No, Git differs here from other VCSes. Each commit is independent of previous commits, in terms of saved files. Each commit does list its parent commits, and by comparing the saved snapshot in the commit to that in each parent, we can *compute* the changeset, but the commit *is* a snapshot. (Exercise: what's the difference between storing a chain of deltas, one after another, and storing snapshots, one after another, in terms of usefulness? What is the boundary condition where this matters?) – torek Sep 22 '18 at 04:59