Some git best practices
A month or two ago (closer to two, if not more than), I made a couple of posts about git and gitosis. If you didn’t read those, you might just skim them real quick, just to make sure you didn’t miss anything. Anyway, now it’s time to go over some best practices. There may very well be more, but I haven’t used it enough myself to run across any more. One thing to note:
Never, ever, work off of main. You should always have a branch or a tag for anything you’re doing. This isn’t just for git though; this is for any version control system (VCS).If you don’t already have a branch to work off of, create a branch, and then check it out, like as follows. This creates the branch, and then switches to it. The branch is initialized from whatever branch you where in at the time, usually main:
git branch mybranch git checkout mybranch
Now, when you want to merge your change or changes back into main, simply do a git merge. You may also merge individual commits from your branch (not files) if you want, using cherry-pick:
git cherry-pick <commit code from your branch>
Now that I told you about picking individual commits to merge, I’ll tell you not to do that! So, don’t do that! The main reason why, is that it’s easy to get carried away, and actually loose other changes. Use the cherry-pick option sparingly.
Keep your branch up-to-date if you can. If you’re using a branch for all of your development, not just for specific issues, you need to remember to update your branch. What do you need to do? Well, you’ve got two options:
git checkout mybranch git pull
and
git checkout mybranch git rebase master
The second option is the better one, by far. If you ever pushed the branch up to the origin for your checkout, the first would simply pull down any changes that are on the origin server.
Branches should be pushed up to origin. There’s a few reasons for this. First, if your workstation crashes, this way you don’t loose your changes, one of the primary reasons for a VCS. Second, other developers can quickly switch to your branch if need be.
Commit your changes often. Because your changes are committed locally, not to the origin/master server (this is done with a push), you should commit changes, regardless of whether they work. This makes it a lot easier to play around with ideas, and keep track of things that work or don’t.
Provide a message/comment for everything you do with the -m option. This is the case for commits (although git will pull up your default editor to put in the message for a commit), merges, a cherry-pick, or pretty much any other operation that makes a change to the revision history.
Lastly, push your changes often. If you’re developing in your own branch that’s (mostly at least) separate from everyone else, you don’t have to worry about your change affecting anyone else.