I’ve been using Git for just over two years now. It’s one of the few systems left that doesn’t have a graphical user interface I prefer. In the past years, many choices have either been launched or announced but I’m still a command-line only person.

I grew tired of typing the full push/pull commands so I’ve finally spent some time searching for the best bash function on the net… which appears to be http://forrst.com/posts/My_gitstuff_bash_shortcuts_for_working_with_g-BwI

Edit your bash profile and place the “gpush” and “gpull” functions after anything that currently exists. I personally didn’t use the aliases shown in the pasted code sample, as I already use a different set.

vi ~/.bash_profile

When running gpush or gpull they will activate the associated commands on the current branch.

One of the most powerful features of any source control system is a method called branching. If you imagine a time line of your code, it flows from left to right, oldest to newest. This is often referred to as the trunk (as in “tree”).

Let’s imagine that you want to follow alternate development paths. Whether you’re trying out some larger changes that may or may not work, or you’re working on some big stuff that just isn’t ready to be included on the main (live) code. Creating a branch allows you to copy your code and add/commit all of your work like usual. However, your changes are being done on the branch only and not the primary “trunk” code.

(more…)

While there are numerous tutorials that cover taking your own git repositories to GitHub, or forking and submitting changes back to open source projects, none really explain the process if you’re primarily interested in working with an existing repository as a contributor.

(more…)

Since there are a lot of git introductions out there, I figured one more wouldn’t hurt. The difference is that I’m not just introducing you to git, but to the entire idea of source control.

(more…)

There are many tricks out there to get the git status to show in the command line path, but here’s one that worked the best for me on a Mac OS X Snow Leopard machine.
(more…)

Git is an amazing source control system, and is even better when used with GitHub.com. Installing git on Mac is pretty simple.
(more…)

I’ve spent the past year doing all of my development using the Git version control system. It’s far better than than subversion and has made my job as project manager/developer/commit manager much easier.

However, since it does not use revision numbers like subversion it’s more difficult to include as build numbers or version numbers. I wanted some automated way to identify the build in some way other than a non-incremental SHA1-hash. The only solution I’ve been able to find (without using any external software) is as follows.

The workflow to make this process work as expected would involve the following:

• Prepare master for a new release. Create a new branch for the release and tag it with 1.0.
• Make a single commit on master (necessary to separate the history) and re-tag with something for the next revision, like 1.1-alpha.
• Tags on branch continue with 1.0-1, 1.0-2, etc. Tags on master continue with 1.1-alpha-1, 1.1-alpha-2, etc.

What’s problematic with this is the requirement to both tag and branch each time you want a release. You also need to add in a extra commit before re-tagging master so there’s an unwanted extra step.
(more…)

Here is a quick and dirty guide to create your own remote repository. Access is controlled through standard ssh so it’s as secure as your ssh access is.
(more…)

It’s pretty straightforward to install Git on a mediatemple DV 3.0 server. If you have later versions of their servers with Yum installed, you may be able to simply install it through yum.

To begin you need to download the latest version and run through the standard extraction and configure/make/make install.

(more…)