"Git workflow" is very known subject, It is possible find thousands documents talking about and with enough information that it makes unnecessary write other tutorial. Anyway, when I have to do any change in Toro's source, I do not follow any patter and I just make the changes and commit them.
In order to make cleaner this procedure I decide to write a kind of "git protocol" to be follow every time that I make a change on Toro.
I figured out how important is to be clear when we change the source, moreover if the project is huge and every little modification can become it unstable. It helps for understand the design and also for finding faster a possible bug.
For implementing a new feature or fix a bug, we should start creating a new branch. It will keep our job independent of the master and we can mistake without care.
> git checkout -b new_branch
This will create a local branch and it will switch to it.
Makes the changes and then commits when you made enough changes, try to avoid very short commit that they aren't adding important information.
> git commit -a
Note about commit message:
"- Write in present
- First line of the description is a short summary of the change:
- If I’m fixing a bug, a small example of the bug I fixed or issue I was changing.
- If I’m changing a feature, or adding a new one, why I think it the right choice and why I think it’s
acceptable or make that sort of change in the given part of the product cycle we are in."
For sharing your job before finish it, push the branch to the remote repo.
> git push -u origin new_branch
Then, in order to show all the branches either local or remote, first execute:
> git branch -a
And after that, to perform a local checkout run:
> git checkout -b new_branch origin/new_branch
It could be useful write a test in toro/tests/ in order to check the new feature and the stability of the kernel.
When you are sure about the changes, merge to master:
> git checkout master
> git merge --no-ff new_branch
A comment about --no-ff flags extracted from here:
"The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature"
Finally, we should remove the remote and local branch:
> git push origin :new_branch
> git branch -d new_branch
Matias E. Vara
www.torokernel.org
Matias E. Vara
www.torokernel.org
