The main advantage of Vagrant in my opinion is to allow each developer to use the native resources of their environment during development (e.g., text editor, IDE, etc.) execution environment (Runtime) is identical for all of them - and identical (as far as possible) to that used in production.
The first step, as you have already noticed, is to install and run a virtual machine. But which one? Now, the one that is more like the environment in which the system will actually execute. If it is a client-server architecture, the virtual machine must use the same operating system as the server, have the same packages installed on the server (and the same version), etc. If it is a multi-systemplatform, which needs to run in several different environments, so you would create a distinct virtual machine for each of them (without needing to keep all in operation at the same time, of course).
Once set the virtual machine(s) (s) to be used, and how it will be set up (it is possible to pre-install a set of dependencies, or create a startup script for each virtual machine to be run during its creation)this should be made available to each developer of your team so that everyone works in an identical environment.
The last step is to map a host environment folder set (i.e. your computer) to a host environment folder set (i.e. the virtual machine). This allows you to edit files, make modeling, etc using your preferred tools (which may be different from those of your colleagues), but when compiling and running everything is done within the virtual environment. Thus, when executing, the differences between computers have their impact minimized, being restricted only to performance (i.e. the ability of the host system to emulate the host system).
Nothing prevents you from Compile/execute also on your own computer, of course, if it offers a compatible environment. The important thing is that you never make it available ("do the check-in") files that have been tested only on your machine. Instead, before putting your modifications in version control you should open each virtual machine (if there is only one, best leave it open direct) and test the system on it, so as to ensure that what works in one environment does not cause bugs in another.
Thanks for the explanations. But the main point is there... this I already knew, until then. I want to really understand how I can use this, because so far I have seen it being used in command line, ie I have not seen an advantage, examples: nodejs npm Bower leave these examples because I see a "use" in them, but so far what I understood from Vagrant is, download, install, and start, but for what? , and how to use? , how to serve me? , I have not understood his logic so far
– vinibudd
@vinibudd Please edit your question then specifying exactly what you want to know. The way you are now, it seemed to me your doubt was as to purpose of Vagrant (which I believe my answer has already explained in brief).
– mgibsonbr