Get Git?

Git, my process, and lessons learned along the way

Git

Git is an incredibly useful tool for a number of reasons, but at its core it is basically a version control system for code repositories (or repos for short).  Git tracks all ‘committed’ changes that are made to files in the repo.  You then have a record of what has been done, when it was done, by whom, and if good notes are included, why it was done.   At any time, you can always revert back to a specific version if ever needed. Git also makes sharing code with colleagues a lot easier via branching.  If multiple people are working in the code, they do so by working in their own branch.  When a colleague commits a change, the repo owner has the ability to review the change and approve it by merging it into the code base often known as the master.

My Process

Most of my repos are only used by me as a way to have a copy of my project in the cloud, a history of changes, and it allows me to have staging and master branches for a more complete workflow.  So, my process is more or less:

• Open project.  It should already be on my staging branch.
• make code changes (one feature, change, or fix at a time to keep it simple)
• commit changed files (adding a brief commit description)
• git push origin staging
• Github.com – pull request, review, merge, confirm
• git pull upstream staging
• git push origin staging
• git checkout master
• git merge staging
• git push origin master
• Github.com – pull request, review, merge, confirm
• git pull upstream master
• git push origin master
• git checkout staging
• git merge master

At this point, my local project is on staging with everything up to date, ready for the next feature, change, or fix and I am ready to repeat the cycle or close the project.

Lessons Learned

Git can be confusing, especially when you are new to it or you don’t use it regularly.  There are several commands to learn and sometimes a simple mistake can return a cryptic error message.  When I first got into Git, I made several mistakes and had to learn how to resolve conflicts.  It meant spending a lot of time reading online tutorials and forums.  Fortunately, just about any error that you can possibly make has most likely already happened to someone else and a solution has been posted online somewhere.  You just have to stay calm and take the time to find it.  So, here are some of the lessons I have learned:

• Keep commits small.  I now keep my commits to a single feature, change, or fix.  If there is even one small error, it could mean backing out a commit and redoing it.  Small commits are easier to test and rollback.
• Slow down
• Always complete the full commit, push, merge… cycle.  Stay focused on completing the cycle because an interruption or stopping to take a break can cause you to forget where you are in the cycle.  Sometimes, it just isn’t possible to avoid an interruption.  Ie. internet outage, power outage, children…  Fortunately, you can always do a ‘git status’.
  • I have failed to do this and as a result, I have made code changes to the wrong branch.  This causes merge conflicts as one branch will be a commit ahead or behind the other (assuming you are working with multiple branches).
• Stay calm and don’t panic.  I know it is really easy to initially panic with the thought that you might have just hosed your entire repo, but remember Git at its core is a ‘version control system’ and you can revert back to previous versions.
• When in doubt – Google it.
• Don’t upload private API keys to public repos.  A public repo is as its name suggests public to all.  The last thing you want is for your private API key to be found and used and all the sudden you or your client is getting a massive bill for something someone else benefits from.
• Know the repo settings (especially the danger zone settings where the delete button lives):
  • Private vs. public
  • How to add collaborators
  • etc.