Proposed Public Git Repo Layout

A place to discuss software and code that isn't automotive related. Free and open source preferred but not compulsory.
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Proposed Public Git Repo Layout

Post by Fred »

With the advent of real users, and being on the receiving end of another author with moving target repo names, I have been thinking about how to best provide development code to the community.

What I've come up with is this set of public git branches in order from most stable to least stable:
  • release: contains the code pointed to by the last release tag - this is what it is, and release feedback should be checked on the forum. Releases them selves will have fairly stringent requirements wrapped around them in future, this should be solid, but possibly down on features and/or containing known bugs at release time or post release. Release candidates will be used to get real world testing in before a release is done. Unit testing will be completely run and 100% passed before each release.
  • master: contains the latest reasonably tested development code - no guarantees, but believed to be working for at least some cases, if not tested on all. Updated/pushed after each block of work is complete and seems to work well. Frequency of update could be multiple times per hour or once a month, it depends upon what is being done.
  • dev: contains potentially unfinished changes and untested changes that are not ready for master yet, but need to be shared by developers to stay in sync. These changes should be final and will generally not ever be rolled back or amended at all. These commits are to be as often as the developer is connected and is happy that his code is final and working towards some short or medium term goal. They may be partial work, though, and could break the build and/or functionality, though this should be avoided where possible.
  • tmp: contains absolutely anything the developer wants it to contain. Used for sharing risky fixes with specific users/testers and/or other developers. These commits *could* make it into dev or master, however equally, they could be amended and rolled back, etc. Typically you wouldn't pull from this unless a developer asked you to, or you thought the stuff it contained was worthwhile and understand it fully. This could contain broken builds, broken code, broken functionality, anything, in the name of temporary testing and development in a shared social coding environment.
Typically:
  • As a developer, you would track dev in order to stay as close to your upstream and/or downstream as possible.
  • As a technical user and tester you would track master, or maybe dev, IF you're game, and IF you're convinced that the current HEAD of dev is useful to you and stable enough for you.
  • As a normal user and tester, you would track master only, unless specifically instructed to track dev or tmp by a developer working on an issue for you. Because you don't know anything technical and therefore are not in a suitable position to make judgement calls on code stability and feature completeness etc, you should not risk using dev and never touch tmp without explicit instructions to do so.
  • A normal user who does not wish to do any testing should not track source at all, rather they should rely on released binaries based on the release tag found in the release branch. Such binaries can be downloaded from the appropriate place for the particular project in question.
The above scheme can/should/will apply to all key projects, with any actual real world users.

A developer may wish to have named branches locally to them, and from time to time, putting a named branch on the public repo will make sense (if development is occurring on more than one thing at a time), however in general, the dev should work on one feature/fix/change at a time, and thus, even if they name their branch at home, they can push that branch into the public dev branch making it super simple for their testers to track their work with a minimum of fuss for both them and the testers.

Does anyone have any comments on this scheme? I will implement it for my stuff fairly soon, I think. Dave is already more or less doing just this.

The release and tmp branches aren't strictly necessary, release can be found by looking at tags and tmp can be created (with a name, perhaps) on the fly when/if required.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
dandruczyk
LQFP112 - Up with the play
Posts: 100
Joined: Sun Apr 06, 2008 6:30 pm

Re: Proposed Public Git Repo Layout

Post by dandruczyk »

Sounds fine to me, though I'd expect there maybe multiple branchs of the "tmp" style and that a more free-form naming might be applicable. i.e. for my own work I tend to name the branch based on the theme of that workflow, mainly so its easy to remember and if hard-core folower wish to track I cna give them a name that makes more sense than just "tmp", esp if i have multiple experiments going on at once and don't wish to use tmp1, tmp2 and tmp3...
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Proposed Public Git Repo Layout

Post by Fred »

Sure, tmp could and possibly should be named whatever you feel is necessary. The named branches for general pushing should, if you're only doing one at a time, which you usually are, be pushed to dev such that the hard core, unless specifically offered something temporary and roll-back-able to pull, can track a single name and not have to constantly mess with configuration etc.

The current stuff that you've been pushing has been of the naming form "fastmath" and "fastmath2" and so on, and those should all be pushed to the dev remote one at a time, then merged and auto deleted post the merge, or kept on your local, gathering dust. Rather than keeping stacks of local branches around, you'd be far better off merging in, fast forward style, tagging the end of that work, and optionally the start too, and deleting the branch. Those tags, like the branches, could be left hanging around locally and never pushed. Tags, unlike branches, are designed to last in perpetuity. Branches, unless they are forks, are designed to be brought back into the main line. Just see the git manuals for examples of language strongly hinting at that.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Post Reply