Workflow best practice with git and github?

Question

I have been using git and github with my small team of developers for our projects. I can\'t help but think that we aren\'t doing it right. I am interested to hear how other

Answer 1

Read the Pro Git book. You can read git man pages for a year and still not get it: trying to learn git by reading man pages is like trying to learn a new language by reading a dictionary, it can be done. The book will teach you a handful of workflows you can have with git, and what git commands to use and in which context to use them.

Answer 2

Basically, you can very well function with one "central" GitHub repository.

• Tags being immutable pointers, they can be used (and pushed) any time, in order to be checked-out to any testing or production environment. That allows some validation to take place but usually does not serve for development.
• Pulling a branch means you can make some evolutions within that branch (due to some bugfix and adjustments to make once the code is on a production environment) and push it back for all the other developer's repository for them to pull back and take into account.

So it depends what you are doing on those servers: only validation (with a status accepted or rejected), or also further developments.
In every case, a tag with an appropriate naming convention is nice to keep track of specific commits in the history, but branches are necessary every time you need to isolate a development effort.

Answer 3

On GitHub, I use one account for my company, which is where the "blessed" code lives; I then maintain a personal fork, where I work on things that aren't quite stable yet. On my local machine, I handle both in one repo, so that master is the blessed code (and pushes to the company account), while all the other branches are for my fork. Here's part of my .git/config:

[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = git@github.com:xiongchiamiov/fourU.git
[branch "hacking"]
        remote = origin
        merge = refs/heads/hacking
[branch "editor"]
        remote = origin
        merge = refs/heads/editor
[branch "problem-utils"]
        remote = origin
        merge = refs/heads/problem-utils
[branch "tests"]
        remote = origin
        merge = refs/heads/tests

[remote "trunk"]
        fetch = +refs/heads/*:refs/remotes/trunk/*
        url = git@github.com:xyztextbooks/fourU.git
[branch "master"]
        remote = trunk
        merge = refs/heads/master

Since I have commit permissions for the company repo, I can just merge (or cherry-pick) commits from one branch into another, and push it up to the appropriate location. Now, separate repos certainly aren't necessary, but since this is an open-source project, I like to keep the "official" repo free of random branches created by my tangents. Once it reaches the point where it will get versioning, there will be an 0.x branch, with tags for each version (0.1, 0.1.1, 0.2, etc.), which is particularly advantageous because github automatically creates tarballs of the files at each tag, nicely suited for pulling down a specific version to a machine that doesn't need the full history.

You should read the github blog; they've had some nice posts describing their deployment workflow, which of course heavily involves git.