MozillaWiki

Auto-tools/Projects/Mozmill/RepoSetup: Difference between revisions

Page Discussion

Auto-tools/Projects/Mozmill/RepoSetup (view source)

Revision as of 23:27, 8 October 2010

1,507 bytes removed ,  8 October 2010
update to 1.5.1 workflow, correct some statements
(note about remote tracking branch)
(update to 1.5.1 workflow, correct some statements)
Line 14: Line 14:
Here's how to stay up to date with the remote mozautomation repository:
Here's how to stay up to date with the remote mozautomation repository:
<pre>
<pre>
git pull origin master                // Pulls changes from your github fork to your local machine
git pull --rebase mozauto master   // Pulls changes from mozauto to your local machine
git pull mozauto master               // Pulls changes from mozauto to your local machine
git push origin master             // Pushes any changes from mozauto to your Github fork
git push origin master               // Pushes any changes from mozauto back up to your github fork
</pre>
</pre>
Now you're in sync.  Unless you're working on a maintenance release, skip down to "getting stuff done".
Now you're in sync.  Unless you're working on a maintenance release, skip down to "getting stuff done".


= Setting up for Development on 1.4.2 =
= Setting up for Development on 1.5.1 =
For work on a maintenance release of Mozmill, we'll use the maintenance release branch.  Work for the next major version of Mozmill will be done against the "master" branch, which is already set up.  Here's how to set up the maintenance branch on your system (Assuming you've already added mozautomation as a remote repository).
For work on a maintenance release of Mozmill, we'll use the maintenance release branch.  Work for the next major version of Mozmill will be done against the "master" branch, which is already set up.  Here's how to set up the maintenance branch on your system (Assuming you've already added mozautomation as a remote repository).
* Pull the 1.4.2 code into a local branch:
Pull the 1.5.1 code into a local branch:
<pre>git checkout -b 1.4.2
<pre>
git pull mozauto 1.4.2</pre>
git branch hotfix-1.5.1 mozauto/hotfix-1.5.1
* Now you're on a local branch called "1.4.2" with the 1.4.2 code.  Use git checkout to switch between local branches.
git checkout hotfix-1.5.1
</pre>
Now you're on a local branch called "hotfix-1.5.1" with the 1.5.1 code.  Use <tt>git checkout</tt> to switch between local branches.
 
To keep your hotfix-1.5.1 branch updated with the changes to mozauto's 1.5.1 branch:
<pre>git pull --rebase mozauto hotfix-1.5.1</pre>


= Setting up for Development on hotfix-1.5.1 =
For work on the hotfix-1.5.1 branch, you will need to use a remote tracking branch. 


= Getting Stuff Done =
= Getting Stuff Done =
We recommend doing all your work against master.  Then if we need to take that patch on a maintenance branch, we can address that later with your patch from the master tree. So, to work on master, here's what you need to do.
If you're doing a fix to the maintenance branch then check out that branch (e.g. hotfix-1.5.1). If you're doing a fix to master then checkout master. Create a new, temporary branch off of that branch to do your work in (with the example of master):
<pre>
<pre>
git pull origin master       // Ensures that you're up to date with your fork
git checkout master               // we're doing a fix that will land on mozauto master
git pull mozauto master       // Ensures you're up to date with mozauto
git pull --rebase mozauto master // make sure local master is up to date
git push origin master       // Ensures your fork is up to date with any changes from mozauto
git checkout -b myfeature        // create new feature branch based on master
git checkout -b myfeature    // makes branch and switches you to the myfeature branch
// make some changes to some files
git commit -a -m "did some stuff" // commit changes to your local myfeature branch
</pre>
</pre>


This is important because it keeps your "master" branch clean.  If you use master '''ONLY''' as a area for merging upstream to your fork and mozauto, you'll keep things simple and you will have very few (if any) merge conflicts.  So, that's why we recommend doing all feature/bugfix work in a branch.  You can optionally push that branch up to your github fork as well (that's recommended, then your code doesn't just live on your own machine).
This is important because it keeps your "master" branch clean.  If you use master '''ONLY''' as a area for merging upstream to your fork and mozauto, you'll keep things simple and you will have very few (if any) merge conflicts.  So, that's why we recommend doing all feature/bugfix work in a branch.  You can optionally push that branch up to your github fork as well (that's recommended, then your code doesn't just live on your own machine).


== Push a Feature branch to github ==
== Push a Feature branch to Github ==
<pre>
<pre>
git checkout master          // Gets you back on the master branch
git checkout myfeature       // switch to feature branch if not already on it
git push origin myfeature     // pushes your feature branch to github
git push origin myfeature    // pushes feature branch to your remote (fork on github)
</pre>
 
== Finished some pieces of code, push them to github ==
<pre>
git add <myfile>              // adds your file to the change to be picked up
                              // do this for both new and modified files
git commit -m "some message"  // commits your current change
git push origin myfeature    // pushes your feature branch (and your commits to your github fork)
</pre>
</pre>


Line 58: Line 53:
We want to diff your feature branch against the master branch.  So ensure your master is up to date and create the diff:
We want to diff your feature branch against the master branch.  So ensure your master is up to date and create the diff:
<pre>
<pre>
git checkout myfeature                  // Switch to myfeature branch
git checkout myfeature                  // switch to myfeature branch if not already on it
git diff -U8 -p master > mypatch.diff  // Create the patch
git diff -U8 -p master > mypatch.diff  // Create the patch
</pre>
</pre>
Line 66: Line 61:
''This only applies if you have commit access to mozautomation''
''This only applies if you have commit access to mozautomation''


Once you have gotten review, it's time to get things ready to land.  First, you may have many commits in your patch.  We really encourage you to [http://www.andrewmoore.com/public/index.php/My_git_workflow squash those down] to just the salient commits.  You can do that using interactive rebase:
Once you have gotten review, it's time to get things ready to land.  First, you may have many commits in your patch.  We really encourage you to [http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html] to just the salient commits.  You can do that using interactive rebase:
<pre>
<pre>
git checkout myfeature
git checkout myfeature
Line 72: Line 67:
</pre>
</pre>


Ok, you've gotten your review, your commits are in good shape, and your commit message is correct, then you're ready to push!
Ok, you've gotten your review, your commits are in good shape, and your commit message is correct, then you're ready to push, let's say you want to push to mozauto/master:
<pre>
<pre>
git checkout master              // Switch to master branch
git checkout master              // Switch to master branch
Line 82: Line 77:
</pre>
</pre>
You only need to do pull --rebase if your main master branch is NOT clean.  If you have changes on master then this will ensure those changes are applied properly with changes coming downstream from the mozauto master.  If the master branch is clean, doing pull --rebase doesn't hurt anything, so it's the recommended step.
You only need to do pull --rebase if your main master branch is NOT clean.  If you have changes on master then this will ensure those changes are applied properly with changes coming downstream from the mozauto master.  If the master branch is clean, doing pull --rebase doesn't hurt anything, so it's the recommended step.
== Pushing to 1.4.2 (or any maintenance branch) ==
'' This only applies to you if you have commit access to mozautomation. ''
This workflow assumes that you have a patch that you uploaded to bugzilla.  I'll assume that you've created that patch against the master and now we're going to backport it to the maintenance branch.  Here's how to do that.
<pre>
git checkout 1.4.2              // Switches to your 1.4.2 branch
git pull --rebase mozauto 1.4.2 // Ensure the 1.4.2 branch is up to date
git checkout -b myfeature1.4.2  // Creates a new branch based on 1.4.2
patch -p1 <mypatch.diff        // Applies your patch to the 1.4.2 based branch
git add <any changed files>    // Ensures files will be committed
git commit -m "msg"            // Use a good commit message
git checkout 1.4.2              // Switches back to clean 1.4.2 branch
git merge myfeature1.4.2        // Merges your patch into the 1.4.2 branch
git push mozauto 1.4.2          // Pushes the changes to 1.4.2 branch on mozauto
                                // PARTY!
</pre>


== Delete a Feature Branch ==
== Delete a Feature Branch ==
Line 105: Line 83:
To delete a local branch, you must switch to the main branch that the local branch was created from.  If the branch was created for a feature on the master, then switch to master.  If the branch was created for a feature on a maintenance branch, switch to that maintenance branch.  Failure to do this will give you a "branch is unmerged warning":
To delete a local branch, you must switch to the main branch that the local branch was created from.  If the branch was created for a feature on the master, then switch to master.  If the branch was created for a feature on a maintenance branch, switch to that maintenance branch.  Failure to do this will give you a "branch is unmerged warning":
<pre>
<pre>
git checkout master            // Assuming you created this branch from master
git checkout master            // Move to some other branch
git branch -d myfeature        // Deletes the branch
git branch -D myfeature        // Delete the myfeature branch
</pre>
</pre>


Now, if the branch was pushed to your github repo, we add another step.
Now, if the branch was pushed to your Github repo, we add another step.
<pre>
<pre>
git checkout master            // Assuming you created this branch from master
git push origin :myfeature    // Removes the branch from github
git push origin :myfeature    // Removes the branch from github
git branch -d myfeature        // Deletes the local branch
</pre>
</pre>


Harthur
865

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/259788"