2

I have started my own OS application, I am hosting it on GitHub. My problem is that I push changes to the repository from more than one location so sometimes I want to work on it and sometimes I can't always finish something in time but I would still like to push it anyway so I can fetch it later from my other location. I'd like to be able to somehow have a stable version and have the master branch be a 'work in progress'.

How do I do this?

Is there some button I can push that will take the code from my master branch and make it into a zip file in my downloads tab and call it a version or should I do this by hand?

Would it be better to have the master branch be nice and neat and have a separate branch to play with and then merge the two when the time is right? Would this not cause more problems in the merging phase?

Improve this question
2
  • 1
    Do you know how to create different branches? Its just a matter of checking out a specific branch.
    – Ramhound
    Oct 30, 2012 at 11:37
  • On github you can download a zip for every tag, but you should still keep your master somewhat stable. (also see my answer)
    – JonnyJD
    Jan 12, 2013 at 12:26

3 Answers 3

Reset to default
2

Some projects dedicate the master branch for "stable" and use a separate branch, such as "dev" for cutting edge stuff. The development branch is then merged to master every once in a while, when it's in a stable state. For bigger, breaking features it's a good idea to use completely separate feature branches.

Other option is to do the other way around and have master be the dev branch and create release branch(es). Just be sure to document that the master is unstable. Note that you can also change the default branch that GitHub displays from the admin panel.

Perhaps a more elegant way, and also takes care of the zip files automatically is to tag stable versions. GitHub creates automatical zip links for every tag in the Tags tab, which is next to the Downloads. For tagging guide, see this link.

If you do commits in the stable branch, then be sure to merge them to the development branch very often. That will minimize merge conflicts.

If you are unfamiliar with branching, here's a guide.

Improve this answer
1
  • I would recommend using an extra dev branch only when that one is tested independently and merged to master often. So only do that when your master would really become unstable otherwise.
    – JonnyJD
    Jan 12, 2013 at 12:24
0

Have your main act as your on going trunk, this is what will make up your next release.

Use a separate branch for each feature and then merge these back in to the main trunk when they have been fully developed and tested and then retest on the main trunk.

Make release branches periodically from the main and use the log of current open branches and merged in branches to create release notes detailing known faults and added features. This means these branches stay static so you can provide user support for multiple versions not just the latest release.

Improve this answer
1
  • 1
    You should use tickets and milestones for known issues and features. Only use branches for releases when you want to backport things to these releases.
    – JonnyJD
    Jan 12, 2013 at 12:37
0

You should (almost) always have a working master branch in git repositories.

That doesn't mean you can push to master only when you make a new release, but it does mean you should use another branch when you are in the middle of implementing a new feature.

You merge new_feature to master after the feature is complete and tested.

Patches and new (feature) branches are normally based on master.

You could use a branch named stable, since you can change which branch is the default branch shown in github. However, stable is also frequently used as a branch that only receives changes for security fixes or similar of the currently stable release.

Either way, you should not rebase or push -f to "well-known" branches like master and stable, since that is often unexpected. You can rebase in feature branches as much as you like and breaking things in feature branches is no big deal either.

Using feature branches is especially important when you want to open pull_requests on github. After you opened a pull-request to merge one branch into some other branch, you can't use that branch without your changes appearing in that pull-request. This means you should only use the master branch if your repository is the main repository. When you only have a fork and don't plan on making this a standalone project, you should not use the master branch in your fork at all, only feature branches.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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