Workflow best practice with git and github?

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 others use this workflow within their projects.

How we use it: We branch before each change, merge back int开发者_运维知识库o the master, commit locally and push to our github repo. We then ssh into our testing environment and pull the master branch of the github repo. We haven't quite grasped rebase, fetch or tagging just yet.

How I would like to use it: I would like to be able to ssh into the different servers and pull a specific tagged version, like "phase 1" into the server. Is this possible, or would I need two different github repos?

Are you supposed to git pulla specific branch into the web servers or create a new alias to git push to?

Can you control release candidates or environments (testing, development, production) within one git repository? or do you need multiple?

If pulling is the solution, can you pull a specific tag ?

---

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.

---

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.

---

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.