Over the past couple of years, Git has become the standard version control system among the Open Source community. As a consequence of Git hitting the mainstream, the number of Git novices is at an all time high. While there is absolutely no shame in being a novice, the following habits shared among many designers/junior developers should be kicked as soon as possible.
1) Committing everything to master
A significant portion of Git's acceptance by the Open Source is due to its quick branching. Creating, deleting, and switching between branches is a trivial task in Git, in contrast to centralized version control systems such as SVN. Fewer companies understand Git more than Github! Thus it is highly recommend you read an explanation of their
Git workflow.
2) Committing PSDs
PSDs and other large binary files have no place in a collaborative environment. Committing a single PSDs (or worse, a collection of PSDs!!!) can cause the repository to grow to an ungodly size.
Your options:
- Check out Pixelapse, which is geared at solving the version control issues for designers.
- Use version numbers on multiple PSD files when significant milestones are reached.
3) Overuse of global .gitignore
Using a global .gitignore is a great way to save yourself time. However, if misused, your global .gitignore can easily become a headache for your collaborators. Let's say you've created a project withPython Flask, with SQLite as the database of choice. You decide "Hey, I never want to version .sqlite3 files. Let's just toss that in my global .gitignore!". At first glance, this mentality doesn't seem harmful at all. However, any collaborator that comes along without .sqlite3 listed in their global .gitignore can accidentally bring the generated database file into version control. Here's a small list of file extensions I find safe to place in your global .gitignore.
*.o
*.log
*.DS_Store
*Bonus* Lack of Bundler Use in Rails Projects
Plain and simple, use
properly configured Bundler for your Rails projects. Fewer things are more frustrating than tracking down Gems used throughout a Rails project that are not listed in the Gemfile. Just because a gem is installed on your system does not mean it's installed on mine! Remember to track both the Gemfile AND Gemfile.lock files.
February 25, 2012
Joseph is the lead developer of Vert Studios
Follow Joseph on Twitter: