CODEWITHSUNDEEP
ruby-on-railsgitversion-control
bmeyers
bmeyers

Reputation: 754

Git workflow two developers remotely, best practice?

I know that this question has been asked in many different forms, but I have yet to see the configuration that I want, so I'm throwing this out there.

What I want:
1. 2 clones of the master, so each has its own entire version of the project, so that one subdomain goes to his current work, and the other to mine so that we can both see the changes that we commit and push to the remote server in our respective remote clones.

  1. We both have own local versions of our remote folders/clones.

Essentially we both have our own branches, that neither of us are ever committing to the master branch. My personal branch can be considered the master in this case, because I want him to be able to make his changes, me be able to see and test them on his subdomain, and them merge them into my own.

I also want him to be able to pull my latest commits to the remote server into his own remote clone, and then subsequently onto his local machine so he always has my latest code.

What are the best practices for this? As of now this is what we have been doing and it has been a huge hassle and makes me hate git.

  1. I make changes locally, commit them, and then push to my remote folder of the same branch.
  2. He merges his local folder/branch with the remote commits that I made.
  3. Any commits hes made locally he then commits to his remote branch/subdomain. (This should mean that his remote branch also includes my changes that he merged since his remote folder should be an exact replica of his local machine)
  4. Upon inspection and testing I say a feature is complete, and I then merge into my local branch/folder
  5. I push to my remote branch/folder and everything is available to see on my domain.

Is this not the correct way of doing things? Any suggestions or advice greatly appreciated!

The essentials are that we each have our own branches, and can make additional branches for features and merge them into our own. And also that we each have exact replica copies of our local machines on the server in different folders that are pointed to by the webserver via subdomains so both can be viewed at the same time in different states.

I apologize in advance for the length of this, I just wanted to be as clear as possible.

Upvotes: 3

Views: 120

Answers (1)

John Feltz
John Feltz

Reputation: 63

What you've written is not extensible - add a third developer, and then what do you do?

Instead, have the following branches:

  • master (always clean, use only for deployment to production server)
  • staging (always clean)
  • acceptance (messy)

You create new branches from staging:

git checkout staging
git pull
git checkout -b feature/JF_my_new_feature_20141018

(use a unique set of initials so you know who wrote the branch, and datestamp the branch as well.)

When you're satisfied with your branch (and your tests run fine), you merge into acceptance and run tests there. When your coworkers (or your QA team, or whoever), have verified that the branch is good, you merge it into staging.

Everybody always creates new branches from staging, and nobody merges into staging without a thumbs-up from someone else.

Upvotes: 1

Related Questions