How do I continue development once my pull has been applied, without using the pull request
I'm having troubles phrasing this clearly, but I'll give it a shot.
- I forked a Repository as my master then cloned it locally.
- Made my changes, and sent a pull request.
- The pull request has been closed, and has been "added manually" (patch and apply).
- I don't care about keeping minor differences.
- I want my code to be easily pulled in the future.
- I don't want to lose history (mine or upstreams).
- Will the solution cause me issues with developing in the future?
- is there an easier way?
- Should I just rename this branch (somehow) and start afresh?
- (somehow) sync the rename locally and work from a new master?
- Should I now forget using branches named master as this will cause me issues?
Github's in question:
Well, the easiest thing if you don't want to lose your history is to always create a feature branch where you work on your pull request.
In your case (if you want to keep your history), create a new branch
git checkout master git checkout -b my-old-feature
Then, just reset your master branch to whatever point is the upstream master branch
git remote add upstream <upstream-repo-uri> git fetch upstream git checkout master git reset --hard upstream/master
There you then have a clean state and your master branch will be exactly the upstream one. In the future, just always keep master branch following the upstream/master one, and work on feature branch you create to prevent collision with upstream updates.
edit: By the way, I always prefer to have my branches named the same as the upstream. But you can also track upstream/master on another branch name. For example:
git pull upstream master:upstream-master
Hope this help!
Do you mean you have additional commits on your fork that aren't in the pull request, and you want to shift them over to the new master?
Use git-rebase, with the caveat that you should really only rebase if you know what it's doing:
git rebase --onto upstream/master A B
Here, A should be the last commit in your pull request, and B should be the name of your local branch (which is probably master).
This will iterate over all the commits that come after your pull request and "replay" them, one at a time, on top of upstream's new master. By "replay" I mean git is literally generating a patch from each commit, applying it to the code, and making a new commit with the same date/author/message as the original. You'll have the same changes arranged the same way, but the commit hashes will be different. (So don't do this if anyone else has branched off of your branch!)
Another way to do the same thing is to create a new branch based on upstream, then git cherry-pick the commits you want to keep. This does exactly the same thing, replaying the commits, except you bring arbitrary other commits into the current branch rather than moving the current branch somewhere else.