Centralized GIT workflow/deployment - Repository I

Question

OK, I just want to check the workflow of my GIT setup is correct and I understand it fully before I begin to use it properly. I'm following this workflow and this topic is just going to start with the initialization and creating feature branches then when I'm confident with that I'll create a new topic for Releases and Hotfixes. Hopefully this will help other people to who are looking to use GIT in a similar workflow.

There are 3 developers, let's call them A, B and C who will all work on their local machine, we have 4 remote servers - 'Development', 'Staging', 'Production' and Unfuddle (as the centralized server). Developer A has the directory of files on their local machine.

So, i'm thinking the workflow will be as follows.

Firstly, I need to create the repository on Unfuddle and locally then push my files to the Unfuddle server.

1. Create a repository in Unfuddle called 'website' and give it the abbreviation 'web'
2. Create an SSH Keypair on 'Development', 'Staging' and 'Production' servers and add them to Unfuddle account.

3. Developer A initializes a Git repository in their document root:

   git init

4. Associate the Unfuddle repository with developer A's local one and designate it as an upstream server:

   git remote add unfuddle [e-mail]:username/web.git

   git config remote.unfuddle.push refs/heads/master:refs/heads/master

5. Developer A adds all files to index

   git add *

6. Developer A commits all files

   git commit -am 'initial commit'

7. Developer A pushes locally made commits to Unfuddle Git repository.

   git push unfuddle master

I should now see all of my files within my Unfuddle repository. Developers B and C may now clone the repository to get a copy of the website files.

`git clone [e-mail]:username/web.git`

Feature Branches:

Each developer can now begin creating feature branches using the following workflow:

1. git checkout -b develop
2. git checkout -b feature\test develop
3. Make any code changes
4. git commit -a -m "Make test code changes"
5. git checkout develop
6. git merge --no-ff feature\test
7. git branch -d feature\test
8. git push unfuddle develop

OK so the next part I'm unsure of. We have pushed the feature changes to the centralized Unfuddle server, however the other developers need to get the changes, therefore would they need to create a 'develop' branch and then do git pull unfuddle develop? I've read a fetch and merge is better than pull, is this the case? If so, would it be git fetch unfuddle develop then git merge develop ?

Answer 1

Sounds solid.

With regards to pull vs fetch, I think that if you know exactly what a pull does (fetch/merge), you can use it freely. A lot of newcomers to git use pull without understanding what it does, but it seems like you grasp it. I'd just make sure your team knows what the difference is.

The only step I'm not seeing is the deployment to your webservers - those should be doing a fetch/merge or pull on updates as well. You may want to start off with this process being manual and consider automating it in the future. You should be able to do that with git hooks (they should be supported in Unfuddle). Those scripts will vary on the type of servers that you're running.