Describe the commands to accomplish source control tasks. Show command usage examples for specific tasks(Update Local Master, Update Local Feature Branch ...).
Work flow notes from :Mardak and :Standard8 Development Workflow: Setup: git clone email@example.com: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 firstname.lastname@example.org: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
<dmose> then how do you update your local branch? <Mardak> origin email@example.com:Mardak/loop.git (fetch) <Mardak> mozilla firstname.lastname@example.org: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
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 email@example.com: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 firstname.lastname@example.org: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.
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.
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: ./email@example.com into Nightly and Install. -OR- RUN AUTO TEST cd ../loop/ make karma
Chris: is there information in this bug that still needs to be pulled out into the github docs?
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]
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
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.