3 Common git Pitfalls and How to Self-Correct

Photo by Patrick Hodskins on Unsplash

Quick links to your issue:

You cloned before forking

Can’t pull down the code

Git init’d the wrong the wrong directory

Whether you’re new to git or a seasoned veteran there are a few pitfalls that will snare us all on occasion. Nothing too serious, more on the side of frustrating; and likely the cause of embarrassment as opposed to actual danger. After all, git is designed to avoid the most tragic of errors.

If you are brand new to git some of the terminology may seem unfamiliar. However, I think that if you’ve found your way here then you will be able to decipher any foreign words through context clues. So I won’t take any more of your time telling you how I’ve almost managed to lose entire repos, or merge a bug into the master branch.

Your day-to-day git work-flow is going to involve six basic commands.

1. git fetch—make your code aware of what has happened in the remote repository.
2. git pull — get your code in sync with the latest commits from the remote repository.
3. git status — see what changes you’ve made on your local machine since your last commit.
4. git add *filename* —stage(prepare) the file(s) named after “git add” for committing. You will most likely be using a dot . instead of listing the actual files names but I’ll let this stackoverflow answer explain that option.
5. git commit -m “A message.” — commits the changes you have made to your local repository. Get in the habit of always providing a message; of what, not how.
6. git push — replaces your remote repo with your local repo, overwriting the remote repo. I realize there is a lot of unpacking to do here but the base command is a push followed by the industry standard origin then the branch name, perhaps master.

YOU CLONED BEFORE FORKING

Let’s assume you’re not committing your code as often as you probably should. Often times you will not catch this mistake until you begin to push your code and have to wonder for a split second why you’re getting this error:

Hopefully you checked you remote repository with git remote -v and saw the repository that you cloned was the repository that you meant to fork first.

• There are a few ways to go about this but I find it most assuring to first delete the current remote repository with git remote rm *repo/branch name*.
• Now you can check your remotes again git remote -v and see that the specified repository is no longer an option.
• Next we add a new remote with git remote add origin *link to the new repo*. You can also add a new branch by using the branch name in place of “origin” in the command. See more about this git command in this stackoverflow answer.

CAN’T PULL THE CODE DOWN

As troublesome as it is common. The error can come in many forms, here’s one example:

This error might be simple, or it could be more complex. that all depends on how you want to handle your local changes. In this article I’m assuming you want a quick fix.

• In that case git stash is your best friend. Your local repo is reset to the last pull and as the command implies, the differences are not entirely deleted but stashed. So you can access the changes later. For more details check out the thorough and intuitive documentation.
• Let’s say you have changes that you want to keep but you also want access to the most recent copy of the remote repo to work with; start by running git fetch then git rebase origin/ *branch name*. Here is a great stackoverflow post on the how and why of these commands.
• If you’re like me you were chasing a curiosity, created a practice file, and don’t care about the changes or even that new file. You just want to quickly get back to the state at the last pull. git clean -f -d or it’s equivalent git reset --hard HEAD will permanently erase the changes and you’re all set to pull down the remote repository’s updates.

^ Nᴏᴛᴇ; ᴛʜᴇ -ғ ᴏᴘᴛɪᴏɴ ᴄᴀɴ ʙᴇ ᴛʜᴏᴜɢʜᴛ ᴏғ ᴀs “ғᴏʀᴄᴇ” ᴀɴᴅ ᴛʜᴇ -ᴅ ᴡɪʟʟ ʙᴇ sᴜʀᴇ ᴛᴏ ɪɴᴄʟᴜᴅᴇ sᴜʙᴅɪʀᴇᴄᴛᴏʀɪᴇs ᴀs ᴡᴇʟʟ. Iғ ʏᴏᴜ’ʀᴇ ғᴇᴇʟɪɴɢ ᴛɪᴍɪᴅ ᴛʜᴀᴛ ᴛʜɪs ᴡɪʟʟ ᴅᴇʟᴇᴛᴇ ᴛᴏᴏ ᴍᴜᴄʜ, ʀᴜɴ ɢɪᴛ ᴄʟᴇᴀɴ -ɴ ᴛᴏ sᴇᴇ ᴡʜᴀᴛ ᴡᴏᴜʟᴅ ʙᴇ ᴅᴇʟᴇᴛᴇᴅ ɪғ ʏᴏᴜ ᴡᴇʀᴇ ᴛᴏ ʀᴜɴ ᴛʜᴇ ᴄᴏᴍᴍᴀɴᴅ ɪɴ ᴇᴀʀɴᴇsᴛ. Fᴜʟʟ ᴅᴏᴄᴜᴍᴇɴᴛᴀᴛɪᴏɴ ғᴏʀ ᴛʜɪs ᴄᴏᴍᴍᴀɴᴅ ᴄᴀɴ ʙᴇ ғᴏᴜɴᴅ ʜᴇʀᴇ.

GIT INIT’D THE WRONG DIRECTORY

You have a new app idea. You make the directory,mkdir worlds-best-app and immediately run git init because you’re responsible only you forgot to run cd worlds-best-app first.

Depending where you ran git init your IDE might be telling showing this:

• Save the gallon of ice cream for a real emergency because you’re going to undo this issue with a simple command rm -rf .git from the same directory you ran git init from.

That’s right, we’re simply going to remove the .git file so changes will stop being tracked in this directory and all of it’s subdirectories.

QUICK TIPS

• Triple check that you are running your command from the correct directory. The majority of errors, especially as a beginner, will result from running your command in the wrong directory.
• Read your errors! Then use those errors to guide you to success or use them as search criteria on stackoverflow. Git, as a version control software is so pervasive and has been around long enough that you problem has already been encountered before.
• DON’T PANIC!! Git has a steep but short learning curve. Many developers work for years and will stray from the six commands listed at the top but a very little.
• Practice. Find a friend or a second computer(a bit redundant) and go through the easy commands until they are smooth and comfortable. Then create edge cases, mistakes, and bugs. Then fix or deal with them.