GitHub pull request and current branch

kfrajer

What do ppl do after they submit a pull request and it is process... ok, let's backtrack. What I do in GH:

1. I fork the repo of interest into my account
2. I clone from my account to my local
3. I make changes, comit and push to my account
4. Then from my account I do a pull request.

If that what most ppl do? After you do the pull request, do you stop working in this branch and create a new one? Is it common then to erase the copy in the local dir and in my GH account? Advise, comments, do & don't 's are welcome....

Kf

GoToLoop

Actually I've never done pull requests locally. I did everything directly in the browser at GitHub! =P~

It's gr8 for tiny edit fixes. \m/
But when it's a lil' bigger, I simply copy the whole raw file to some editor program.
Once finished, I pasted it all back into the browser again. :ar!

I confess I rarely delete my forks when it's all set. No problem accumulating them.
However, if it's starting to get outta hand, we should probably start getting rid of them. 3:-O

jeremydouglass

@kfrajer -- they way that you describe is common.

1. fork processing into gihub account
2. clone to local computer(s)
3. create a branch of what you are doing e.g. "lerpWidgets" (optional)
4. change, commit, push branch to your fork
5. pull request (optionally, from your named branch)

Delete the branch, or not. Keep the fork, or not.

...time passes...

1. pull to update your existing fork -- or just delete and refork
2. pull to your existing clone on local computer -- or re-clone
3. create a branch e.g. "PShape.set"
4. change, commit, push
5. pull request

kfrajer

Thanks for your comments. I have one scenario and I would like to hear your feedback:

• I forked a repo labeled RepOriginal in GitHub to my account, labeled now RepForked

• I clone RepForked to my pc, so I get RepCloned

Then I do this:

• I make changes directly in RepForked so now I have RepForked-2.I merged RepForked-2 to RepOriginal.

• I make changes to RepCloned so now I have RepCloned-2

Could I now [1] merge RepCloned-2 to RepForked-2 by doing a push? [2] Or would you pull RepForked-2 into RepCloned-2 so turning the latter to RepCloned-3? Then push to my repo before merging to original? [3] Would it be better if I push to a new branch in my GitHub and then merge to the original repo?

I am sure there is a proper way to do this. I also see this more of an exercise to explore "do and don't" actions managing repos. There is also the idea of "not do that"... I am more interested to know about alternatives and thoughts of non-easy and non-standard merging processes.

Kf

kfrajer

To answer my own question,

To summarize, I have three versions:

• RepOriginal
• RepForked-2 (Modified directly in GitHub and on the pull request queue of RepOriginal)
• RepCloned-2

I proceeded as follows: I did a pull from origin to pc. So git did a smart merge:

"git pull origin master" Results in RepCloned-3

Now I update the repo in my GitHub account with "git push origin master" so technically my repo in GitHub (the one that was forked from RepOriginal) is different and I should called it RepForked-3. Now I should create a pull request to merge this repo (and its latest changes) to RepOriginal. However....

I don't have to do that. Because I created a pull request early with RepFoked-2, then after I merged my local PC with my online GitHub account, GitHub automatically detected the changes and updated my last pull request to include my first commit (from RepForked-2) and the changes from RepCloned-2. Of course, this works great since my initial pull to RepOiginal was still pending in queue.

GitHub is a very neat tool.

Kf

jeremydouglass

@kfrajer -- It seems like you've got it worked out. To underscore this at a more general level -- there isn't one proper way of doing this. Choose a workflow that works with your project / source or for you personally.

Here is a generic intro to workflows with github:

• https://guides.github.com/introduction/flow/

...and here is a detailed guide to comparing different workflows:

• https://www.atlassian.com/git/tutorials/comparing-workflows

Branches are cheap, fork as many as you want, and merge where it makes sense for the type of collaboration you are doing, the type of records you are trying to keep, or what you want to share with audiences. Note in particular the first example of how more pushing to a branch can continue during an open pull request.

kfrajer

Note in particular the first example of how more pushing to a branch can continue during an open pull request

Neat @jeremydouglass, that is exactly what I just figured out. I will revise these links for sure. Thxs for sharing. I just did it this way as I described it above to try @GoToLoop's approach and then I thought I found myself in trouble. Really good exercise....

Kf