How to push all folders to GitHub?

Question

I am trying to push a project to GitHub. The project has many folders. All folders is pushed except one folder.

My Project
|-- Folder 1
|||---Sub-Folder 1.1
|--Folder2
|||---Sub-Folder 2.1
|--Folder3
|||---Sub-Folder 3.1

All folders have contents and many files. Folder1 and Folder3 are pushed, but folder2 is not pushed to GitHub. What cause this problem? How could I push it to GitHub with the other folders?

I used this command to push to GitHub

git add .
git commit -m "Updatefiles "
git push origin branchName

Answer 1

First, you need to know a few things about Git:

• Git never pushes folders at all.

• Git does not push files either. What Git pushes—transfers from one Git repository to another—are commits. A commit holds files. While you can think of the files as being organized into folders (and Git will store them with names that imply folders), the commit holds only the files, not any of the folders themselves. That is, a particular commit might contain d1/fileA.ext, d1/fileB.ext, and d3/fileC.ext as its entire set of three files. Extracting that commit will produce two folders, d1 and d2, because your OS insists on having those two folders to hold the files: the files fileA.ext and fileB.ext go in d1 and the fileC.ext goes into d2. But as far as Git is concerned, there are only the three files in the commit: there's no d1 or d2 at all; they're just implied.¹

• Each commit that you do make stores—permanently² and in a read-only, compressed, and de-duplicated³ form—every file, almost as if you made a tar or zip archive.

Hence, to get a folder-full of files into Git, you must add those files to your proposed next commit, and then run git commit to make that proposed next commit become an actual commit.

When you run git checkout to pick out some existing commit, Git extracts all the files from that commit into a work area. It has to do this, because the stored files in the commit are in a read-only, Git-only, compressed and de-duplicated form. Only Git can read them, and literally nothing can write them. That makes them pretty useless for getting new work done. So Git extracts the committed files, turning them into regular ordinary everyday files, that all the programs on your computer can use.

You now use them, in this working area—the working tree—and you can create new files in this working area. Those new files, and even the extracted existing files, are not in Git. They are merely there in your working tree for you to work on/with.

Checking out some other commit, using some other branch name, will remove, from your working tree, those files that came out of Git earlier because of the other commit—those files are there because they came out of the commit you've been using, after all—and will replace them with the files that go with the commit you switching to. Files that are not and never were in Git at all, in your working tree, remain there, sitting there undisturbed. They weren't in Git, and still aren't.

Once you do add and commit the files, now those files are in Git. Switch to another commit that does not have the files and Git will remove the working tree copies. That's okay, because those files are now in Git, in that commit, stored forever (or as long as the commit continues to exist; see footnote 2). You can get them back, in that form, any time by checking out that commit. But of course, if you switch away from that commit to some other commit that doesn't have the files, they'll vanish from your working tree.

As per your comment, these files, in this other folder full of files, have not yet gotten into Git because you told Git: when these files are in my working tree, but aren't in Git, don't complain about them, and don't put them into Git by listing the entire folder in a .gitignore. If you remove this line from the .gitignore, and then git add the folder, that will add all the files in the folder (except any that are listed on other .gitignore lines anyway).

Be sure you really want to do this because once you do commit these files, they are in the new commit, and they remain in that commit forever. Switching to that commit, with git checkout or git switch, will extract those versions of those files from Git to your working tree. Subsequently switching away from that commit, to a commit that lacks the files, will remove those files from your working tree. You can get them back, of course, because they're in that commit, but in some cases this may be a hassle. So figure out why the entire folder-full of files was being ignored before. Was it a mistake? What led you to make this mistake? Or was it correct, and is making your future life annoying, by adding and committing these files, the mistake?

---

¹The effect of this restriction is that you cannot store an empty folder in Git in any convenient way (see How can I add a blank directory to a Git repository?). There's no really good reason for this restriction, but it's there.

²The files are tied permanently to that commit, so as long as that commit continues to exist, the files exist. It's not completely impossible to strip a commit from Git, but it's generally pretty difficult, so its best to think of these as "mostly permanent".

³The de-duplication means that once you have stored a file in a Git commit in the past, there is essentially no cost to storing it again. So the fact that most commits mostly re-use most of the files from previous commits is not a bad thing. It's a good thing; these re-used files take almost no space, and mean that checking out any historical commit, to see how the files were a year ago or whatever, is very quick.