Home/ Questions/Q 7441607
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T11:02:36+00:00

I’m a bit new to github and I want to try it out, but

  • 0

I’m a bit new to github and I want to try it out, but I’m a bit confused in regards to how to properly do this.

I want to have a Master repo that is pretty much a copy of the live version, and I want to have a development repo (that gets merged with the Master repo every week or what not), and developers would work off the development repo on their own “fork” I guess?

Pretty much

  1. I want a way to allow a bunch of developers to work on a “clone” of a development version of the master repo.
  2. I’d like the “clones” of the development version to be able to be easily updated with the newest development repo.
  3. I’d like the “clones” of development repo to be able to be quickly merged into the development repo, so for example if I edit a css file, and the development repo has added a bunch of new files, it should not require an hour sorting out conflicts.
  4. I want development repo to be able to be merged quickly into the master repo.

How would be the best way to do this? In SVN I would just use a whole bunch of branches (along with 15 hours of merging), but github seems to be confusing in regards to branches.

Any help?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    You can model your process using branches just like in SVN… but better because branches are easier to make and merges are less infuriating. Forks add another layer of separation and access control.

    It’s perfectly fine to simply have a single repository on Github with a “live” branch and a “development” branch. Everybody has permission to push to the repo. The developers work on the “development” branch and somebody is nominated to manage merging things into “live”. That’s a fine first order use of git when transitioning from SVN, and keeps the centralized SVN workflow, but it’s not really taking advantage of Github or git.

    Next trick is to get used to feature branches. When a developer wants to add a new feature or fix a bug, they make a branch off of “development” for that purpose AND ONLY THAT PURPOSE. This branch can be pushed to Github to allow other developers to participate. When it’s ready, the feature branch into “development”. This lets developers collaborate on features while still making small, sharp commits. It keeps multiple features and bug fixes from getting confused. And it makes it obvious why a change was made when looking at the history, because it’s part of a larger feature branch.

    Then you get to the Github “fork and pull” model, and this is when you’re really taking advantage of git. You retain the repository with “live” and “development” branches, and continue to use feature branches, but instead of having push access to the repository, each developer makes a fork of their own repository and does their work there in a feature branch.

    When they’re ready, they send a pull request to have their work merged. This pull request is an opportunity for the work to be reviewed, commented on, and possibly improved. The main advantage of a pull request is how the request itself becomes a conversation, using both words and code, about the merge. This is best illustrated with an example. The initial pull request contains two commits, easy to review by opening them in tabs. Then as the code is discussed and more commits are made they all show up in the request. Even discussions inside the diffs themselves. These pull requests are a fantastic way to have a conversation about code, and they are IMO the killer feature of Github.

    • 0