views:

73

answers:

1

Hello all, I have been using Git for my version control for a while now, but I have as of yet only used the single master branch for all of my development. As my projects are getting bigger, it's time I being worrying about stable/development branches and release tagging.

I have been reading a bunch of articles about Git branching, but I can't seem to grasp the concepts behind how they work, and it's causing me some frustration when attempting to setup my branches properly.

Here is my situation: I have a project that is a bunch of rake tasks specific to creating our website on a particular server. Right now, we are using Debian-based system, but we are about to switch to an Ubuntu-based system, so I would like to fork (branch) my project and create a separate branch for each server distribution and I would like each branch to be able to easily pull in all of the generic code changes from the master branch when I run git pull in either branch. From what I have read, this can be achieved by tracking the master branch, but I can't seem to get it to work properly.

In addition to this, I also need to begin versioning a different project so that I can release it, but I don't really know the standard Git way of achieving this. At my old company, we used TFS (which I hated) and it was pretty simple: we would create a branch from the master and call it "Version 2". Then we would make sure version 2 was stable and fix any bugs, then every-so-often, we would merge the version 2 changes back into the master branch. Is this the Git way to achieve this, and if so, how exactly do I go about that?

So, to wrap up, I'm asking the following two separate (but very related) questions:

  1. How do I create a remote branch (on GitHub) that automatically tracks changes in master so that I can run git pull in the new branch and have all of the master changes brought in; and
  2. What is the best method for versioning my project and can you give some example commands?

Thanks very much, and please let me know if anything needs clarification!

+1  A: 

If I understand you correctly, I don't think you're using tracking properly. Tracking is used, for example, to track differences between a local branch and a remote copy of that same branch. Your "version 2" branch shouldn't track master. Your local master should track origin/master (the remote repo).

Instead of tracking (if I'm understanding you correctly at all), you should be using rebase. When master has new patches that you want in your version 2 branch, then you do (assuming you're currently on the version 2 branch):

git rebase master

and hope there are no conflicts for you to resolve. Rebasing can be yet another can of worms but it's really not bad. I've only been using git about 6 months, just at work, and after the initial hump it has been smooth sailing.

Tesserex