The first thing you need to do is find out where your development directories are going to reside. For instance, on my PC, I put them on the root of the
C:\ drive in a directory called
C:/dev, but on my Mac, it's in the
Users/[username] directory. This is the same directory that is defaulted to when you open your terminal, as you can see here I have placed my
dev folder inside that directory.
Once you have figured out where this folder will reside on your machine, it doesn't matter what platform you are on, it's all just organization of files and folders from here. What I'm about to explain may seem trivial to some, also understand that I am not trying to enforce this as a best practice (although some developer communities like GoLang have a similar approach). I went years without a consistent approach to how I organize my projects and applications and at the very least this would have saved me a lot of time and grief over time. You can always tweak and make changes and rules as you need to, but the idea is that you are better off with at least some consistency at this level and if we are just talking about directory structure, there is not many rules that need to be followed.
Let's look at how I organize this dev directory, and
dev is just the name I used, you could call this whatever you want, some use
projects but I like dev because it seems a little more generic, and outside of the
src directory I can add directories like
sandbox and whatever fits into my development category. I have a few rules that I will state up front that I follow, especially in the
- all directories are lowercase
- all directories are kebab case (that I can control)
- there is a directory named
srccontains a directory for each git platform
- inside each git platform is only repo names
These rules are the most important for me because they define a convention for how my
src directory will be laid out and those rules define how I will create and name project folders, but I also like to extend this convention to all folders within the
dev directory if possible. There are some cases where I cannot follow these rules for instance, if I clone a repo that is not mine, but I try to set standards for my own projects or my teams projects. I have taken cues from the GoLang Code organization and workspace standards. This is one community that I tend to agree with although my naming conventions are my own.
This guide is just one that covers the very basics of "how are my projects stored in a directory hierarchy" and "how are those root level folders for each project (that become git repos in most cases) named". That's it.
dev/src directory you would see all of the different git-based repository hosting platforms that I store code in:
Let's take a deeper look into repos that come from my GitHub. If I were to
cd into my
dev/src/github/httpjunkie directory (notice folder names are all lower case), it would look very similar to what you would see on my GitHub account. These are all of the repos (public or private) that I have on my computer at the time. It does not have to be a full representation, I don't ever have every single repo from my GitHub on my machine at any given time, just those that I am actively working on or hav previously cloned.