"Can I even help?"
You can't do anything wrong. Except not doing anything.
There is no wrongdoing, just wrong restraint.
"Help - I want to contribute something, but I don't know what?"
You're in luck. There's various sources for tasks:
TODO
messages!We basically do whatever we think is good to do.
The openage architecture is the foundation. For our development concept, see the development guide.
If you need some inspiration what to work on, see above.
*Please at least skip over this whole file if you want to contribute some code to openage!
Have a GitHub account
Click the fork button
git clone git@github.com:YourAccount/openage.git
cd openage
git remote add upstream https://github.com/SFTtech/openage.git
git checkout -b tentacle-monster-fix
Edit file, adhere to coding style!
Add yourself to copying.md
git add libopenage/unit/tentacle_monster.cpp
git commit -m "engine: fixed vomiting animation of tentacle monster"
make checkall
make test
git push origin tentacle-monster-fix
Create a pull request and look at the CI output
Watch cat pictures while waiting for feedback
Read on below if you need more detailed instructions and quality hints.
We use the git fork/commit/pull request model.
Note: The following is for larger features. For tiny stuff like typo fixes, just create your PR and be done with it.
Fork the repo and add the needed remotes.
upstream
remote is SFTtech/openage
origin
remote is YourAccount/openage
Create a branch for your feature ("feature branch": git checkout -b feature-name
).
feature-name
,
e.g. all changes relevant for branch really-secure-drm
.Discuss your ideas and your work:
"Release early and often!" also applies to pull requests!
[WIP]
pull requestcopying.md
fileOnce your work is done, remove the [WIP]
so it can be merged
Do the changes that are requested by the reviewers.
Aaaaaand you're done.
Before making a pull request, it's good to review these things:
make test
to check whether any functionality has been brokenmake checkall
. If that fails, the automatic buildbot will reject your code.We have a buildbot (currently kevin-ci
) that runs all sorts of checks.
It can be very strict at times, so don't be shocked if it rejects your code, and go fix it instead.
The pull request will present your code to the community, which may point out some things that you might haven't noticed. You should fix stuff until everybody is happy.
What the hell is it, and (why) do I need it?
Rebasing is 'moving' your commits to a different parent commit.
In other words: Cut off your branch from its tree, and attach it somewhere else.
There's two main applications:
# update the upstream remote to receive new commits
git fetch upstream
# be on your feature branch (you probably are)
git checkout my-awesome-feature
# make backup (you never know, you know?)
git branch my-awesome-feature-backup
# rebase: put your commits on top of upstream's master
git rebase -m upstream/master
If you want to fix an older commit of yours, or merge several commits into a single one (squash them), rebase interactively. We don't want to have a commit history like this:
add stuff
fix typo in stuff
fix compilation
change stuff a bit
rebase
in practicegit log --graph --oneline
shows your commit history as graph.
To make some changes in that graph, you do an interactive rebase:
git rebase -i -m upstream/master
With this command, your new "base" is upstream/master
and you can
then change any of your branch's commits.
-i
will open an interactive editor where you can choose actions for each individual commit:
--amend
) it manuallyJust follow the messages on screen.
amend
and fixup
There's also git commit --amend
which is a "mini-rebase" that modifies just the last commit with your current changes by git add
.
It just skips the creation of a new commit and instead melds the changes into the last one you made.
If you want to update a single commit in the range [upstream/master, current HEAD]
which is not the last commit:
edit stuff you wanna change in some previous commit
git add changed_stuff
git commit --fixup $hash_of_commit_to_be_fixed
git rebase --autosquash -i -m upstream/master
After you have rebased stuff ("rewritten history") that had already been pushed, git will not accept your pushes because they're not simple fast-forwards:
The commit contents and the parent commit have changed as you updated the commit, therefore the commit hash changed, too.
force push is the standard way of overwriting your development work with the fixed and mergeable version of your contribution!
You can use any of:
git push origin +my-awesome-feature
git push origin -f my-awesome-feature
git push origin --force my-awesome-feature
Some extra tutorials on git rebase
:
man git-rebase
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。