In previous blog post, we learned how to analyze a commit. We now will proceed to understand the various stages of commit and types of them as well.
As we all know, Git has 3 places for the code:
– Working tree: The place where we can add, modify source code.
– Staging area: The contents of modified files in the working tree are temporarily stored to a staging area called the “index” with git add. A file can be reverted back, only in the index but not in the working tree, to that of the last commit with git reset HEAD — , which effectively reverts git add and prevents the changes to this file from participating in the next commit.
– Local repository: git commit (without any pathname parameter) is used to record what has been staged so far in its most basic form.
Let’s explore more on the same. First, let’s add some code to our Visual Studio Solution. For this right click project, select add and then add new class:
Once its done, let’s save this file. If you look carefully at solution now, Class01.cs has[+] icon, which indicates the file is added but not tracked. ConsoleApp02 project has red check icon, which indicates tracked and modified:
If we open up and see the git status of repository using command, we’ll find below:
Sometime, changes made in Visual Studio would not be immediately reflected when using command line. So you might see some discrepancy like above. However, be sure its all still there.
Stage changes to code
As mentioned above, git add is required to add items to stage. For this, right click the project -> select source -> commit. This will take us to the changes pane:
This won’t commit the change but navigates you to Changes pane. We need to click on [+] icon shown below to commit our changes:
Once you click on the icon, the items would be shifted to staged changes section:
If we now see git status of repository using command, we’ll find below:
Commit changes to repository
Let’s commit changes by adding a commit message:
and observing status of repository using command:
As highlighted, we can see our new commit details. The same can also be viewed inside Visual Studio:
Adding commit without staging files
Instead of staging files after each individual change, you can tell git commit to notice the changes to the files whose contents are tracked in your working tree and do corresponding git add and git rm for you. This is the most common form of commit. When using native commands, this can be achieved by the git commit -a command. To understand this, let’s modify Class01.cs file by adding couple of variables:
Now, go to commit pane, enter commit comment and click “Commit All”:
This will perform equivalent git commit -a -m command. Do note that unlike native git commit -a behavior, if we add a new file, it will also commit the same.
To view this, let’s add a new file Class02.cs to our project:
Once its done, go to commit pane, enter commit comment and click “Commit All” again:
If we now, see git log, it would be as below and we can see that there is no indication of using git add to add file to tracking area first:
Performing selective commit
We can also add selective files to commit. For this, let’s add two classes namely Class03.cs and Class04.cs to the project. Now, let’s go to changes pane and see the files are listed:
Right click Class03.cs and select stage:
Make sure, Class03.cs is reflected in the staged area. Fill the commit message and then click commit staged:
This performs equivalent of git commit Class03.cs -m “Added Class03.cs”
Amend previous commits
The amend option is important when you forget to add some changes to previous commit. By using this you can add those changes as part of previous commit. The new commit has the same parents and author as the current one. Also, the message from the original commit is used as the starting point, instead of an empty message, when no other message is specified.
In our case, let’s modify previous commit to also include Class04.cs file. In the changes pane, click actions and from drop-down, select amend previous commit:
This will immediately issue git –amend command. This is where you might see some aberrant behavior in the git history inside Visual Studio and command line:
Once thing to note is that you see SHA1 hash value is different from previous commit. This is because commit object has been updated thus it becomes different object. Other than this, there is nothing to worry. If we look at file status, they are being tracked now. I hope this behavior of git history being shown wrong inside VS should get corrected soon.
Perform dry run for commits
This option is not available in Visual Studio as of now. It does not create a commit, but show a list of paths that are to be committed, paths with local changes that will be left uncommitted and paths that are untracked.
Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change followed by a blank line and then a more thorough description. In this post, we learned what operations can be performed when committing changes in Visual Studio.
One thought on “Integration of Git and Visual Studio – Commit variations”
[…] In previous post, we discussed on the commit variations. Basically, we discussed how to stage changes selectively or whole and then committing those changes. We also discussed how to amend previous commit as well and understanding its command line equivalent git commands. In this post, we are going to discuss about concept of branching in git and how it works. […]