On Tue, 2014-04-15 at 17:29 +0200, Olav Vitters wrote:
[...] Is there any recommended workflow people are using in the following situation: - be able to commit changes in a self hosted Bugzilla repository - use that self hosted Bugzilla repository for own installation (easy) - be able to merge changes from git.mozilla.org - be able to move from 4.2 branch to 4.4 branch, etc - be able to see the difference between local and "pristine upstream" - how to set all of this up initially? Any recommended workflow to follow? I'm pretty much an idiot with git. I've found various guides, just wondering what people use in practice.
Hi Olav, I think it depends on how many changes are you going to apply on top of them. FWIW, in a similar use case I've used a workflow based on http://nvie.com/posts/a-successful-git-branching-model/ Though, instead of master I've used a branch named 'stable'. If you had 2 branches, stable and development. I would "merge" first in development, fix anything needed to be fixed, run all tests, once happy, merge development in stable. You might want to consider rebase instead of a regular merge. So, you will always see clearly what is on top of upstream (I mean visually, with a tool like gitg). In this case, I am assuming you would apply changes for 4.4, like 4.4.1, 4.4.2, and so on. I have not written the commands because in the link you will find many examples with diagrams. I would go for something simpler, but you will get the idea. Nevertheless, I can get into the details if you need to. -- Germán Poo-Caamaño http://calcifer.org/
Attachment:
signature.asc
Description: This is a digitally signed message part