Fix collaborating/pull-requests-and-git-flow.md
This commit is contained in:
parent
274558d54f
commit
db5724f0b9
|
@ -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.
|
||||
|
|
Loading…
Reference in a new issue