

gitignore (which will be hidden by default). These might be backup files that text editors create, compiled python files (.pyc) or even files with sensitive information in, such as passwords. There are many scenarios where you might end up with files in your repository that you don't want to place under source control. One useful command in this section is the "-amend" flag for git commit, which allows you to amend the previous commit, for example to fix a spelling mistake. Running git diff again should show no changes, as the file and repository are up to date. Since the file is already in the repository, we can use another shortcut to add it and commit it in one go: git commit -am"Added name to blah.txt" This should give output similar to the following:Īgain we need to add this file to the staging area and then commit it's changes. We can view the difference between that version of the file and the committed one (eg the changes) using the following command: git diff In your text editor of choice, add a line to blah.txt that says what your name is, and save the file. Let's make a change to the file so we can try out some other commands. You might sometimes need to refer to this! That's an unique ID, or SHA, for that particular commit. Note that long string of characters and numbers. Staging and committing can therefore be done in one go using the following syntax: git commit -m"First commit of currently blank text file"Īlso, running git log will give you a nicely formatted record of your changes: git log

Note that we can shorten these steps slightly using the -m flag to the git commit statement. Running git status again will tell you that your "working directory is clean", in other words you have no untracked files or uncommitted changes:
git diffYou can stage these changes by using git-add 1. In other words, the differences are what you could tell Git to further add to the index but you still haven’t. Once your commit message has been saved and you are back at your git command prompt, you will see a summary of the changes git has made. This form is to view the changes you made relative to the index (staging area for the next commit). The screenshot below shows an example using the nano editor on linux: This pops open your default text editor (depending on what you configured in your setup stage) and asks for a commit message. This human-readable explanation will go alongside Git's own record of the change and the file structure snapshot at that point.

We do this by recording a short message that explains what we did and why. The final stage is to commit the change we have made. If we re-run the git status command at this point the output has changed: So our next stage is to add our files to the staging area: git add blah.txt The output of this command not only tells you the stage of the files in your repository but also gives you some handy tips on what to do next. Git-status is used to understand what stage the files in a repository are at. Committed: the change has been committed.

#GIT STAGE ALL CHANGES CODE#
You can stage any chunk of code by using the Peek Difference user interface (UI). You can modify how Visual Studio interacts with code changes in the Peek Difference UI by using the Click to peek in margin option from Tools > Options > Text Editor > Advanced.įor example, you can change the default Single click setting to Double click, or you can select None to turn off the Peek Difference UI.
