Skip to content

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:

  1. 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>
  2. 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.
  3. 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


    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.

  4. 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.
  5. 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.
  6. 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.
  7. 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.
Be Sociable, Share!

Posted in Programming, Version Control. Tagged with , .

3 Responses

Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.

  1. I have to disagree with number 3. “The second option is the better one, by far.” Rebase can be a very dangerous operation and can trash your repo and make everyone hate you if you don’t know what you are doing. Other than that, good advice.

  2. In fact, when combined with 7, using rebase WILL screw your repo up.

  3. Or 4 for that matter. Point is rebase is a very very very sharp tool.