Git/GitHub tip No. 6: Branch freely
One of the biggest advantages Git has over some other version-control systems is that merging usually works well, at least partly because Git automatically chooses the best common ancestor to use for a merge. Most software developers need to start creating branches in their projects more often. It should be a routine daily occurrence, not the subject of an anguished all-hands strategy meeting. The likelihood is that, when the branch project is complete, accepted, and ready to move into the main project, the merge will not present any insurmountable problems.
I know that takes some adjustment, especially if you've been stuck in a company that does source code control with CVS. But try it. It's a whole lot better than having customers accidentally see your unfinished experimental code when the trunk project has to be published because of a breaking bug. (This article explains basic branching and merging well.)
Git/GitHub tip No. 7: Merge carefully
While merges with Git usually work well, if you do them without thinking, you can occasionally encounter difficulty. Step one is to make sure you have no uncommitted changes. From the
git merge manual page:
Before applying outside changes, you should get your own work in good shape and committed locally, so it will not be clobbered if there are conflicts. See also
Also see tip No. 8.
Even if it all goes south during a
git merge, you aren't hosed:
If you tried a merge which resulted in complex conflicts and want to start over, you can recover with
git merge --abort.
The follow-on command to
git merge is usually
git mergetool, assuming you like to use a GUI for merging. If you'd prefer the old-school method, you can edit the files in conflict with your favorite programming editor, fully remove the
>>>>>>> lines, save the revised files, and
git add each file you fixed.
Git/GitHub tip No. 8: Stash before switching branches
A software developer's workflow is rarely linear. Users have the gall to report bugs, managers have the audacity to prioritize tickets other than the one you picked to work on, and you yourself might change your mind about what you want to do.
There you are, with three files committed for a release, and a fourth file in a changed but non-working state. (The
git status command will tell you all of this if you don't happen to remember where you were.) All of a sudden you need to work on a bug fix in a production version. You need to switch branches pronto, but you can't. Your working directory is dirty and you have two hours of work you don't want to lose.
git stash. Voilà! Now you have all your changes stored in a WIP (work in progress) branch, and you can switch to the production branch from your clean directory. When you're done with that, switch back to where you were with
git stash apply.
Git/GitHub tip No. 9: Use gists to share snippets and pastes
GitHub "gists" -- shared code snippets -- are not a Git feature, but they use Git. All gists are Git repositories, and GitHub Gist makes it easy to share them. You can search Gist for public gists by topic, programming language, forked status, and starred status. You can also create secret gists and share them by URL.