Git/GitHub tip No. 2: Pull frequently
One of the easiest ways to make a mess for yourself with Git (and indeed, with any version control system) is to allow files to get out of sync. If you
git pull frequently, you will keep your copy of the repo up to date, and you will have the opportunity to merge your changed code with others' changes while the merging is easy to understand and accomplish -- ideally, when it's so easy that it can be done automatically. A corollary of this tip is to watch your project status. Many Git clients will automatically show you when you need to update to stay current.
Git/GitHub tip No. 3: Commit early and often
A commit is a granular update to a project, which includes one or more changes to one or more files. Think of it as a record of a unit of work completed, which can be applied to or removed from the project as a logical whole. Do commit every logical change you complete, even before testing it. Commits only apply to your local repository. See tips No. 4 and 5 for corollaries to this tip.
The definition of
git commit from the manual page:
Stores the current contents of the index in a new commit along with a log message from the user describing the changes.
Git/GitHub tip No. 4: Comment your commits as you would have others comment theirs
There are 10 kinds of coders: Those who comment their commits, and those who don't. (Old joke. Hint: What base am I using?)
I freely admit to being a stickler for good commit log messages. I set up my repositories to require messages for every commit, and I've been known to send out annoyed late-night messages when commits land with logs on the order of "xx." If you're the kind of developer who thinks (1) the code should speak for itself and (2) the in-line comments are way more important than the change logs, try cloning a repository you've never seen before and identifying the recent commit that may have caused the latest issue posted without reading all the code. As you can see, accurate commit logs are double-plus good.
Git/GitHub tip No. 5: Push when your changes are tested
The worst Git-related bug I've ever had the misfortune to know about happened when an outsourcing company switched from Subversion but didn't train its developers on the difference between distributed source control and centralized source control. About a month later, the project developed weird bugs that nobody could seem to track down. At the daily stand-up meetings, the developers responsible for the area of the application that was misbehaving would protest, "I fixed that two weeks ago!" or accuse another developer of not bothering to pull the changes they had so carefully checked in.
Eventually, someone identified the problem and taught all the developers how and when to
push their commits: In short, whenever the commits test successfully in a local build. Then the company did a two-day-long merge fest before being able to build and deploy the updated, integrated product.