Replacing a flat tree with one that has meta information baked in.
When cloning projects you likely have some sort of "development" directory. That
is where most, if not all, resulting directories of git clone reside. You
might create a sub-directory for your employer. You might make one for your
personal projects.
After a while this becomes unweildy. You start doing "deep dives" of your own filesystem.
Some possible reasons you have a given sub-directory (aka project) in "development".
- You created it, a "source project".
- You want to contribute to someone else's work, a "forked project".
- Your employer created the project.
- You have some reason to compile the project from source.
- You needed to read the source. Maybe to help create a bug report. Maybe the documentation is 💩
These concerns quickly start overlapping with a traditional directory tree.
Make your folder stucture mimic the web.
- Make directories for domain names.
- Make directories for static pathnames.
- Use soft links for discoverability.
For me that means my "wotblitz.js" project lives at ~/dev/github.com/CodeMan99/wotblitz.js/
instead of ~/dev/wotblitz.js/. The clone of globby
lives at ~/dev/github.com/sindresorhus/globby/. If I were to fork the project I would change
to working directory ~/dev/github.com/CodeMan99/ and create a link called "globby".
ln -s ../sindresorhus/globby globby
Now if I list the contents of ~/dev/github.com/CodeMan99/ I see a source project named
"wotblitz.js" and a fork of "globby". By reading the link path I know that globby is mainted
by sindresorhus.
What about projects that live only on my computer? Simple! Your computer has a hostname, right?
mkdir -p ~/dev/localhost/new-idea/
There is some very minor tooling that will aid in how useful this directory structure is. I am going to get opinioned in this section, because it is easier for me.
-
git clonethe project to disk.cd ~/dev/github.com mkdir sindresorhus cd sindresorhus git clone git@github.com:sindresorhus/globby.git -
Fork the project, likely at the github.com UI.
-
Create a soft link to the original project.
cd ~/dev/github.com/CodeMan99 ln -s ../sindresorhus/globby globby cd globby -
Create a new git remote to your fork, named
fork!git remote add -f fork git@github.com:CodeMan99/globby.git
Setup a git alias to fetch both remotes at the same time. Do it globally so you only
need to do this once. Use this instead of updating with git pull.
git config --global --set alias.u "remote update"
Set git config option to default from upstream when merging. This allows you to use
git merge with no arguments.
git config --global --set merge.defaulttoupstream true
Next, find a work flow to track both "origin" and "fork" the same way you would any
branch HEAD. Personally, I really like tig.
I like to use git branch -vv just as much as I use git status. In particular because
I might "fast forward" my current branch, but the master branch may still be behind. This
command can tell me both in one go. So I setup another alias.
git config --global --set alias.l "branch -vv"
Last, the general consencius is that you should contribute forked work on branch other than master. To help myself enforce this, I setup my master (or whatever the default is) to track with the origin remote and all other branches I track with the fork remote.
