31

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.

28

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 ! – badZoke Jul 12 '12 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 Jul 12 '12 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) ? – Eswar Rajesh Pinapala Jul 19 '13 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 Jul 19 '13 at 12:40
  • @badZoke .... what you did to handle your 3rd question (handle 2 people working on the same file) ... – Moumit Sep 7 '16 at 18:12
24

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.
  • 1
    Nice and simple, thanks a lot ! I'll start with this, before I move into the complex stuff ;) – badZoke Jul 12 '12 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? – wayofthefuture Aug 3 '16 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 Dec 1 '16 at 9:43
5

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. – Maybe_Factor Jan 4 at 1:00
0

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/git-model@2x.png

  • 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 – Brad Thomas Dec 1 '16 at 14:11

protected by gnat Dec 1 '16 at 4:48

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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