
GitHub Fork and Pull Request Workflow - Quick Reference Guide - susam
https://github.com/susam/gitpr
======
zie
I just wish they would also support patches. Forcing us to fork and merge back
just for GitHub is annoying. Especially for quick drive-by type patches and
smaller doc changes and just minor fixes.

I git clone'd the project, built it, noticed something small, fix it locally,
and then decide OK I'll just send this up real quick. oh crap. NOPE I have to
do a bunch of GitHub crap with forking and merging to get it back to the
master tree. Annoying.

Forking and merging is perfectly fine for regular contributions, but for
smaller one-time type fixes it's just annoying.

~~~
zoul
FWIW, for smaller drive-by fixes you may press the Edit button directly on a
file in some else’s repo.

~~~
bastawhiz
And in truth, the "github crap" is clicking "Fork" and running "git remote
add". Pushing and filing a PR are the same process.

~~~
lozenge
Except your fork now prominently appears even after the PR is merged. However,
I don't think Github has a way to see all your PRs.

~~~
shlomi-noach
Here's how to see all your PRs:

[https://github.com/search?q=is:pr+author:YOURNAME&type=Issue...](https://github.com/search?q=is:pr+author:YOURNAME&type=Issues&ref=searchresults)

Here's how to see all your open PRs:

[https://github.com/search?q=is:pr+is:open+author:YOURNAME&ty...](https://github.com/search?q=is:pr+is:open+author:YOURNAME&type=Issues&ref=searchresults)

Replace YOURNAME with your GitHub handle, or pick your colleagues names.

~~~
zie
Nice, thanks!

------
foo101
There are two different methods to merge pull requests in the article. When do
people prefer one over the other?

Are there any good reasons why someone should try to rebase and merge (fast-
forward) a pull request to avoid a merge commit? It involves more steps than
the method which creates a merge commit. What benefits warrant these
additional steps?

~~~
rahkiin
I have found that rebasing often creates more issues than it is worth it. Only
when there are only a couple of commits I might try but you are still
rewriting history: something that is destructive and needs force-pushing which
I almost always disallow.

Merging does create a merge commit which is sometimes annoying (when you are
merging a single-line commit, for example). It does however preserve full
history.

~~~
u801e
> It does however preserve full history.

Frequently, I see a commit history like:

    
    
        Implemented feature
    
        Forgot semi-colon
    
        Fixed syntax error
    
        Addressing review comments
    
        Removed unnecessary method
    

History like that, other than the initial commit, is not very useful. It makes
more sense to rebase to clean up the commit history such that it becomes a
logical series of commits, which can then be viewed via git log or git blame.

------
whatastorymark1
Semi-related question: Assuming I drafted up a software license with generally
permissive terms (freedom to use, modify, sell, etc.), but included some
perverse clause that would forbid forking (such as only allowing the software
to be distributed from the canonical repository on my profile), would I have
legal grounds to request repository removal from GitHub if someone pressed the
repo's fork button?

~~~
carreau
Yes, when you created a GH account, you read and accepted the TOS, which
enforce your project must be forkable.

~~~
whatastorymark1
Interesting, thank you!

Relevant excerpt:

> If you set your pages and repositories to be viewed publicly, you grant each
> User of GitHub a nonexclusive, worldwide license to use, display, and
> perform Your Content through the GitHub Service and to reproduce Your
> Content solely on GitHub as permitted through GitHub's functionality (for
> example, through forking).

For those interested, GitHub's entire TOS is written in a very approachable
way.

[https://help.github.com/articles/github-terms-of-
service/](https://help.github.com/articles/github-terms-of-service/)

------
asmdev
After we merge a pull request with rebase + fast forward merge, there is no
merge commit created. This leads to a linear commit history.

Does anyone know anyway to look at the linear commit history alone (not
GitHub) and tell where a pull request was merged and who merged it?

~~~
gonewest
Git tracks the committer and the author separately: you should see the “who
merged” preserved as the committer and the “who wrote it” as the author.

If each commit notes the issue number in its comment (“Add indentation and
trailing white space check to CI [#123]”) then you can see easily when each
merge occurred by issue number.

Additionally in GitHub there are conveniences built from these little
conventions. The “#123” is displayed as a hyperlink to the issue, and merging
a commit that has “Fix #123” automatically closes the issue.

In cases where a feature is big enough to justify multiple commits for
clarity, you can mention “#123” in all but the last commit, and “fix #123” in
the final commit. Doing so partitions the linear history.

In fact, if someone else notices and fixes a regression caused by the merge,
they can push additional commits later on but mention “#123” in their commit
as well for documentary purposes. Seeing downstream commits “out of sequence”
but with some earlier issue number is a clue this was probably a regression.

~~~
foo101
This is true only if the merge operation leads to a new commit or altering of
existing commits. But your parent comment was asking this question for merge
operation where there is no new commit.

The person who merged the commit appears as the committer name only if the
rebase led to a change in the SHA1 hash of the commit.

If the pull request branch is already based on master and up-to-date with
master, then "git checkout master; git merge pr" performs a fast-forward merge
without altering any commits. The SHA1 hash of the commits in the pull request
do not change. The merger's name does not appear anywhere because the merger
has not done anything except fast-forwarding master.

