---

13.12.3 Production workflow

Fortunately ‘Pro Git’ has done a wonderful job in explaining the different workflows in Chapter 5²⁸³ and in particular the “Integration-Manager Workflow” explained there. The implementation of this workflow is nicely explained in Section 5.2²⁸⁴ under “Forked-Public-Project”. We have also prepared a short tutorial in Forking tutorial. Anything on the master branch should always be tested and ready to be built and used. As described in ‘Pro Git’, there are two methods for you to contribute to Gnuastro in the Integration-Manager Workflow:

1. You can send commit patches by email as fully explained in ‘Pro Git’. This is good for your first few contributions. Just note that raw patches (containing only the diff) do not have any meta-data (author name, date, etc.). Therefore they will not allow us to fully acknowledge your contributions as an author in Gnuastro: in the AUTHORS file and at the start of the PDF book. These author lists are created automatically from the version controlled source.

   To receive full acknowledgment when submitting a patch, is thus advised to use Git’s format-patch tool. See Pro Git’s Public project over email section for a nice explanation. If you would like to get more heavily involved in Gnuastro’s development, then you can try the next solution.

2. You can have your own forked copy of Gnuastro on any hosting site you like (Codeberg, Gitlab, GitHub, BitBucket, etc.) and inform us when your changes are ready so we merge them in Gnuastro. This is more suited for people who commonly contribute to the code (see Forking tutorial).

In both cases, your commits (with your name and information) will be preserved and your contributions will thus be fully recorded in the history of Gnuastro and in the AUTHORS file and this book (second page in the PDF format) once they have been incorporated into the official repository. Needless to say that in such cases, be sure to follow the bug or task trackers (or subscribe to the gnuastro-devel mailing list) and contact us before hand so you do not do something that someone else is already working on. In that case, you can get in touch with them and help the job go on faster, see Gnuastro project webpage. This workflow is currently mostly borrowed from the general recommendations of Git²⁸⁵ and GitHub. But since Gnuastro is currently under heavy development, these might change and evolve to better suit our needs.