Hi
I have made a few changes to my own server on certain standard doctypes and I feel its perhaps something that other user would like.
I have been reading up about doing PR.
- Seems the first step would be to create fork onto my own repository.
- This leads me to my first question : is it best to fork the production branch or the
develop branch ?
- Do I then sync ( push --force ) my local code onto the forked repository ? I seem to
recall trying this, and github would not allow me to ?
- I then create a PR, referencing my fork ?
You’re on the right track with the general steps for contributing via a Pull Request (PR). Here’s a breakdown addressing each of your points:
-
Forking the repository
Yes, the first step is to fork the Frappe (or ERPNext) repository into your own GitHub account. This gives you your own copy to work with.
-
Which branch to fork from
It’s best to base your changes on the develop branch, as that’s where active development happens. The version-XX or main/production branches are generally for stable releases, so PRs should go to develop unless explicitly stated otherwise.
-
Syncing your code to the fork
You don’t need to use --force unless you’re rewriting history (which isn’t usually needed for standard PRs). Instead:
-
Clone your fork to your local machine.
-
Create a new branch from develop (e.g., feature/my-change).
-
Make your changes and commit them.
-
Push this branch to your fork:
git push origin feature/my-change
If you were trying to push changes to the original Frappe repo directly (rather than your fork), GitHub would reject it — only maintainers have that access.
-
Creating the PR
Once your branch is pushed to your fork, go to GitHub and you’ll usually see a “Compare & Pull Request” button. Make sure the PR is targeted from your branch on your fork → to the develop branch on the original Frappe repo.
Let me know if you need a step-by-step with Git commands or help resolving any specific errors!
Thank you @Hardik_Zinzu for your post. Greatly appreciated !
Okay, I shall start with the process. So far I have simply worked on an installed
version of the code. So I will have to build another server and then, instead of
doing a get-app , install-app, I will have to clone my fork.
Another question that has just popped into my mind …
There are three things that I want to achieve…
- A bug-fix
- Small addition to some functionality
- a brand new doctype
Is it fine to take this a step at a time i.e…
first push the bug-fix and do a PR
and then push the new functionality and do a PR
and then finally add the new doctype and to the last PR ??
IF I get stuck with the github commands , I shall make use of your offer. Thank you.
Create different PR for Bug fixes and new feature. Please mark answer as solution. So others can refer it.
Update…
Would like to check the last step in this procedure…
After pushing the changes to my own repository, I go to my own
repository and goto > Contribute > Open pull request
This then opens a dialog with a title and in the title I put “Closes : #123”. With 123 being the issue nr ?
And in the description I describe the changes ?
Thank you
Edit …
Also, once I have done a PR , this make my repository 1 commit ahead of the
parent repository. If there are merges on the parent repository, hwo do I sync
my repository with the parent again ?
Update …
Okay, I found the answer to the last question …
I see there is a “Sync fork” button on my repository.
That problem solved.
Update …
I have been reading up about how to do this correctly …
IT seems I have to …
- Be specific when I do the commit i.e. when I issue the "git commit -m " I have to be
specific … git commit -m “fix: fixes incorrect rounding in invoice”
- ANd then I do the same when I complete the PR …
Goto my repository Goto > Contribute > Open pull request > Dialog with title and
Body … then the title must be the same “fix: fixes incorrect roundign in invoice”
and then in the body I should give any detail around the fix
Am I interpreting the docs correctly ?
Would appreciate some guidance. I would like to do this correctly.