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

List archive Help


[PeerLibrary dev] Regular development


Chronological Thread 
  • From: Mitar < >
  • To: PeerLibrary development < >
  • Subject: [PeerLibrary dev] Regular development
  • Date: Tue, 10 Sep 2013 14:08:42 -0700
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