GIT: Using Git to Sync Workspaces for VSCode, Eclipse or Whatever

Motivation – Why Should I think about this?

This article assumes that you have skill to work with Git.
Its purpose is not a Git’s tutorial but a direction for an another usage for versioning control.

Every developer uses to customize the workspaces of Eclipse, VSCode, etc.
As much as you work, more customized it gets.
Very painful and time-consuming when we need to switch machines or even work on a different one.
Unless you register all extensions(VSCode), plugins(Eclipse) in a document to make sure that you’ll be able to recover or original configuration, you’ll depend upon memory, that is not reliable, because most of the time are numerous and we don’t handle them daily, so very probably the configuration is lost or partially recovered.

There is an alternative using Git, or another versioning control.
It is simple, fast and you no more is required to take note of your configurations.

 

How To

The example will be shown using VSCode, but the same apply for any other workspace that has an external path (not internal to the software).

VSCode, by default, saves your configuration here:

C:\Users\yourLogin\.vscode

Create a local git repository here.

C:\Users\yourLogin\.vscode\.git

Also attach to a remote repository.
An alternative is GiHub, using the private mode.

The Trick: the “forward administration approach”

If you try to use git as usual, it will not work.
You’ll get mad with the conflicts when merge is done.
It doesn’t work.
The tip and trick is to use a “forward administration approach”.

How does it work?
Rule of thumb, you’ll never ever merge.
Due to this golden rule, you’ll never perform changes in more than one environment at the same time.
It is easy since it is personal stuff, therefore there is just one user: yourself.

The strategy follows below:

1. Elect an environment as the current reference.
2. Create a new branch from the current reference each time you need to get a copy to begin working on a new environment.
3. If you don’t install things, the current reference remains the same.
4. If you have changed the common configuration (not local) or installed a new extension, the current environment becomes the reference.
5. When you switch machines or environment, create a new branch from the last current environment.
6. Delete old local and remote old branches to save disk space.
7. If something goes wrong, you have prior branches that may restore a previous state and you don’t loose everything, just the last things since the commit for that branche.

This is how I create my branches.
The “n6w10” is the hostname of a machine, so it is n7w10.
I use date by hostname. Easier to track.

 

Note

Take care when using console commands via cmd.exe.
Sometimes, depending on your machine configuration, if having administrator status, may cause some malfunction like when you issue the command “git branch -r”, comes nothing.
If you use scripts, sometimes it may loose the session and the registry ssh file, so when you do a push keeps asking to accept encryption key. No problem, accept it and it will work fine, or open a new prompt.

Such issues are not deterrent.