Github has its own App (for Windows I think), I never tried it
Your new PR is from your master branch again, I think this can be a trouble...
Your Timeline will be like :
- Code: Select all
Last Commit Sync'ed from DOL -> Your Commit -> Your Commit
When it's Merged Upstream, Official Repo Timeline will be like :
- Code: Select all
(Your Fork Branch) -> Your Commit -> Your Commit ->
(Official Repo) Last Commit -> -> Merged Pull Request Commit (two parents)
If you Try to merge Upstream to your master it will (...probably...) end up like :
- Code: Select all
Last Commit Sync'ed from DOL -> Your Commit -> Your Commit -> Merged Pull Request Commit (no change...)
The timeline won't match the one from Upstream/master... Git is not easy to grasp most users have trouble understanding how it works (I still use stack overflow and stack exchange to search for most basic features apart from checkout/push/merge)
Anyway your Fork will be different in Timeline (different Sha1 Hash for the snapshot right after last sync), and you won't be able to match the Upstream anymore, changing your timeline when rebasing will break your existing commit snapshots that's why you need to force push, force push means that if other users cloned your master branch they will be out of sync.
Git commits are like nodes in a binary tree, if the tree hierarchy don't match you can't provide Pull Request that contains only new nodes...
I suggest you don't use master for anything except to keep in sync with upstream.
Each change should be a new branch here is what I usually do :
- Code: Select all
// checkout an up to date master
$ git checkout master
// create a feature branch
$ git checkout -b my-new-feature
// ... change some code here ...
// Commit changes to the branch
$ git add .
$ git commit -m "Added: New features !!"
// push to Github (probably need some options to push a non-existing remote branch...)
$ git push origin
// Revert to master branch
$ git checkout master
// Start another feature
$ git checkout -b other-new-feature
// ... change some code here ...
// Rinse and repeat above...
Then go to Github website to create a pull request from the new branches only
The only downside is there won't be "my-new-feature" code in "other-new-feature" branch, so you can't work using the previous change you made (but this is intended by design, if "my-new-feature" don't make it to Upstream that won't prevent from merging "other-new-feature", you can probably branch "my-new-feature" to "upgrade-to-my-new-feature" if you want to expand on the previous code, but if the root node is not merged to Upstream other branches won't be able to make it either !)
If you want to keep a repository for your customized server containing changes that didn't make it to Upstream repository you should probably maintain a branch for it (branch dev or branch my-custom-server, you can even change your default branch from github website), then you should be able to cherry pick which changes you merge with your custom-server branch and if you make some research you should be able to extract and cherry pick changes to rebase them on Upstream/master for a proper pull request (but I admit I don't have the skills to do this, I'm not maintaining a custom server anyway...)