Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion source/coding/git.rst
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ The goal will be to work on your computer and save your changes to **your** fork

By default all repositories have a main version of the code (a branch called *master* or *main*). When you are exploring new pieces of code, fixing bugs or tinkering in general you should always create a branch first (with a meaningful name) to avoid messing up your main branch with your tests :bash:`git checkout -b my_branch`. Your main branch in **your** fork should always stay the same as the main branch in the **upstream**. A good practice is to never use :bash:`git add` or :bash:`git commit` in your main branch: only :bash:`git pull upstream master` (or main).

If your modifications are useful, and you want to keep it safe, you should commit and push them. If your modifications of one branch of your own fork to be added to the real scilpy repository (upstream)could be useful to everyone and you want to share them with the rest of the world [2]_, you should consider doing a *pull request*. Only when everything is clean and tested, in the Github web interface, you can start an official pull request that will be reviewed by other members of the lab.
If your modifications are useful, and you want to keep it safe, you should commit and push them. If your modifications of one branch of your own fork to be added to the real scilpy repository (upstream) could be useful to everyone and you want to share them with the rest of the world [2]_, you should consider doing a *pull request*. Only when everything is clean and tested, in the Github web interface, you can start an official pull request that will be reviewed by other members of the lab.

When that branch is accepted and merged to the master branch of the upstream, then if you update **your** own master branch of **your** fork (:bash:`git pull upstream master`), you will see the changes. You will then be able to delete safely your branch in your fork (:bash:`git branch -d my_test_branch`).

Expand Down
Loading