I'm very new to git and I wanted to try and understand a bit more about how github displays branches online.

I created a repo with about 50 files.

I cloned that repo locally, I created a new branch, added a single file with no other changes. I then pushed the changes up. So far so good.

However, when I go into github and switch to the branch, I see my new file, but I also see, the other 50 files, which I have not changed.

Does that make sense? i.e is github showing a full view of master branch?

I was only expecting to see the file I added when I switched to that branch.

Now when I created the branch from the repo, I didn't remove the files I wasn't working on, I left them and added a new one. Would that be the right flow? Or should I have removed the files so the above doesn't happen?

Any help would be appreciated.

Thanks.

CodePudding user response：

This isn't really about how Github displays the repository, or even how git works, but about what the purpose of version control is.

Let's go through your description, and make it a bit less abstract:

I created a repo with about 50 files.

In the real world, those 50 files mean something. Generally, they are 50 files of source code for some application, and you need all of them to make the application work as intended.

I cloned that repo locally, I created a new branch, added a single file with no other changes. I then pushed the changes up. So far so good.

A branch is a way of tracking a particular change to the application. So, your new file might be some new feature of the application - maybe it's a new level for a game. Often, changes will actually be much smaller than this - you might fix a bug by editing one line in one of the existing 50 files.

However, when I go into github and switch to the branch, I see my new file, but I also see, the other 50 files, which I have not changed.

A branch containing just your new level wouldn't be very useful - without the rest of the game, the level doesn't do anything. So the branch has to contain the whole application, including the new file. It would make even less sense for a branch to contain just one line which you'd changed.

Does that make sense? i.e is github showing a full view of master branch?

No, Github is showing what the source code the application looks like after that change, which is 51 files. If you'd deleted one of the original 50 files, it would show the branch as containing 49 files. You could delete the master branch completely, and your other branch would still contain all 51 files.

I was only expecting to see the file I added when I switched to that branch.

If you want to view the changes made for a particular task, you need to compare two branches - any two branches you want, since all are versions of the same application. In your case, if you compare master with your new branch, you will see one added file. If you had instead changed one line, the difference viewer will show the specific line you changed.

Now when I created the branch from the repo, I didn't remove the files I wasn't working on, I left them and added a new one. Would that be the right flow? Or should I have removed the files so the above doesn't happen?

If the 50 files were needed for your application to function, you don't want to delete them, or your application won't function. Deleting a file is a change you want to track in version control like any other - to use my example from earlier, you might remove a level that is too difficult to complete.

Hopefully thinking about it in a real-life scenario like this makes what happened a bit clearer. There is a lot more complexity to how git in particular models history, but before you can begin to look at that, you need to understand the basic aim of version control.

CodePudding user response：

What you could use is git filter-branch command. This commands allow you to apply filters to your branches.

As an example you could filter just one subdirectory into your branch with this command:

git filter-branch --subdirectory-filter foodir -- --all

Be very careful with this command since it has a plethora of pitfalls that can produce non-obvious manglings of the intended history rewrite.

CodePudding user response：

You wrote, "I'm very new to git..."

Welcome to Git! This is a common misconception at first about what creating a branch means. There are likely an infinite number of ways to explain this, and here are 2 of them:

When you "create a new branch" you aren't planting a new tree. You are simply preparing to add new commits to an existing tree and naming them something so it's easier to find them later.

Or,

When you "create a new branch" you are actually creating a bookmark or pointer to a specific commit. For example, if you are on branch main and issue the command: git branch my-new-branch you will then have two branches that point to the same commit. At this moment they will have the identical contents when you switch between them, until you make new commits on one of those branches.

Note that with the command git reset you can change which commit a branch name points to. So branches are basically just a convenience so you don't have to remember long commit ID hashes.