0

I have few questions as mentioned below scenario. Please suggest. Scenario 1: In Directory 1, I have File1, File2, File3. I have modified all three files. But I want to push only File1 and File3 to Git Repo. And leaving the changes in Files2 as it is but not pushing to Git Repo. How can I do this ? Regards RG

Rama Sarma
  • 11
  • 3
  • https://stackoverflow.com/a/5506483/3852949 – Storm Dec 24 '19 at 08:37
  • for that you need to add, commit and push only the files that you want. The normal git command sequence but adding only the changes you want to push. Command sequence would be: git add , git add , git commit -m "your changes explain message", git push -u origin. You can also try a UI where git becomes more visual and user friendly than the console. I would recommend sourcetree. – rustyBucketBay Dec 24 '19 at 08:46
  • Before I jump into UI, I wanted to understand gitbash. Evn after using "git push -u origin" I am still able to see Changes not stagged for commit. Any other workaround please. TIA. – Rama Sarma Dec 24 '19 at 09:03
  • you should see the File2 change in the git status not staged for commit, because you dont want to push that change according to your question. – rustyBucketBay Dec 24 '19 at 09:34

1 Answers1

1

Git does not push files. Git pushes commits. It's true that commits contain files, but you either get the whole commit, or none of it.

Every commit represents a complete snapshot of all files. But Git does not make new commits from what is in your work-tree. Your work-tree (or working tree) is the area where you can work with your files, hence its name. These files have their everyday form on the computer.

When working with Git, however, there are, at all times, three active copies1 of each file. The first copy is the one in the commit you are working with right now. That first copy cannot be changed, just as nothing about any existing commit can ever be changed. The third copy is the one in your work-tree, which you can work on/with: it can be changed. The interesting one in this case is the one in the middle, between the current commit and the work-tree. This middle copy can be replaced using git add.

This middle copy (see footnote 1 again) is in what Git calls, variously, the index, the staging area, or (rarely these days) the cache. It starts out matching the commit. When you git checkout some particular commit, Git:

  • copies all the files from the commit into the index (again, see footnote 1), and
  • copies all the files from the index into your work-tree so that you can see and work with them.

As you make changes in your work-tree, nothing happens to the copies in the index. Eventually, you must run git add on your updated work-tree files. This command copies the work-tree file back into the index.

A good (but incomplete) short description of the index is that it contains your proposed next commit. Using git add to copy files from your work-tree into the index updates your proposed next commit.

When you run git commit, Git takes a new snapshot of all of the files that are in your index at that time. That includes all the unchanged ones that were copied into your index when you checked out the commit, plus any updated and/or new ones (and minus any removed ones) that you updated with git add.

The new snapshot, made from what is in your index right then and there—i.e., from your proposed commit—now becomes your current commit. Now your current commit and your index match, once again, as usual.

Any files that are in your work-tree that you changed, but did not git add, remain unchanged in your work-tree.

You can now git push the new commit(s). If the other Git to which you will be git pushing accepts them, that Git now has the new commit(s). Those new commit(s) have the snapshots that you made. Nothing and no one can ever change anything in those snapshots—not you, nor your Git, nor anyone else. Each commit is uniquely identified by its hash ID. That hash ID, created when you (or whoever) made that commit, is forever reserved for that commit, and no other. But now that the other Git has those commits, by their hash IDs, any user of that other Git can git checkout one of those commits, by its hash ID or by whatever name(s) they may choose to use for those hash IDs: branch names, tag names, and so on.

Note that the way git status works is that it runs two comparisons:

  • First, it compares the copies of all of the files in the current (or HEAD) commit to the copies in the index. Wherever these are the same, git status says nothing. Wherever these are different, though, git status says staged for commit.

  • Then, git status compares all of the copies of all of the files in the index to all of the copies in the work-tree. Wherever these are the same, git status says nothing. Wherever these are different, though, git status says not staged for commit.

So, even though you can't see the index directly, you can tell a lot about it very quickly by using git status. Whenever git status is quiet, the index matches. Whenever git status is noisy, the index copy or copies of some file(s) differ(s) from the committed and/or work-tree copy or copies.

1Technically, the index contains a reference to an internal Git blob object for each file, rather than a literal copy of each file. Running git add on a file will create a new blob if needed, then put the appropriate reference into the index, rather than actually physically copying the file into the index. However, there's no way for you to tell the difference unless and until you start experimenting with git ls-files --stage and git update-index.

torek
  • 448,244
  • 59
  • 642
  • 775