1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. If you would like to submit a tutorial please visit the main tutorial page here.
    You can not submit them from this forum.
    Dismiss Notice

How To: Submitting your Bug Fixes as Pull Requests on Github

Discussion in 'Tutorials' started by Toriad, Mar 6, 2014.

  1. Toriad
    Offline

    Toriad Shard Owner

    Joined:
    Mar 4, 2013
    Messages:
    86
    Likes Received:
    35
    Enjoy a Crappy Tutorial Video!

     
    • Like Like x 2
    • Winner Winner x 2
    • Two Thumbs Up Two Thumbs Up x 1
  2. Hank
    Offline

    Hank Active Member

    Joined:
    Nov 14, 2013
    Messages:
    972
    Likes Received:
    152
    Everyone should watch this video tutorial. *two thumbs up* I've never been involved in the github before and this taught me so very much.
    I love video tutorials. You did an excellent job making this.
    Toriad - "pick an easier name bro"
     
    #2 Hank, Mar 7, 2014
    Last edited: Mar 7, 2014
    • Agree Agree x 1
  3. Ravenwolfe
    Offline

    Moderator ServUO Developer

    Joined:
    Sep 7, 2013
    Messages:
    1,147
    Likes Received:
    123
    Great video! This info from Atlassian really helped also!

    Forking Workflow With Pull Requests
    In the Forking Workflow, a developer pushes a completed feature to their own public repository instead of a shared one. After that, they file a pull request to let the project maintainer know that it’s ready for review.

    The notification aspect of pull requests is particularly useful in this workflow because the project maintainer has no way of knowing when another developer has added commits to their Bitbucket repository.

    awww.atlassian.com_git_workflows_pageSections_00_contentFullWi2b84eb6afaf47efd313e2016c64075e7.png

    Since each developer has their own public repository, the pull request’s source repository will differ from its destination repository. The source repository is the developer’s public repository and the source branch is the one that contains the proposed changes. If the developer is trying to merge the feature into the main codebase, then the destination repository is the official project and the destination branch is master.

    Pull requests can also be used to collaborate with other developers outside of the official project. For example, if a developer was working on a feature with a teammate, they could file a pull request using the teammate’s Bitbucket repository for the destination instead of the official project. They would then use the same feature branch for the source and destination branches.

    awww.atlassian.com_git_workflows_pageSections_00_contentFullWi8d521f009510845da8a775ae760d479a.png

    The two developers could discuss and develop the feature inside of the pull request. When they’re done, one of them would file another pull request asking to merge the feature into the official master branch. This kind of flexibility makes pull requests very powerful collaboration tool in the Forking workflow.

    Example
    The example below demonstrates how pull requests can be used in the Forking Workflow. It is equally applicable to developers working in small teams and to a third-party developer contributing to an open source project.

    In the example, Mary is a developer, and John is the project maintainer. Both of them have their own public Bitbucket repositories, and John’s contains the official project.

    Mary forks the official project
    awww.atlassian.com_git_workflows_pageSections_00_contentFullWi5f062d8791b8d87bc59d6801182f4d2a.png

    To start working in the project, Mary first needs to fork John’s Bitbucket repository. She can do this by signing in to Bitbucket, navigating to John’s repository, and clicking the Fork button.

    awww.atlassian.com_git_workflows_pageSections_00_contentFullWi5c199206c0316c1ac267398d0edcb344.png

    After filling out the name and description for the forked repository, she will have a server-side copy of the project.

    Mary clones her Bitbucket repository
    awww.atlassian.com_git_workflows_pageSections_00_contentFullWi67629e6259dc6622d252406c1958e425.png

    Next, Mary needs to clone the Bitbucket repository that she just forked. This will give her a working copy of the project on her local machine. She can do this by running the following command:

    git clone https://[email protected]/user/repo.git

    Keep in mind that git clone automatically creates an origin remote that points back to Mary’s forked repository.

    Mary develops a new feature
    awww.atlassian.com_git_workflows_pageSections_00_contentFullWic21398a95e1b359eb98fca9cc78577d0.png

    Before she starts writing any code, Mary needs to create a new branch for the feature. This branch is what she will use as the source branch of the pull request.

    git checkout -b some-feature
    # Edit some code
    git commit -a -m "Add first draft of some feature"

    Mary can use as many commits as she needs to create the feature. And, if the feature’s history is messier than she would like, she can use an interactive rebase to remove or squash unnecessary commits. For larger projects, cleaning up a feature’s history makes it much easier for the project maintainer to see what’s going on in the pull request.

    Mary pushes the feature to her Bitbucket repository
    awww.atlassian.com_git_workflows_pageSections_00_contentFullWie3a1d760358753f0bec89d6ff75b0b2e.png

    After her feature is complete, Mary pushes the feature branch to her own Bitbucket repository (not the official repository) with a simple git push:

    git push origin some-branch


    This makes her changes available to the project maintainer (or any collaborators who might need access to them).

    Mary creates the pull request
    awww.atlassian.com_git_workflows_pageSections_00_contentFullWid2fe1dd9453b95abd539045cec85757d.png

    After Bitbucket has her feature branch, Mary can create the pull request through her Bitbucket account by navigating to her forked repository and clicking the Pull request button in the top-right corner. The resulting form automatically sets Mary’s repository as the source repository, and it asks her to specify the source branch, the destination repository, and the destination branch.

    Mary wants to merge her feature into the main codebase, so the source branch is her feature branch, the destination repository is John’s public repository, and the destination branch is master. She’ll also need to provide a title and description for the pull request. If there are other people who need to approve the code besides John, she can enter them in the Reviewers field.

    awww.atlassian.com_git_workflows_pageSections_00_contentFullWia1296a9dc08b6ab08e55baee7586fd56.png

    After she creates the pull request, a notification will be sent to John via his Bitbucket feed and (optionally) via email.

    John reviews the pull request
    awww.atlassian.com_git_workflows_pageSections_00_contentFullWib34ff71a8675276b343e8901e586be10.png

    John can access all of the pull requests people have filed by clicking on the Pull request tab in his own Bitbucket repository. Clicking on Mary’s pull request will show him a description of the pull request, the feature’s commit history, and a diff of all the changes it contains.

    If he thinks the feature is ready to merge into the project, all he has to do is hit the Merge button to approve the pull request and merge Mary’s feature into his master branch.

    But, for this example, let’s say John found a small bug in Mary’s code, and needs her to fix it before merging it in. He can either post a comment to the pull request as a whole, or he can select a specific commit in the feature’s history to comment on.

    awww.atlassian.com_git_workflows_pageSections_00_contentFullWiac8140e0d584e3b039a73cce29dc392c.png

    Mary adds a follow-up commit
    If Mary has any questions about the feedback, she can respond inside of the pull request, treating it as a discussion forum for her feature.

    To correct the error, Mary adds another commit to her feature branch and pushes it to her Bitbucket repository, just like she did the first time around. This commit is automatically added to the original pull request, and John can review the changes again, right next to his original comment.

    John accepts the pull request
    Finally, John accepts the changes, merges the feature branch into master, and closes the pull request. The feature is now integrated into the project, and any other developers working on it can pull it into their own local repositories using the standard git pull command.
     
    #3 Ravenwolfe, Apr 7, 2014
    Last edited: Apr 7, 2014
    • Two Thumbs Up Two Thumbs Up x 2
    • Informative Informative x 1
  4. Ravenwolfe
    Offline

    Moderator ServUO Developer

    Joined:
    Sep 7, 2013
    Messages:
    1,147
    Likes Received:
    123
    Ok, so I created a pull, you added it and I'm ready to work on the next thing. However, Denjiki has made some more edits and my fork is only showing 180 commits but the main is showing 200 commits. Somehow I am behind but I have no idea what I need to do to update my local files. My sourcetree currently looks like this:

    question.png
     
  5. Ravenwolfe
    Offline

    Moderator ServUO Developer

    Joined:
    Sep 7, 2013
    Messages:
    1,147
    Likes Received:
    123
    Nevermind, I think I got it by pushing to my origin.
     
  6. Hank
    Offline

    Hank Active Member

    Joined:
    Nov 14, 2013
    Messages:
    972
    Likes Received:
    152
    Bump - This is useful and can help people. Let it not be forgotten by the servuo community.

    Anyone can submit pull requests to the distro. ServUO is a community project. It's up to everyone in the community to help perfect it!
     
    • Like Like x 1
    • Two Thumbs Up Two Thumbs Up x 1
    • Agree Agree x 1
  7. Kilra Yan
    Offline

    Kilra Yan Member

    Joined:
    Aug 26, 2015
    Messages:
    284
    Likes Received:
    19
    I am in! :)
    I can now pull my requests: I already sent trammel.xml file with magincia cleant and relocated spawns, a small work to test if everything is fine.

    Happy to get this opportunity to contribuite more closely!
     
Similar Threads: Submitting Bug
Forum Title Date
ServUO Discussion "Phantom Mob" Bug? Oct 15, 2017
Archived Bug Reports Animate Dead Spell Bug Oct 15, 2017
Archived Bug Reports Imbuing resists are buggy Oct 13, 2017
Archived Bug Reports Valley of Eadon House Build Bug Oct 9, 2017
Archived Bug Reports Bugs with Send SpeedControl Oct 4, 2017
Archived Bug Reports Imbuing Bugs Sep 28, 2017
ServUO Discussion Add Bug Sep 20, 2017