DevHowTo
If you are interested in contributing to the TypeCobol project, but you don't belong to the TypeCobolTeam organization, you have to use Github pull requests feature. This is how it works for our project:
- Create an issue describing what you want to do, labelling this issue with the proposal label. Discussion ensues. If accepted by the TypeCobol Team, the issue gets the enhancement label (see Issues lifecycle for more details).
- Fork the TypeCobol Repository.
- Hack the code as desired. Altough it is not mandatory, we suggest you do it in a branch of your repository: this allows you to work on different features inside a given repository. Don't forget to implement unit tests!
- Open a pull request.
- Your pull request will then be analyzed by TypeCobol Team members at the earliest opportunity.
- If your modification is all good, a TypeCobol Team member will Merge your pull request.
Discussion between you and the TypeCobolTeam members will ensue. This discussion can happen either:
- in the issue ticket you created in step 1.
- directly in the pull request
- directly under specific lines of code
We will hopefuly be able to solve together the points preventing your pull request to be merged as is. That's how social programming works!
When you submit your code to our repo, giving credit where it's due is the least we can do.
In any case, the issue and pull requests page will leave no doubt that you are the real author of a given feature or bugfix.
You should appear in the repository commits history, too. However, due to git inner workings, this can be more tricky than it seems.
If your PR can be merged with our master's HEAD without any conflict, you will directly appear in the repository commits history. There will be a "merge commit" by the TypeCobolTeam member who analysed your pull request, but the commit(s) grouped in your pull request will be yours.
In practice, that's how we do it:
git checkout -b <local branch> master
git pull --no-ff <url of your fork> <branch of your PR>
git rebase master
git checkout master
git merge --no-ff <local branch>
git push
git branch -D <local branch>
And this is how it will look like:
laurentprudhon's pull request could be merged without any conflict by wiztigers.
If your pull request cannot be merged "as is" because of conflicts between our master's HEAD and the code proposed by your pull request, we'll have corrections to do. In many cases, this will mean solve conflicts in a way that prevents your original commits to be kept untouched.
That's why it is always better that you make sure your pull request can be merged in our master without any conflict.