Question: Commit Individual Branches for GUI (Without using the Command Line)

Lately I’ve been doing some work with a project which lives on Github.  Last week I found a bug, so I put together a patch.

Since the package lives on Github, I followed instructions to put together a “pull request”:

  • I forked the main branch to my own Github account.

  • I checked out my fork.

  • I fixed the bug, and submitted the pull request.

Then I felt good about myself, and continued on with my work.  Today I tracked down another bug, unrelated to the previous one.  I know enough about git to know that I shouldn’t commit this fix to my fork, because it would then become part of the previous pull request.

So I created a branch within my fork, and committed the change there. But Github provides no way to create a pull request that only includes the new stuff!  Every attempt I made would have included everything from both bug fixes.

I’ve read online about creating a new branch based on the master copy, and “cherry picking” just the final change:  But it required the command line, and was not easy enough.

Okay, I know the solution:  I need to burn the whole thing down.  I’ll just create a new fork, and put the new bug fix in a branch there.

I can’t!  I don’t know if this is a Git restriction or a Github restriction, but it won’t let me create a new fork without deleting the old one.  I don’t know if deleting the previous fork would also delete the previous PR, so I’m not going to do this.

This is ridiculous!  It is such an easy concept:  I want to take the diff between my most recent commit and the one before, and send that diff to the owners of the master copy.  This should be a trivial (and it is in svn).

If I don’t misunderstanding, you can easily checkout to the first commit (with the hash code of that commit) of your fork and create a branch from that, then solve bug and create a pull request by this new branch to the master.

“Without using the command line” what does it means?

Hi @jtelleria,

This post was moved to a different board that fits your topic of discussion a bit better. This means you’ll get better engagement on your post, and it keeps our Community organized so users can more easily find information.

As you’ll notice, your Topic is now in the How to use Git and GitHub board. No action is needed on your part; you can continue the conversation as normal here.


The process to achieve the above that requires command line git would be as follows:

  1. Via GUI: fork or clone at gitlab so that you have URL to use in 2)

  2. Run
    git clone giturl…
    to fetch local instance

  3. Run
    git checkout -b feature/new_thing_a

  4. Edit, save, compile, test, revise, … leading to 1 or more commits

  5. Run
    git push origin
    standard configuration should have remote branch follow local branch, I
    think the “long form” is
    git push --set-upstream origin feature/new_thing_a

  6. Run
    git checkout -
    git checkout master
    and you are back in master. Now you can restart at my 3) above for
    branches b, c, d and create independent pull requests

I find it really to have a bash prompt that shows the branch:

edd@rob:~$ cd git/rcpp  
edd@rob:~/git/rcpp(master)$ git checkout -b feature/new\_branch\_to\_show  
Switched to a new branch 'feature/new\_branch\_to\_show'  
edd@rob:~/git/rcpp(feature/new\_branch\_to\_show)$ git checkout -  
Switched to branch 'master'  
Your branch is up-to-date with 'origin/master'.  
edd@rob:~/git/rcpp(master)$ git branch -d feature/new\_branch\_to\_show  
Deleted branch feature/new\_branch\_to\_show (was 5b25fe62).  

Do you mean that:

* Creating the new branch on the previous bugs (Other than in the new bugs), and doing a Pull Request on them.

Would allow me to fix the new unrelated bug, and do a pull request, without it being asociated to the whole master?

I might missunderstood…

Thank you.


A good practice in such case is that always you create a new Pull Request, you do it on a local branch