Immutable File Patterns in vscode git: a blog to introduce patterns for file organization.
An immutable file is a file that never gets modified.
My experience using immutable files was limited to having the final version of a thesis or article in a version-controlled folder (the last version before it was published). It wasn’t until I read Jesse Kavadlo’s post on Immutable Files that I realized the power of this simple idea.
How it works
Immutability means not changing things after they are created. The benefit to keeping files immutable is that when you look at an old document, you can be sure that it will look and act the same as it did when you originally wrote it, which is not always the case if you use word processors.
There are several ways of creating immutability, but the simplest one is to just create a new document for each update and leave the old ones alone. This can be done by appending a date or number to the filename and copying over all of information from the previous document into the new one. In this way, you can always find what your document looked like on any given day without doing any more work than it takes to write your daily updates.
Immutable File Patterns in vscode git
In a previous blog, I discussed how to use the gitignore file to exclude specific files from being tracked by git. The purpose of this file is to exclude files that are not necessary or harmful to have in your repository. The .gitignore file should contain a list of file patterns that match the files that you do not want in your repo.
To help you organize your .gitignore patterns, I have created a github repo called vscode-gitignore. In it you will find a collection of .gitignore files for common programming languages and platforms. You can copy and paste the contents of these .gitignore files into your own project’s .gitignore file.
If you find any errors or omissions, please create an issue on github!
In version control systems like git, files are stored in a repository. The repository is stored in a directory that can be accessed by the user. In order to make this process efficient, users often use patterns to organize the files in their repository.
In vscode, there are three types of file patterns that are important. These are: glob patterns, gitignore patterns, and ignore patterns. Glob patterns include wild cards and support ** in paths to match any string of characters, including /. Gitignore patterns can be used to exclude files from commits and synchronization while ignore patterns can be used to exclude files from search results and outline view.
Git provides a convenient way of managing versions of files. By tracking and archiving all changes, it becomes a powerful tool to track the history of changes in files. In this blog post, I’ll introduce some patterns I use to organize and manage my code using vscode git.
1. Separate folders for different projects
2. Be consistent (folder name, file name, etc.)
3. Leave comments if necessary when committing**
The VSCode git extension has a feature that allows you to specify file patterns that you do not want to commit. The file patterns are given as glob patterns relative to your project directory.
To use this feature, add a section like the following to your vscode global settings (File > Preferences > Settings):
“git.ignoreLimitWarning”: true,
“git.confirmSync”: false,
“files.exclude”: {
“**/.classpath”: true,
“**/.project”: true,
“**/.settings”: true,
“**/.factorypath”: true,
“**/node_modules”: true,
“**/bower_components”: true // add this line if you use bower for frontend package management and don’t want to commit bower packages to git
},
My organization has started to use git for our version control. Previously, we had been using a homegrown solution that was a kind of a cross between Subversion and Git in that it allowed you to have branches, but only per file. That is, you could create branches of one file, which was useful for long-running development cycles, but not so useful for merging or collaborating.
Because some people used the existing system to track every single iteration of their work, we have received a lot of pushback from users about switching to git because they are afraid of losing that history. I think they are beginning to get over their initial resistance now that they can see how much better git is at merging than what we had previously. The biggest issue right now is the fact that we are writing code in an unstructured way. Everything is in one big folder with no real structure within it.
We want to change this and introduce subfolders, etc., but it is a daunting task to move all the files into different folders. It would be very easy if we were just starting out because then we could just create the correct folder structure and put the files in there as we went along, but retroactively trying to make sense of it all is pretty difficult.
I
When you work in a team, your files are stored in a remote repository. You can clone a copy of this repository on your machine and make changes to it. If you add and commit these changes, the files in your local repository will be different from those in the remote repository (unless you’re the only person working on that branch).
When you push your local changes back to the remote repository, git will try to merge them automatically with the latest version of that file. Let’s say that you’ve modified line 5 out of 100 lines in a remote file. You can tell git to add that change and commit it. When you push, git analyzes the difference between your local version and the remote version and updates all 100 lines in their entirety.
To learn more about how git works, check out our [blog](https://www.github.com/blog)