h759bkyo4/Documentation
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Fix collaborating/pull-requests-and-git-flow.md

Browse source
This commit is contained in:
Jeremy 2022-07-06 10:22:51 +12:00 committed by Gitea
parent 274558d54f
commit db5724f0b9
1 changed files with 12 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
content/collaborating/pull-requests-and-git-flow.md
View file

@ -8,7 +8,7 @@ eleventyNavigation:
## Benefits of a pull-request based workflow
> ***TLDR:*** *Keep an eye on your repository and org permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners need full access to the repo to merge them.*
> ***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:
@ -19,11 +19,11 @@ Although it is perfectly possible to use a Git project on Codeberg just as singl
Let's say, you would like to contribute to our "examples" project [knut/examples](https://codeberg.org/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:
First, fork the project you would like to work on, by clicking the `Fork` button in the top-right corner of the project page:
![Fork a project](/assets/images/collaborating/pull-requests-and-git-flow/fork-button.png)
Then clone it onto your local machine. We assume that [you have set up your SSH keys](/security/ssh-key). This has to be done only once:
Then, clone it onto your local machine. We assume that [you have set up your SSH keys](/security/ssh-key). This has to be done only once:
```shell
git clone git@codeberg.org:<YOURCODEBERGUSERNAME>/examples.git
@ -33,19 +33,19 @@ Now, let's create a feature branch, do some changes, commit, push, edit, commit,
```shell
git checkout -b my_cool_feature_branch
## do some changes
# 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 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 push
## ...
# ...
git commit -m "more work, tidy-up"
git push
```
Now you can create the pull request by selecting your feature branch, and clicking on the pull request button:
Now you can create a pull request by selecting your feature branch, and clicking on the pull request button:
![Create a pull request](/assets/images/collaborating/pull-requests-and-git-flow/pull-request-button.png)
@ -53,7 +53,7 @@ Now you can create the pull request by selecting your feature branch, and clicki
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 add a second remote that is pointing to the original project. This has to be done only once:
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:
```shell
git remote add upstream git@codeberg.org:knut/examples.git
@ -69,11 +69,11 @@ git pull --rebase upstream main
git pull
```
That's it. You can now push your changes, and create the pull request as usual by clicking on the "pull request" button.
That's it. You can now push your changes, and create the pull request as usual by clicking on the "New Pull Request" button.
## A friendly note on owner rights, and forced push permissions
## A friendly note on owner rights, and force push permissions
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
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.