Finally it is included in the next commit when you use the git commit command.Then the file is added to the staging area using the git add command.The working directory is like a work bench it is where you edit your files, add new files and delete files. It is edited in your working directory.The journey a file takes to have an updated version of it added to your repository: (This is a common misconception, people may think in their mental model that the file is moved but actually it is copied.) What the git add command actually does is copy that version of your file from your working directory to the staging area. Note that you can copy versions of files into the staging area and also take them out of the staging area before you make your commit which is why I referred to it as a rough draft space. The staging area is like a rough draft space, it's where you can git add the version of a file or multiple files that you want to save in your next commit (in other words in the next version of your project). Again, if you use git gui, whatever's on the bottom left pane gets committed, so just make sure only that change gets there and commit, then push! With git, you can quickly make and commit only that change, without committing all the other stuff you're still working on. The usual recommendation is to do this on a separate branch, but let's say this fix is really just a line or two, and can be tested just as easily without affecting your current work. Staging helps you sneak in small changes - Let's say you're in the middle of a somewhat large-ish change and you are told about a very important bug that needs to be fixed asap. In git, all you have to do is never to stage that file or that change. This may be some test data, a log file or trace file, or a temporary shell script to automate some test. Of course you have to discuss with your team and work out a more permanent solution, but right now, you need that change in your working tree to do any work at all! Another situation could be that you want a new local file that is temporary, and you don't want to bother with the ignore mechanism. For example, perhaps you upgraded your build environment and it now requires an extra flag or option for compatibility, but if you commit the change to the Makefile, the other developers will have a problem. However, sometimes you want a local change to a file that cannot be excluded (which is not good practice but can happen sometimes). Staging helps you keep extra local files hanging around - Usually, files that should not be committed go into. Again, this lets you concentrate on the stuff that needs your attention - the merge conflicts. Only changes that did not merge cleanly (i.e., caused a conflict) will show up when you do a git diff, or in the top left pane of git gui. Staging helps when a merge has conflicts - When a merge happens, changes that merge cleanly are updated both in the staging area as well as in your work tree.
Just that change (not the entire file) is now staged in fact, if there are other, unstaged, changes in that same file, you'll find that the file now appears on both top and bottom left panes! In the right pane of git gui, right click on a change that you approve of and choose "stage hunk". Even better, you can even stage partial changes to a file. It's two left panes show unstaged and staged changes respectively, and you can move files between those two panes (stage/unstage) just by clicking on the icon to the left of the filename. If you stage each change as you review it, you'll find that you can concentrate better on the changes that are not yet staged. Before you commit, you'll probably review the whole change by using git diff. Staging helps in reviewing changes - Staging helps you "check off" individual changes as you review a complex commit, and to concentrate on the stuff that has not yet passed your review.
Really works well with git gui if you're into that too, or you can use git add -p or, with newer gits, git add -e. With the index, just stage each set of changes and commit until no more changes are pending.
DICEBOX WITH STAGING CODE
Now the change is all tested and working, you need to commit all this properly, in several clean commits each focused on one aspect of the code changes. (And you're smart enough not to make the whole thing on honking big commit!). You didn't actually commit any of these - you were "in the zone", as they say, and you didn't want to think about splitting up the commits the right way just then. Staging helps you split up one large change into multiple commits - Let's say you worked on a large-ish change, involving a lot of files and quite a few different subtasks.
0 kommentar(er)
