The Codeberg Documentation website by The Codeberg Documentation Contributors is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
It bundles third-party font software licensed under a different license. Please look at the LICENSE file for details.
Changes to the original versions of the article as well as its individual authors can be looked up in this article's commit history
Codeberg and the Codeberg Logo are trademarks of Codeberg e.V.
TLDR: Keep an eye on your repository and organization permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners have permission to merge them.
Although it is perfectly possible to use a Git project on Codeberg just as single shared central repository for individuals and teams, a collaborative workflow based on pull requests provides many benefits:
Let's say, you would like to contribute to our "examples" project knut/examples.
First, fork the project you would like to work on, by clicking the
Fork button in the top-right corner of the project page:
Then, clone it onto your local machine. We assume that you have set up your SSH keys. This has to be done only once:
git clone firstname.lastname@example.org:<YOURCODEBERGUSERNAME>/examples.git
Now, let's create a feature branch, do some changes, commit, push, edit, commit, push, ..., edit, commit, push:
git checkout -b my_cool_feature_branch
# do some changes
git commit -m "first feature"
git push # here you get asked to set your upstream URL, just confirm
# do more work, edit...
git add new_file.png
git commit -m "second feature introducing a new file"
git commit -m "more work, tidy-up"
Now you can create a pull request by selecting your feature branch, and clicking on the pull request button:
Sometimes the upstream project repository is evolving while we are working on a feature branch, and we need to rebase and resolve merge conflicts for upstream changes into our feature branch. This is not hard:
In order to track the
upstream repository, we'll add a second remote that is pointing to the original project. This has to be done only once:
git remote add upstream email@example.com:knut/examples.git
You can also use the SSH variant here for public projects, if you want to be able to pull without specifying your credentials.
Now, let's pull from
upstream, and rebase our local branch against the latest
HEAD of the upstream project repository (e.g. the
git pull --rebase upstream main
That's it. You can now push your changes, and create the pull request as usual by clicking on the "New Pull Request" button.
Please keep in mind that project owners can do everything, including editing and rewriting the history using
force-push. In some cases, this is a useful feature
(for example to undo accidental commits or clean up PRs),
but in most cases a transparent history based on a pull-request based workflow is surely preferable,
especially for the default branches of your project where other people rely on intact history.
Warning If you accidentally leaked sensitive data, say, leaked credentials, keep in mind that commits stay directly accessible, e.g. from the user activity tab or a Pull Request feed, for a while. Please contact us if you really need to remove such data from the public.
Hey there! 👋 Thank you for reading this article!
Is there something missing, or do you have an idea on how to improve the documentation? Do you want to write your own article?
For an introduction on contributing to Codeberg Documentation, please have a look at the Contributor FAQ.
© Codeberg Docs Contributors. See LICENSE