First login?
Lost password?
 
 
 
General mailing list for discussions and development of PeerLibrary and related software.

List archive Help


Re: [PeerLibrary dev] Regular development


Chronological Thread 
  • From: Mitar < >
  • To:
  • Subject: Re: [PeerLibrary dev] Regular development
  • Date: Tue, 10 Sep 2013 14:13:26 -0700
Hi!

Ah, I forgot. The idea is that we teach others in this way better
programming. Everyone has different experience and by code reviewing we
can help each other to become better programers.

And remember, somebody commenting on your code is a good thing. This is
a comment of the code, not of you as a person.


Mitar

> Hi!
>
> We started working regularly in person on Mondays, Tuesdays, Wednesdays
> at 8 PM in BiD lab:
>
> http://bid.berkeley.edu/
>
> We started using pull requests for internal development as well, so you
> can follow progress on various features online on GitHub:
>
> https://github.com/peerlibrary/peerlibrary/pulls
>
> (You can check closed pull requests for already merged pull requests as
> well.)
>
> So in short, the idea is that whoever starts working on a feature in
> PeerLibrary, makes:
>
> - a branch (called feature branch) where only the commits related to
> this one planed feature or fix or whatever will be
> - pushes the branch to GitHub PeerLibrary repository (no need to use
> your fork)
> - makes a pull request from that branch to master branch of PeerLibrary
> repository
> - then others can review the code, put comments and so on
> - when somebody else agrees that the code is OK and that is ready to
> merge (by commenting LGTM (look goods to me)), a person who opened the
> pull request can (if he or she things it is ready as well) merge it into
> master
>
> So the main idea is that the same person both opens and merges the pull
> request (he or she knows if this is all that was planned for this pull
> request). And in meantime others can comment and review code.
>
> Command line git commands for all this should be learned. If there are
> some issues with that, the best is to show them in person. Or we can
> write a guide as well.
>
> One mine suggestion is also to not be afraid to have PeerLibrary cloned
> multiple times locally, for example, for each branch. It is much better
> to have each branch in its own local clone than to try to switch between
> branches in one directory. It can get quite messy sometimes (with files
> git is not tracking especially).
>
> We are loosely basing our development on this model (we don't yet need
> master/develop distinction because we have not yet released anything):
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> I hope this will make the whole development more open and easier for
> others to join. If you have any questions, just ask.
>
>
> Mitar
>

--
http://mitar.tnode.com/
https://twitter.com/mitar_m

Archive powered by MHonArc 2.6.18.

Top of page