git-index

To use git effectively (and as intended) I make small atomic commits, while I do have longer sessions where I do change not only one thing. Thus, I make heavy use of git add -p . This doesn't work for completely new files, though, because I tend to forget them later on. What I want to do is, tell git that there is a new file, I want it to track, but not stage it : Example: Running git status produces: # On branch my-current-branch # Your branch is ahead of 'origin/my-current-branch' by 2 commits. # # Changes to be committed: # <<STAGED SECTION>> // A # # Changes not staged for commit: # (use

I have a fuzzy idea of what the git index contains as one does git-add s and git-commit s, but I don't have a clue of what happens to these contents when one does a git-merge . I'm particularly interested in learning what the index holds when a merge fails (e.g. due to some conflict). For any given path, there are up to four "version numbers" in the index, numbered 0 (zero) through 3. I'll call them "slots" as if they were actually there for every entry, and then easily indexed (this makes them easier to think about), although actually extra versions are introduced dynamically only when needed

When I first started using Git, I found the checkout command quite confusing. However, as I adapted to Git's model of version control, it started to make sense. Now I am having to teach Git to my coworkers, and I'm trying to explain checkout simply. I thought I had a simple explanation (from the documentation ): Checkout a branch or paths to the working tree That seems to unify some of the things you can do with checkout which seem like a diverse set of operations to someone new to Git: git checkout . git checkout HEAD . git checkout HEAD~2 git checkout feature/update-readme README.md ..

Still having a hard time getting my head wrapped around the concept of staging as it applies to Git. Can any analogies be made with SVN? What is the primary purpose of having a stage level in Git? Similarities: Files that should be part of the repository must be added in order to being tracked. Both tools use the add command to accomplish this. Adding files means to prepare a commit. Differences: Git allows some further kind of detail when adding files. You can decide to add a whole file or distinct lines of code. Adding files to the index or stage allows more flexibility. SVN automatically

GitRef.org - Basic : git rm will remove entries from the staging area. This is a bit different from git reset HEAD which "unstages" files. By "unstage" I mean it reverts the staging area to what was there before we started modifying things. git rm on the other hand just kicks the file off the stage entirely, so that it's not included in the next commit snapshot, thereby effectively deleting it. By default, a git rm file will remove the file from the staging area entirely and also off your disk > (the working directory). To leave the file in the working directory, you can use git rm --cached .

This question already has an answer here: How do I undo the most recent local commits in Git? 80 answers How can I uncommit my last commit in git? Is it git reset --hard HEAD or git reset --hard HEAD^ ? Cascabel If you aren't totally sure what you mean by "uncommit" and don't know if you want to use git reset , please see " Revert to a previous Git commit ". If you're trying to understand git reset better, please see " Can you explain what "git reset" does in plain English? ". If you know you want to use git reset , it still depends what you mean by "uncommit". If all you want to do is undo

I was confused the naming of staging directory (Git Index) in Git. Is there any special meaning such that it is called Index? Why not just called Cache / or Temp directory so that we can understand more easily? To me, index is sth which help us to search things faster, like indexing in DBMS, how does it relate to the staging area??? I did some google search but still have no much idea. ref link Git Index The article by the main Git maintainer Junio C. Hamano , is instructive, for grasping the difference between cache and index: (emphasis mine) When Linus started writing git, his aim was to