search

stat157 / questionnaire

Stat 157 Questionnaire Data Wrangling
1 stars 23 forks source link

Suggested Workflow: Shared Repo? #33

Closed teresita closed 10 years ago

teresita commented 10 years ago

Goal: Efficient Workflow

I'm looking for suggestions from classmates/instructors on how our group should collaborate and share code. We will of course be pushing our code to GitHub, but what are the merits of contributing to a shared repo vs submitting pull requests to one member?

Group Control vs Administrator

Currently, one of our group members created a repo and is the sole contributor (the only one with write access). We fork, clone, modify, push, and submit a pull request. It's a lot of work, and it might make merging somewhat more difficult, but it's nice to have someone who can review your code before approving the pull request.

I'm thinking that a shared repo might be better because we can push to it in real-time without waiting for the approval of a pull request; that is, we all have write access to the repo, we each edit code on branches, then merge those branches to master once we've completed a task. The control is distributed, though, so it seems like it might be easier for one group member to make mistakes.

Thoughts?

kqdtran commented 10 years ago

My $0.02 (:D): Usually, fork and pull request work well for open source software because you don't really know who is going to contribute on your project. It could be a friend, or it could be some random guy from Antarctica... In that case, you don't really want to give them full access to a shared repo, and having the fork + pull request workflow is nice because, like you said, you can review the code before merging it to the main branch.

As a small team, however, I think having a shared repo is better. You basically know who is going to push the code, so it's easier for them to get direct access to it. Plus, the point of every version control system is to allow people to, well, version control the code :D. Mistakes can't be avoided, but it will be fairly painless to revert back to an earlier version or nuke a commit if somebody on the team makes a mistake.

That said, having a shared repo can cause a lot of merge conflicts. More than often, two or more team members will be working on the same file, and bam!, git complains. The best way to avoid this, IMO, is to have each team member working on a different file (or the same file but on different branch), and always do a git pull before pushing anything.

teresita commented 10 years ago

@kqdtran thank you for the input! very helpful.