At Monarch Digital, we use Git (http://git-scm.com) to manage our source code. Overall the process of storing code in a repository with a timeline of changes is referred to as version control. We decided to use Git for our version control workflow because it is one of the most popular systems in use (for ubiquity) and because it is well-designed to support distributed teams working asynchronously on projects.
This post may be used as a reference of basic Git commands and is useful for those who are new to Git as well as a refresher for those who use Git everyday.
Imagine this situation. You've "pulled" in a bunch of code for your project into your local development git repository, but afterward realized you want to go back to a previous version or "commit" in your code. Using the "git revert" command, because it sounds like it is going to put things back to what they were, you actually end up making a mess of your repository and are lefting scratching your head and wondering what went wrong.
Executive Summary. This is a short, no-nonsense explanation directed to nontechnical website owners on what release control is all about and what problems it addresses.
If you work with a team and use Git as your primary version control system, then you may have noticed some strange commit messages in your log. These commits have cryptic messages like "Merge remote-tracking branch 'origin/master'" that are pretty much meaningless. In this post we'll see an example of how these ugly commits are generated and how to prevent them using the git rebase command. This example assumes you are familiar with basic Git commands and workflows.