Web Testing/Automation/CodeReviewProcess/Repository setup: Difference between revisions
Line 28: | Line 28: | ||
2. Once you cloned your repository, you might want to create a new branch for your changes. This way, you keep your main branch clean and prevent merge conflicts from happening.<br><code><nowiki>#Create a new branch for your changes and switch to it immediately:</nowiki><br> git checkout -b stuffIWillBeWorkingOn</code> | 2. Once you cloned your repository, you might want to create a new branch for your changes. This way, you keep your main branch clean and prevent merge conflicts from happening.<br><code><nowiki>#Create a new branch for your changes and switch to it immediately:</nowiki><br> git checkout -b stuffIWillBeWorkingOn</code> | ||
3. Now that you switched to that branch, you might want to do whatever work comes to your mind, write a new test, improve an already existing test or do other changes to the test files. Once you're done, execute the <code>git status</code> command to see which files from your current branch were changed (if you can't remember, which I normally can't :-) ). Once you know which files to commit, you execute the<br><br><code>git commit <filename_1> <filename_2> <filename_n> -m "This is a very meaningful message describing your changes"</code><br><br> | |||
command. |
Revision as of 18:25, 4 August 2011
Introduction
Two different repositories can be useful when you want to keep the code that you write separate from the code that you review. One repository is solely used for the purpose of reviewing other people's code and pushing the code back to the remote Mozilla repository on Github, while the other repository remains for the things you work on.
Case 1: Repository for code review
1. If you'd like to review code, you first need a working branch off the Mozilla main repository. This is the branch that you'll keep up with changes by merging it with the master repository from mozilla and push back any changes that you approve.
#Clone Mozilla repository:
git clone Addon-Tests localdirectory
2. In order to test changes from other repositories, it's essential to create a new branch for each pull request off your cloned master repository and merge it with the changes that you want to review. The branching is needed so that you keep your master branch clean of any remote changes that aren't yet part of the Mozilla master repository. We'll be creating a new branch for Bob's changes as follows:
#Get the data from Bob's repository:
git fetch bob
#Create new branch and switch to it:
git checkout -b bob-test12345
#Merge bob's changes with the new branch:
git merge bob/test12345 bob-test12345
3. Once you've created a new branch for Bob's code changes, you need to switch to it, in order to be able to access Bob's changes and review them.
#Switch to the new branch:
git checkout bob-test12345
4. Next step is to test the changes and to look at the code thoroughly (Look at code style (PEP8) as well as code functionality, take your time!)
5. If you're done looking at the repository and approve the changes that have been made, you might want to either:
- leave a comment in the pull request, stating that you took a look at the code and approved or
- merge these back with your local copy of the Mozilla repository and then push it to Github:
#Merge the changes:
git merge bob-test12345 master
#Push them to Github:
git push
- If you don't approve, you might want to leave comments in the pull request that specify what needs to be changed.
6. In any case, you may delete the branch now or keep it intact to pull upcoming changes from it. That's up to you!
#Delete the branch:
git branch -d bob-test12345
#Update with changes made to the branch:
git fetch bob
git merge bob-test12345 bob/test12345
Case 2: Repository for you own work
1. A clone of the Mozilla repository is needed if you want to work on branch off the Mozilla main repository. You'll keep this clone up-to-date with all upcoming changes to the Mozilla repository.
#Clone Mozilla repository:
git clone Addon-Tests localworkdirectory
2. Once you cloned your repository, you might want to create a new branch for your changes. This way, you keep your main branch clean and prevent merge conflicts from happening.#Create a new branch for your changes and switch to it immediately:
git checkout -b stuffIWillBeWorkingOn
3. Now that you switched to that branch, you might want to do whatever work comes to your mind, write a new test, improve an already existing test or do other changes to the test files. Once you're done, execute the git status
command to see which files from your current branch were changed (if you can't remember, which I normally can't :-) ). Once you know which files to commit, you execute thegit commit <filename_1> <filename_2> <filename_n> -m "This is a very meaningful message describing your changes"
command.