oreolek/batufa
1
0
Fork 0
Code Issues Pull requests Releases Wiki Activity

Updating DEVELOPERS.md, fixes #3114

Browse source
This commit is contained in:
BRMatt 2010-07-25 19:03:19 +01:00
parent 6b1e4fa00e
commit abbffd5b28
1 changed files with 67 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

83
DEVELOPERS.md
View file

@ -14,35 +14,86 @@ Please read the following before working with this code:
First, you will need to tell git about the remote repository:
git remote add kohana git://github.com/kohana/kohana.git
> git remote add kohana git://github.com/kohana/kohana.git
This adds "kohana" as a remote repository that can be pulled from.
This tells git about the kohana repository and gives it a name which we can use to refer to it when fetching changes from the repository.
git checkout -b kohana/master
## Developing locally
This creates a local branch "kohana/master" of the master branch of the "kohana" repository.
There are 3 branches in the kohana/kohana repository:
* **master** This branch always points to the latest release tag. In essence it points to the last stable edition of the codebase
* **3.0.x** This is a release branch for development of the 3.0.x series, i.e. 3.0, 3.0.3, 3.0.8 etc.
* **3.1.x** This is a release branch for development of the 3.1.x series, i.e. 3.1, 3.1.4, 3.1.14 etc.
To work on a specific release branch you need to check it out then check out the appropriate system branch (the system repo uses 3.0 and 3.1 instead of 3.0.x and 3.1.x).
i.e. to work on 3.0.x you'd do the following
> git checkout 3.0.x
Switched to branch '3.0.x'
> cd system
> git checkout 3.0
Switched to branch 3.0
**Note:** The last step is necessary due to the way that git submodules work.
It is highly recommended that you run the unit tests while developing to ensure that any changes you make don't break the api. *See TESTING.md for more info*
### Creating new features
New features or API breaking modifications should be developed in separate branches so as to isolate them until they're both stable and **fully tests have been written**.
When a new feature is complete and tested it can be merged into its respective release branch.
If a change you make intentionally breaks the api then please correct the relevant tests.
### Bug fixing
If you're making a bugfix then before you start create a unit test which reproduces the bug, using the @ticket notation to reference the bug's ticket number. When you run the tests then this test should fail.
Once you've written the bugfix run the tests again before you commit to make sure that the fix actually works, then commit the fix and the test.
There is no need to create separate branches for bugfixes, creating them in the main release branch is perfectly acceptable.
## Merging Changes from Remote Repositories
Now that you have a remote repository, you can pull changes into your local repository:
Now that you have a remote repository, you can pull changes in the remote "kohana" repository into your local repository:
git checkout kohana/master
> git pull kohana master
This switches to the previously created "kohana/master" branch.
**Note:** Before you pull changes you should make sure that any modifications you've made locally have been committed
git pull kohana master
Sometimes a commit you've made locally will conflict with one made in the "kohana" one.
This pulls all of the changes from the remote into the local "kohana/master" branch.
There are a couple of scenarios where this might happen:
git checkout master
### The conflict is to do with a few unrelated commits and you want to keep changes made in both commits
This switches back to your local master branch.
You'll need to manually modify the files to resolve the conflict, see the "Resolving a merge" section [in the git-scm book](http://book.git-scm.com/3_basic_branching_and_merging.html) for more info
git merge kohana/master
### You've fixed something locally which someone else has already done in the remote repo
This merges all of the changes in the "kohana/master" branch into your master branch.
The simplest way to fix this is to remove all the changes that you've made locally.
git push
You can do this using
This pushes all the merged changes into your local fork. At this point, your fork is now in sync
with the origin repository!
> git reset --hard kohana
### You've fixed something locally which someone else has already fixed but you also have separate commits you'd like to keep
If this is the case then you'll want to use a tool called rebase. First of all we need to get rid of the conflicts created due to the merge:
> git reset --hard HEAD
Then we find the hash of the offending local commit and run:
> git rebase -i {commit hash}
i.e.
> git rebase -i 57d0b28
A text editor will open with a list of commits, delete the line containing the offending commit and then save & close your editor.
Git will remove the commit and you can then pull/merge the remote changes.