0

We have a GitHub project (master), every member of the team have a Fork of the project into their own repository.

Once a developer fixed something he create a new branch inside his local forked repo and commit that into remote repository and after that they request a Pull Request so that change go into the master reposiroty.

We publish to production "manually" once a week but we have had issues in production because accidentaly developer had committed to their forked repository and other developer with higher privilegies accept the changes and merge that into master repo, then someone else publish to production and he didnt knew that those new changes didn't passed to QA process.

So, what I want is to create like a Production Repository, so when we have the code in master repo that we know is stable and working then create like a Production branch so if by mistake something is commited and merge into master repo then the code for production publish is not affected.

Any clue or best practice to do this?

Improve this question

2 Answers 2

Reset to default
1

Not sure I'm understanding the question correctly, but you can add as many remote repositories as you like. There is a section in the Pro Git book called Working with Remotes that discusses this thoroughly.
In my experience, separating development and production code is typically done with a branching model such as git-flow. You can create separate repositories to solve this problem if you like, but doing so is unnecessary. This is because if developer A submits a PR that's merged by developer B, then developer C will get a non-fast-forward error when they try to commit upstream. This is called a subversion-style workflow. Per the docs:

Git will not allow you to push if someone has pushed since the last time you fetched, so a centralized model where all developers push to the same server works just fine.

If commits to the upstream branch are not being fetched and merged appropriately before pushing, then someone has likely taken it upon themselves to rewrite history.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Your git workflow is good enough to take care of this issue.

First, to fix the issue:

Treat unintended code push as bug and fix it as you would fix any other bug. Best person to perform this activity would be the developer who pushed that code. Developer can just fix it in their fork and submit a pull request. Try not to add any other unrelated code with this pull request.

About Production Branch or Repo:

I don't think you need another Production Branch/Repo (you already have one). As it happened with your current PROD repo, accidental code push can make it to new Branch/Repo too.
Instead use tags/releases feature in GitHub. Whenever state of code in master repo is prod ready, tag it and use the tag for production publish.

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.