We thank you in advance :thumbsup: :tada: for taking the time to contribute, whether with *code* or with *ideas*, to the project.
## Did you find a bug?
* Ensure that the bug was not already reported by [searching under Issues].
* If you're unable to find an (open) issue addressing the problem, [open a new one]. Be sure to prefix the issue title with **[BUG]** and to include:
- a *clear* description,
- as much relevant information as possible, and
- a *code sample* or an (executable) *test case* demonstrating the expected behaviour that is not occurring.
## How to work on a new feature/bug
Create an issue on Github or you can alternatively pick one already created.
Assign yourself to that issue.
Discussions on how to proceed about that issue take place in the comment section on that issue.
Some of the work might have been done already by somebody, hence we avoid unnecessary work duplication and a waste of time and effort. Other reason for discussing the issue beforehand is to communicate with the team the changes as some of the features might impact different components, and we can plan accordingly.
## How we work with Git
All work should take place in a dedicated branch with a short descriptive name.
Use comments in your code, choose variable and function names that clearly show what you intend to implement.
Once the feature is done you can request it to be merged back into `main` by making a Pull Request.
Before making the pull request it is a good idea to rebase your branch to `main` to ensure that eventual conflicts with the `main` branch is solved before the PR is reviewed and we can therefore have a clean merge.
### General stuff about git and commit messages
In general it is better to commit often. Small commits are easier to roll back and also makes the code easier to review.
Write helpful commit messages that describes the changes and possibly why they were necessary.
Each commit should contain changes that are functionally connected and/or related. If you for example want to write _and_ in the first line of the commit message this is an indicator that it should have been two commits.
Learn how to select chunks of changed files to do multiple separate commits of unrelated things. This can be done with either `git add -p` or `git commit -p`.
#### Helpful commit messages
The commit messages may be seen as meta-comments on the code that are incredibly helpful for anyone who wants to know how this piece of software is working, including colleagues (current and future) and external users.
Some tips about writing helpful commit messages:
1. Separate subject (the first line of the message) from body with a blank line.
2. Limit the subject line to 50 characters.
3. Capitalize the subject line.
4. Do not end the subject line with a period.
5. Use the imperative mood in the subject line.
6. Wrap the body at 72 characters.
7. Use the body to explain what and why vs. how.
For an in-depth explanation of the above points, please see [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/).
### How we do code reviews
A code review is initiated when someone has made a Pull Request in the appropriate repo on github.
Work should not continue on the branch _unless_ it is a [Draft Pull Request](https://github.blog/2019-02-14-introducing-draft-pull-requests/). Once the PR is marked ready the review can start.
The initiator of the PR should recruit a reviewer that get assigned reviewer duty on the branch.
Other people may also look at and review the code.
A reviewers job is to:
* Write polite and friendly comments - remember that it can be tough to have other people critizising your work, a little kindness goes a long way. This does not mean we should not comment on things that need to be changed of course.
* Read the code and make sure it is understandable
* Make sure that commit messages and commits are structured so that it is possible to understand why certain changes were made.
Once the review is positive the Pull Request can be _merged_ into `main` and the feature branch deleted.
----
Thanks again.
[searching under Issues]:https://forge.ird.fr/mivegec/dainat/isi-training-git/issues
[open a new one]:https://forge.ird.fr/mivegec/dainat/isi-training-git/-/issues/new?title=%5BBUG%5D
To make it easy for you to get started with GitLab, here's a list of recommended next steps.
*[Description](#description)
*[Contributing](#contributing)
*[Report bugs and issues](#report-bugs-and-issues)
*[Authors and acknowledgment](#authors-and-acknowledgment)
*[Notes](#notes)
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)!
## Description
## Add your files
-[ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files
-[ ] [Add files using the command line](https://docs.gitlab.com/ee/gitlab-basics/add-file.html#add-a-file-using-the-command-line) or push an existing Git repository with the following command:
-[ ] [Set up project integrations](https://forge.ird.fr/e-cop/formation-git/-/settings/integrations)
## Collaborate with your team
-[ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/)
-[ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
-[ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
Use the built-in continuous integration in GitLab.
-[ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/index.html)
-[ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
-[ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
-[ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
-[ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
***
# Editing this README
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template.
Depot pour la mise en la mise en place d'une formation mutualisé IRD sur le thème de GIT.
## Suggestions for a good README
## Contributing
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information.
We welcome contributions from the community! See our [Contributing guidelines](https://forge.ird.fr/mivegec/dainat/isi-training-git/blob/main/CONTRIBUTING.md)
## Name
## Report bugs and issues
Choose a self-explaining name for your project.
## Description
Found a bug or have a question? Please open an [issue](https://forge.ird.fr/mivegec/dainat/isi-training-git/-/issues/).
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors.
## Badges
## Authors and acknowledgment
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation
XXX
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection.
## Usage
## Notes
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README.
## Support
Liste de supports d’intérêt sur lesquels s’appuyer:
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap
- https://coderefinery.github.io/git-intro/
If you have ideas for releases in the future, it is a good idea to list them in the README.
State if you are open to contributions and what your requirements are for accepting them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser.
## Authors and acknowledgment
---------------
Show your appreciation to those who have contributed to the project.
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers.
