如何在不同步本地/远程仓库的情况下推送到 github

Question

I've a git folder in my pc that contains directory called work. Each 10mn a file will be generated and added to work directory.

I need to push to github the new file generated in my work dir each 10mn then my automation script will remove it from my local work dir.

The problem is I'll only get the last file on my github each 10mn and not all of them.

what i want is:

#at t=10
file1 added to work git directory.
push it to github 
delete it from work dir

#at t=20
file2 added to work git directory.
push it to github 
delete it from work dir

#at t=30
file3 added to work git directory.
push it to github 
delete it from work dir


then i'll have test1, test2 and test3 on github (this is what i want, but i get only file3 now or the last push file).

The file add & deletion works perfectly and done with my automation script. My only problem is the one i mentioned above.

Answer 1

Git does not work with files—not the way you're thinking, that is. Git does not even work with folders full of files , although this is closer. The issue here is that Git works with commits . The git push operation pushes some commits . Your repository on your local PC stores commits and your (separate) repository over on GitHub stores commits . So you must think in terms of commits, not files.

Each commit acts like an archive of all files . That is, given some commit—they're numbered—you ask Git to extract that commit, and Git gets the full archive of every file as stored in that commit.

If you make a commit on Tuesday, and that commit contains files f1 , f2 , and f3 , then Tuesday's commit contains files f1 , f2 , and f3 . It contains those files, in the form they had when you made the commit . It contains exactly those files forever .

If you make a different commit on Wednesday, and that commit contains files f3 , f4 , and f5 (but not f1 or f2 ), that commit contains those files, in that form, forever . It never contains f1 and f2 .

The commits act as snapshots , holding every file, frozen in time. That's the #1 most important point of any version control system: it lets you "go back in time" and see what all your files looked like on Wednesday. These files are literally frozen: you can't write to them, and not even Git can write to them. To save space—among other reasons—Git stores them in a special format where only Git can read them too: they're compressed and, importantly, de-duplicated so that if Wednesday's files include all of Tuesday's files, they don't take any extra space for the duplicates.

Now, obviously, to get any work done, you can't use a frozen-in-time set of files. So that's not how you do work with Git. Instead, you tell Git: extract a commit so that I have usable, read-able, write-able files . You pick the commit—usually the latest and greatest of course—and Git extracts all those files.

You should not remove files unless you want the next commit to explicitly lack those files. Git will store the next commit's re-used copies of today's files without taking any space, if they're all duplicates. Removing files won't save any space because they're stored forever in the old commits.

So that's what's going on here: you're making each commit as an archive of one file, omitting all the previous files. Extracting the latest archive gets you just that one file. If that's not what you want, stop doing that.