1232851 - Work-flow Proposal Document

Status: RESOLVED WORKSFORME

(Hello (Loop) :: Client, defect, P2)

Description

[Chris Rafuse :crafuse]

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

Comment 1

[Chris Rafuse :crafuse]

Work flow notes from :Mardak and :Standard8

Development Workflow:

Setup:
git clone [e-mail]:chrafuse/loop.git

CHANGES and COMMITS

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

Shared Branch Work
git remote add mardak https://github.com/Mardak/loop.git

git remote add  mozilla [e-mail]:mozilla/loop.git

git fetch mardak

git co -b bug-1231931-strings

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

-OR-

Branch merge
Regular push to shared branch hosted on GitHub.

git push origin HEAD

-OR-

STANDARD PRACTICE:
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
-OR-
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

MERGE INTO MOZILLA MASTER:
git co master
git merge --ff-only bug-1232030-rebuild-npm-install-if-package-json-changed

VERIFY MERGE
git log -2

PUSH TO MASTERS
git push mozilla master
AND
git push origin master

Comment 2

[Chris Rafuse :crafuse]

<dmose> then how do you update your local branch?
<Mardak> origin [e-mail]:Mardak/loop.git (fetch)
<Mardak> mozilla [e-mail]:mozilla/loop.git (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

Comment 3

[Mike de Boer [:mikedeboer]]

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 https://github.com/mozilla/loop 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 [e-mail]:mikedeboer/loop.git` (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 [e-mail]:mozilla/loop.git`
 - 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.

Comment 4

[Mark Banner (:standard8)]

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

[Chris Rafuse :crafuse]

Current testing flow, anything missing?
mozilla=upstream

TESTING
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/[e-mail] into Nightly and Install.

-OR-
RUN AUTO TEST
cd ../loop/
make karma

Comment 6

[Ian Bicking (:ianbicking)]

Chris: is there information in this bug that still needs to be pulled out into the github docs?

Comment 7

[Chris Rafuse :crafuse]

Looking at https://github.com/mozilla/loop/blob/master/CONTRIBUTING.md.
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]

Comment 8

[Mark Banner (:standard8)]

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.

https://github.com/mozilla/loop/pull/60