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. Continue reading “Integration of Git and Visual Studio – Commit variations”→
In previous blog post, we learned how to create a git repository and commit first using Visual Studio and then achieve the equivalent of same using the native git commands. In this blog post, we’ll learn how to see the specifics of commit or how git stores this information.
Let’s analyze commit made by using Visual Studio, using the project ConsoleApp02. If we navigate to the project directory and do a git log, we’ll see below output:
I recently came across few blogs discussions where the question was whether you should be using some kind of UI tool for git or live with the command line git and which one is better. I won’t go much into the debate of which one is better, but I can say that you should know what you are doing. Each UI based implementation of git takes away all those commands and command line interface, it provides a nice usable interface to its users. However command line git can be very very powerful if you know what you are doing and you do need to have that kind of control sometime. So we need to understand what is happening behind-the-scenes.
In previous blog post, we learned how to do baby steps for implementing IaaC. We learned how to use ARM templates, Git and Visual Studio to code your subnets in the Azure. Now, there is no doubt that Git has taken over the world for source code management. And while it is good for managing versions of source code, those versions and details are confined to your local machine. If someday your local machine goes kaput, its all in water. For that, you need to sync your changes to a centralized source code management system. Also having centralized source code management allows more than one person to work on the same repository.
Infrastructure as code and configuration as code both fall into the category of configuration management, and both relate to defining or scripting for environments.
Infrastructure as code is more specifically defined as:
Defining your environments to include networks, servers, and other compute resources as a text file (script or definition) that is checked into version control and used as the base source for creating or updating those environments. For instance, adding a new server should be done by editing a text file and running the release pipeline, not by remoting into the environment and spinning one up manually.
Git (for Windows) – Git is a powerful distributed Source Code Management tool. If you just want to use Git to do your version control in Windows, you will need to download Git for Windows. You can choose to jump through several urls to find and download the right version or you can use the easier way. I’m going to explain the latter in this blog. For this post, you need to have Chocolatey installed on the machine. You can check here on how to do so.