I'm very new to GIT/GitHub (as new as starting yesterday). I would like to know what is the best way to manage multiple people working on the same project with Github. Currently I'm managing one project with four developers.

  1. How do I go about the workflow and making sure everything is in sync?

    (Note: All developers will have one universal account.)

  2. Does each developer need to be on a different branch?

  3. Will I be able to handle 2 people working on the same file?

Please post a detailed answer, I'm not a shy reader. I need to understand this well.


4 Answers 4


If all of the developers have commit access to the repo, you should not need to do anything special. They will pull changes from the repo, make their own changes, commit locally, and then push back into the public repo when they have something working.

If on the other hand you have one (or a few) developer(s) responsible for committing to the repo, and the others are providing patches to these. Have each of them clone the repo into their own accounts and have them send pull-requests when they have a change they want into the main repo.

It's also possible to make specific clones for working on specific features if you wish. Using the same workflow with pull-requests to get changes into the main repo when the feature is done.

If by "All developers will have one universal account" you mean that all developers will share one GitHub account and appear as the same committer in the repo, that's a bad idea. Make separate accounts and set them up as collaborators if you want them all to have commit access.

As for your specific questions:

  1. No, use branches for features, fixes etc that will take more than one commit. More than one developer can be working on the same branch.

  2. Yes, git handles conflicts really well, so there's no problems having people work on the same file. No problems except, conflict resolution may not always be trivial if there's fundamental changes to a file that has been edited by more than one member. This is however nothing that can not be overcome by talking together. Version control does not replace communication.

Good luck!

  • A couple of points you've made there are real eye-openers, got me to think in a different direction all together, thanks !
    – painotpi
    Commented Jul 12, 2012 at 10:03
  • Hapy if it can help you. Git and DVCS's require some getting used to, but they're extremely flexible once you get used to them.
    – harald
    Commented Jul 12, 2012 at 10:09
  • Thanks for this. I had one specific question. If there are multiple developers working on the same branch. Every single time one of the developers makes changes and pushes to the working branch, does the rest of the developers need to pull the changes(to make sure they have the latest code locally to work on) ? Commented Jul 19, 2013 at 4:11
  • No, not every single time, just when you want to sync up. Consider your local copy of the branch as your private branch, and the upstream branch as the one you want to merge into. Using something like git fetch upstream followed by git merge upstream/branch should get you synced without rewriting your local commit history. If that's not an issue, just simply git pull --rebase will move your local unpushed changes onto the top of the upstream branch.
    – harald
    Commented Jul 19, 2013 at 12:40
  • @badZoke .... what you did to handle your 3rd question (handle 2 people working on the same file) ...
    – Moumit
    Commented Sep 7, 2016 at 18:12

We work with 2 developers and we use this workflow:

  • On Github we have a master branch and a dev branch
  • The master branch is the same as production or contains deployment ready code
  • The dev branch is ahead of master and contains all new code currently being worked on
  • Locally we both work on the dev branch and push to github when something is ready
  • The other dev fetches any new changes from the dev branch before pushing his new code
  • When dev branch is good,we merge with the master branch
  • Locally we have several feature branches issue branches etc.
  • 2
    Nice and simple, thanks a lot ! I'll start with this, before I move into the complex stuff ;)
    – painotpi
    Commented Jul 12, 2012 at 11:42
  • What if, when the other dev fetches the new changes, before pushing his code, the new changes alter code that he has already changed? Commented Aug 3, 2016 at 16:39
  • +1, this is indeed the simplest to start with, and works perfectly fine. What you are using is called simplified gitflow: marcgg.com/assets/blog/git-flow-before.jpg
    – Jelle
    Commented Dec 1, 2016 at 9:43

I see only text answers here, so I thought I'd post a picture of a nice gitflow to start with. A picture describes more than a thousand words:

Simplified Gitflow

  • This flow also works good with Continuous Deployment.
  • Your master branch contains code that is currently running on your production server.
  • Your develop branch contains code that is currently running on a staging/testing server.
  • +1, git flow, or something similar is probably the right answer to this question. Commented Jan 4, 2019 at 1:00
  • As I usually see it, the "develop" branch is called "master" and "master" is called something else (maybe "stable", or maybe it doesn't have a name, only the tags) Commented Mar 5, 2020 at 13:37

I work with 3 other developers, and we struggle with this quite a bit. Developers will sometimes push commits into production that really aren't ready for prime-time yet because they'll pull other commits into their changes and then push into production.

Version branches seem to work ok for us. So, if version 1.0 is the current stable version, we will create a branch for v1.1-development. The developers will make changes in this branch. Our testing server checks out this branch and pulls changes as needed.

When all the features for v1.1 are ready to go and testing is done, we will merge v1.1 with master and push.
With branches, developer team A can work on v1.1 and developer team B can work v1.2. Both teams can work without impacting each other. If team A develops something that B can use, you can pull those changes into B without impacting production (this doesn't happen very often).

We also use a hotfix branch that is used for immediate changes.

Here is a link to a picture of what this looks like. http://nvie.com/img/[email protected]

  • 1
    That doesn't sound to me like you're really implementing git flow as it was intended - which is to split each independent feature or fix onto its own branch, rather than just each release Commented Dec 1, 2016 at 14:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.