YunoHost/doc
1
0
Fork 0
mirror of https://github.com/YunoHost/doc.git synced 2024-09-03 20:06:26 +02:00
Code Issues Projects Releases Packages Wiki Activity

Corrections

Browse source
This commit is contained in:
Maniack Crudelis 2020-03-31 20:32:16 +02:00
parent 7f208feda6
commit 0628f0731e
1 changed files with 7 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
packaging_apps_git.md
View file

@ -14,7 +14,7 @@ Let's go first for the easy part, GitHub comes with an "easy" web interface to d
#### Branches #### Branches
Then, probably one of the most important thing, **do not work directly on the master branch**. Then, probably one of the most important thing, **do not work directly on the master branch**.
Sorry, it has to be said ! Sorry, it has to be said !
Branches are, as GitHub explains, *"a parallel version of a repository. It is contained within the repository, but does not affect the other branches. Allowing you to work freely without disrupting the "live" version."* Branches are, as GitHub explains, *"a parallel version of a repository. It is contained within the repository, but does not affect the other branches. Allowing you to work freely without disrupting the "live" version."*
@ -46,18 +46,18 @@ The first field is the name of your commit, a very short sentence to explain why
The second field is a large one for a more complete explanation, if you need it. The second field is a large one for a more complete explanation, if you need it.
Finally, if you're editing a repository on which you have permission to write, you can either commit directly to the current branch or create a new branch. Finally, if you're editing a repository on which you have permission to write, you can either commit directly to the current branch or create a new branch.
It's usually better to create a new branch, that way you keep your modification on a *parallel* version of the repository. Your modifications will be discussed in a pull request (explained below) then finally merged into the original branch. It's usually better to create a new branch, that way you keep your modifications on a *parallel* version of the repository. Your modifications will be discussed in a pull request (explained below) then finally merged into the original branch.
#### To fork or not to fork #### To fork or not to fork
A fork is a copy of a repository into your own account. A fork is a copy of a repository into your own account.
We've seen before that if you don't have permission to write into a repository, editing a file will automatically create a fork. We've seen before that if you don't have permission to write into a repository, editing a file will automatically create a fork.
Because the fork is on your account, you always have the permission to write on it. Because the fork is on your account, you always have the permission to write on it.
But even if a fork is not the real repository, but just a copy, a fork is always link to its parent. We'll see later that to create a fork is really useful when opening a pull request. But even if a fork is not the real repository, but just a copy, a fork is always linked to its parent. We'll see later that to create a fork is really useful when opening a pull request.
When you create a new package, it's common to use the [example app](https://github.com/YunoHost/example_ynh) as a base. When you create a new package, it's common to use the [example app](https://github.com/YunoHost/example_ynh) as a base.
But, because you don't want to keep that link to the example app, you should not fork the example app. You will rather clone the app. But, because you don't want to keep that link to the example app, you should not fork the example app. You will rather clone the app.
Unfortunately, to clone an app is a little bit trickier on GitHub. We will see later how to clone from a local repository instead. Unfortunately, to clone an app is a little bit trickier on GitHub. We will see later how to clone to a local repository instead.
We've seen how to edit a file, and how this could fork the app. We've seen how to edit a file, and how this could fork the app.
But, when you want to edit multiple files, the GitHub interface isn't really the best way. In such situation, you would rather clone the repository and work on a local repository. But, when you want to edit multiple files, the GitHub interface isn't really the best way. In such situation, you would rather clone the repository and work on a local repository.
@ -67,19 +67,19 @@ You may still need to fork on your own account to be able to save your modificat
After you have committed your changes, whether on a branch or a fork, you want to propose your modifications to be integrated into the main repository, or the original branch. After you have committed your changes, whether on a branch or a fork, you want to propose your modifications to be integrated into the main repository, or the original branch.
To do so, you're going to *create a pull request*. GitHub usually ask you directly if you want to do so. To do so, you're going to *create a pull request*. GitHub usually ask you directly if you want to do so.
Otherwise, you'll find the button to open a pull request just here: Otherwise, you'll find the button to create a pull request just here:
<img src="/images/github_pull_request.png" width=100%> <img src="/images/github_pull_request.png" width=100%>
When creating a pull request from a fork, to ease the work of the reviewers, **do never** uncheck the checkbox *Allow edits from maintainers*. That option simply allow the maintainers of the original repository to edit directly your work. When creating a pull request from a fork, to ease the work of the reviewers, **do never** uncheck the checkbox *Allow edits from maintainers*. That option simply allow the maintainers of the original repository to edit directly your work.
#### YunoHost-Apps organization #### YunoHost-Apps organization
Following the [YEP 1.7](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines.md#yep-17), your app has to be into the YunoHost-Apps organization, but if you never contribute to an app before or never had any app into this organization you may not have the permission. Following the [YEP 1.7](https://github.com/YunoHost/doc/blob/master/packaging_apps_guidelines.md#yep-17), your app has to be into the YunoHost-Apps organization, but if you have never contributed to an app before or never had any app into this organization you may not have the permission.
First, you need the permission to write into the organization, to do so, ask to the Apps group on the Apps xmpp room. First, you need the permission to write into the organization, to do so, ask to the Apps group on the Apps xmpp room.
To transfer your app to the YunoHost-Apps organization, go to your repository and to *Settings* tab. To transfer your app to the YunoHost-Apps organization, go to your repository and to *Settings* tab.
At the bottom of the page, you will find *Transfer ownership*. At the bottom of the page, you will find *Transfer ownership*.
Into the field *New owner’s GitHub username or organization name*, type *YunoHost-Apps*. Into the field *New owner’s GitHub username or organization name*, type *YunoHost-Apps*.
Your repo will be moved to the organization, you don't have to remove the original repository. Your repo will be moved into the organization, you don't have to remove the original repository.