the repo != the project

when you start in on your first “project idea” you should be doing anything but mimicing what you’ve seen on github.

a project in captivity

on github you’re told you’re invited to “browse interesting projects” — you’re actually browsing repositories. A subtle difference that encourages confusion, especially if the internet is where you do most of you learning.

When you browse or clone a project, you see a curated, clear-intentioned, sterile specimen. This is just a small part of the project, distilled to it’s most tame, managable form.

It’s a bit like looking at animals in a zoo; You know what they look like, and what they do, but you won’t see either how or why they got that way.

“the repo” is not “the project”.

projects in the wild

What you don’t see, is the swarm of emails, back and forth messages, notebook sketches, post-it covered monitors, dead branches, hacks, pre-rebased histories, and the rest of every project’s attendant mess.

Accepting and embracing this will help you move faster more confidently.

You’re shooting for a nice repository; trying to start there will only slow you down — it’s an unnecessary leap early on, and nobody walks quickly on egshells.

Early in a project’s life, things change quickly. Tracking a voliatile history will likely only slow you down.

nobody walks quickly on egshells.

hit the ground running

instead of starting with any versioned anything, just let yourself move quickly and be creative.

stay away from your computer

a notebook is indespensible: no adding, no commits, and as long as you fill one page at a time, it’s flawlessly versioned!

same goes for a whiteboard, the two make an awesome combo.

Talk about it

bounce your ideas around with people whose opinion you respect. Everyone’s prone to tunnel vision when he/she is excited about something, and it’s even more severe when you’re working on something alone. Without some outside opinions, it’s all too easy to barely-miss great ideas in favor of almost-baked good ideas — those slight changes can make or break your project.

pen and paper again

there’s no such thing as too much sketching

directories before branches

depending on how pinned-down things are, before you start versioning your work, you can keep it organized in directories instead of branches.

This is more useful if, say, you’re writing a command line app, and you haven’t decided between python and js. Basically, the more different your possible approaches, the better served you are by using directories.

orphan branches

git checkout --orphan fresh-branch

this is useful for 1) early refactoring 2) different approaches in the same repo

the --orphan flag creates a branch with no parent commits, making it super easy to start over from ground zero, using some of the files that you had on the previous branch.

finally version control

git init

only once things are stable-ish with a clear goal, should you dive into full-fledged versioning.

a good question to ask yourself is, “do I have a roadmap file?”. Whether it’s in your repo or not, being able to make one is a good sign that it might be time to start versioning your info; now you have a guideline for:

1. what your feature branches will be
2. the goals your commits are working towards
3. where your version tags will be

the takeaway

you run your project, and your project is more than a repo. git is a tool that, when used to track and collaborate on stable projects is close to unbeatable. It’s awesome in the right application, but letting it out of it’s wheelhouse to take over your project will only hinder you, it’ll slow your workflow and stifle your creativity.

using the right tools at the right stages is the goal, and git is there to serve its stage, not every stage.

take control of your projects!