Workflow best practice with git and github?
git, github, version-control, workflow
Solution
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.
Problem
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 into 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 pull`a 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` ?