[Israel.pm] Presentation request: workflow on github

sawyer x xsawyerx at gmail.com
Thu Sep 8 02:00:35 PDT 2011


On Wed, Sep 7, 2011 at 7:13 PM, Gabor Szabo <szabgab at gmail.com> wrote:

> On Wed, Sep 7, 2011 at 10:21 AM, sawyer x <xsawyerx at gmail.com> wrote:
> > On Mon, Sep 5, 2011 at 8:23 PM, Gabor Szabo <szabgab at gmail.com> wrote:
> >>
> >> 3) If you need to fix a project of someone else that is on Github,
> >> what is your workflow?
> >
> > I used to just open an RT ticket and try to add a patch. Nowadays, I'll
> go
> > straight to Github and search for their project (!github PROJECT on my
> > DuckDuckGo! toolbar), fork it, start a branch with the fix, commit and
> send
> > a pull request. I try to add tests, as it helps get it integrated much
> > quicker.
>
> That part is what is interesting to be
> so far I understood that you
> 1) for on the Github GUI
> 2) git clone your own fork to your machine
> 3) git co -b some_name
> 4) git cu -m "fix"  (several times)
> 5) ... ??
>
> but then I am not sure
>

1. !github Dancer
2. Click "fork" on the Dancer github page
3. In a local terminal, in my projects directory: git clone git at github.com:
xsawyerx/Dancer.git
4. Creating a branch of my own: git checkout -b feature/my-new-feature devel
(the "devel" at the end makes sure we're branching off "devel", which is the
development branch of Dancer)
5. git commit -m "adding bling" lib ; git commit -m "adding bling tests" t/
; ...
6. Pushing the branch to my clone on Github: git push origin
feature/my-new-feature
7. Going to Github, to my clone of Dancer and picking "Send a pull request"
Adding details about what my new feature is.
8. Once it is merged in Dancer, I can delete it locally and remotely:
git checkout devel # to leave the branch
git branch -d feature/my-new-feature
git push origin :feature/my-new-feature

If I don't pull the new merged versions of Dancer's devel, git won't allow
me to delete my branch because it isn't merged it. I can force git to merge
it (since I know it was merged into Dancer and I'll get it once I update
from upstream) by using -D (uppercase D, instead of lowercase D): git branch
-D feature/my-new-feature

It might seem like a lot but once you get used to it, it's hard to go back.
Mainly because it's *very* clean and makes it *much* easier to get your
stuff merged cleanly and most importantly - happily.


> > If there is no Github repo, I'll put a patch (or multiple patches of
> > consecutive commits) in an RT ticket on rt.cpan.org.
>
> There is https://github.com/gitpan  what do you think?
>

That's a good idea started by Schwern, but he hasn't updated it in a while.
I understood that Olaf Alders (of MetaCPAN fame) wants to update it, so
maybe after it gets updated we'll be able to use it to patch stuff.

I personally found that most projects to which I would want to contribute
are already on Github, and those that aren't I can just create a patch (or a
few patches) and put it with a ticket on rt.cpan.org.

Then again, YMMV, and I heard of at least one person who found patching
against gitpan very comfortable.


>  >> 4) How can the main author of the project handle the changes you pushed
> >> out?
> >
> > They can either apply the pull request, or apply the patches, or close it
> > and ignore me. :)
>
> I need the steps  slowly please :)
>

Suppose I get an email notification from Github saying that you pushed a
bling feature pull request to Dancer. Now I need to pull it. This can be a
delicate process, because of various considerations.

First, I would update my Dancer "devel" branch with all the latest updates:
$ cd $DANCER_DIR
$ git checkout devel # although I'm usually on "devel" anyway
$ git pull origin devel

Now I want to get your branch. I can either define you as a new remote and
pull your branch, or I can create a new branch and just pull your clone's
stuff in. Let's pick the second one:
$ git checkout -b feature/my-new-feature
$ git pull https://github.com/szabgab/Dancer.git feature/my-new-feature

Now I want to merge it in. However, I have to make sure that if I merge it,
I won't cause a problem. Sometimes people add a feature on top of code that
has changed over time. Suppose you added this branch last week and I just
got around to it today, perhaps someone else already merged stuff into
"devel". That makes your branch incompatible with the "devel" branch of
today. I will need to make sure your code is updated.
$ git rebase devel

Either one of three situations will occur:
1. You're already up-to-date, and git will say exactly that
2. There were commits done in "devel" after you made your commits, but it
would be trivial to rebase and it will do that and finish.
3. There were commits done in "devel" after your commits, and they conflict
with yours. Git will say there's a conflict and ask you to resolve it and
continue with "git rebase --continue".

Once things are up-to-date, I can merge your branch. Sometimes people make a
mess with their branches by pulling incorrectly, merging not in place and
other stuff. In that case I'll create another branch and cherry-pick the
commits I want from your branch. I'm assuming this isn't the case.
$ git checkout devel
$ git merge --no-ff feature/my-new-feature
$ git br -d feature/my-new-feature
$ git push origin devel

Done.

> Hope that helps,
>
> It did.
>

Yay! :)


> Does that mean you won't give this as a talk? :)
>

I'll be happy to give this as a talk. I'll have to consider how to explain
this in a way that won't be too confusing. I felt like I scattered a bit
with the Git talk.

Have a great day!
S.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.perl.org.il/pipermail/perl/attachments/20110908/21f3f7d0/attachment-0001.htm 


More information about the Perl mailing list