Work-flow Proposal Document



Hello (Loop)
2 years ago
2 years ago


(Reporter: crafuse, Unassigned)


Firefox Tracking Flags

(Not tracked)





2 years ago
Describe the commands to accomplish source control tasks.  Show command usage examples for specific tasks(Update Local Master, Update Local Feature Branch ...).

Comment 1

2 years ago
Work flow notes from :Mardak and :Standard8

Development Workflow:

git clone


git commit -m "Bug 1231374 - Strings split into 3 files"

Shared Branch Work
git remote add mardak

git remote add  mozilla

git fetch mardak

git co -b bug-1231931-strings

Single Commit Insertion
git cherry-pick mardak/bug-1231931-strings


Branch merge
Regular push to shared branch hosted on GitHub.

git push origin HEAD


from master
git pull mozilla master

GOOD PRACTICE - sync your GH fork origin master
git push origin master

GOTO Local Feature Branch 
git co bug-1232030-rebuild-npm-install-if-package-json-changed
git rebase master
git rebase -i master

CHANGES - either amend into current or rebase -i and squash into one or multi if too large

PUSH - force changes and PR rewrites history -required when rebasing from master
git push -f origin bug-1232030-rebuild-npm-install-if-package-json-change

Bugzilla ReREQUEST REVIEW - sends notification
r? :Standard8

After r+
REBASE + REWORD: Add r=x to commit message
, r=Standard8

git co master
git merge --ff-only bug-1232030-rebuild-npm-install-if-package-json-changed

git log -2

git push mozilla master
git push origin master

Comment 2

2 years ago
<dmose> then how do you update your local branch?
<Mardak> origin (fetch)
<Mardak> mozilla (fetch)
<Mardak> git fetch mozilla
<dmose> Mardak: then to merge it to your local copy of master?
<dmose> Mardak: or do you just check out topic branches against mozilla/master ?
<Mardak> i dont usually change master. if i need to i "git branch -f master mozilla/master"
<dmose> s/check out/base
<dmose> Mardak: oh, so your local master doesn't track mozilla/master?
<dmose> in any way?
<Mardak> it does
* dmose needs to go read what branch -f does
<Mardak> i meant i don't change my master away from what mozilla/master has
<dmose> rtight, but how do you get your master to reflect the latedst updates from mozilla/master?
<Mardak> git branch -f master mozilla/master replaces my local master with whatever is at mozilla/master
<dmose> oh, interesting
<Mardak> without -f, it would create a branch of that name, but because master already exists, it updates it
<Mardak> alternatively if i want to switch to master at the same time. "git checkout -B master mozilla/master"
<dcritch> Mardak: So you execute git branch -f master mozilla/master every time you want to update your local?
<Mardak> or if i'm already on master "git reset --hard mozilla/master"
<Mardak> the simple way is to make sure you don't have any changes away from mozilla/master and just "git pull mozilla master" with master checked out
<Mardak> but most often i'm not on master and instead on some branch, so the other commands can save some steps
<dmose> Mardak: why not set-upstream mozilla/master instead?
<dmose> ie make local master just track mozilla/master
<dmose> i suppose it does make inadvernent pushes to mozilla/master easier
<Mardak> i always explicitly specify a repository with fetch/pull/push and a specific branch unless "fetch --all"
<dmose> Mardak: ah, that's helpful to know
<crafuse> dmose: Mardak: I had to go through this with Mark this morning and it is done differently.  We should document development work flow of commands to use.  I find each project has a set of commands that are unique and should be used consistently.
<dmose> agreed
<dmose> i rather like Mardak's flow, because it keeps things explicit rather than depending on implicit behavior
<dmose> i generally have depended on implicit behavior a lot
<crafuse> dmose: git push origin master
<crafuse> from master branch
* philipp has quit (Client exited)
<Mardak> crafuse: fyi, you don't need to push from a branch if you're specifying a branch
<Mardak> alternatively, if you're currently on master and want to push it, you can use "git push origin head" instead
<crafuse> Mardak: makes sense
I don't really get all this complicated stuff, so allow me to share my flow (which AFAICT shares the benefits of Mardaks'):

1) Fork on Github to your own set of repos.
2) Clone you fork locally; here's where stuff on the command line starts for you.
 - `git clone` (Please use https:// git URLs if you're behind a firewall)
3) Add the upstream remote repo to occasionally sync the merged PRs in whilst working on your own stuff
 - `git remote add upstream`
 - You can check the result with `git remote -v`
4) For each chunk of work you take, you create a feature branch. This will usually reference a bug.
 - `git checkout -b bug-1232851-fooBarBaz`
5) Start working normally, create commits and push to your own clone regularly.
 - `git push origin bug-1232851-fooBarBaz`
 - You need to specify the branch to push when you push it the first time. Once the branch is tracked on your remote, git push will be smart enough to know where to slingshot stuff to.
6) Whilst working, synchronize with the master branch on the original, upstream repo at mozilla/loop.
 - `git pull --rebase upstream master`
 - Rebasing ('--rebase') will make sure that you local branch commits will be replayed on top of the incoming commits from upstream.
 - If you want to see the changes that were made on master before you rebase, do `git fetch upstream/master`. This will only update the references on the remote tracking branch, so the `git pull` above will still work as expected.
I think the main difference between Mike's method and everyone else is that everyone else seems to keep the local master branch up to date, rebasing on top of that.

I also prefer it slightly as if I find an unexpected issue, I can easily swap to master with up-to-date code to check if the problem exists there or not.

However, I think this is getting down to person preference, and maybe either incorporating some of this into the docs I'm writing in bug 1232111, or creating a new guidance/getting started doc would be most appropriate.

Comment 5

2 years ago
Current testing flow, anything missing?

git fetch mozilla
in feature branch
git pull --rebase mozilla master

make xpi

make build

RUN FF in Profile
cd ../gecko-dev/
./mach run --no-remote -P LoopConfig  -purgecaches

From File Manager Drag and Drop:
./loop/built/ into Nightly and Install.

cd ../loop/
make karma
Chris: is there information in this bug that still needs to be pulled out into the github docs?
Flags: needinfo?(crafuse)

Comment 7

2 years ago
Looking at
Most of the above seems to be addressed.

May want to include a testing section:

Run dev server and firefox with add-on installed.
make runserver
make ARGS="-p ProfileName" runfx 
Optional Parameter for Linux:
[-b ../gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox]
Flags: needinfo?(crafuse)
We've now got a developing document. Additionally, David's got a PR up for improving the contributing document, so I think with the both of those we can call this WFM.
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.