Should I fork or pull a group project from Github to work on in Eclipse?

Question

I am working a group project for school and I am new to Git and Github. From what I understand about Github, when I 'fork' a repository I essentially create a copy of the project into my own Github account so that I can work on it independently. I also understand I can pull directly from the original repository that my group member made into my IDE and go from there.

If I 'fork' from my group member's repository, how do I update the fork with his changes if he were to make commits to it?

I guess my question is: in a small group project where we have split up the work, is it a better idea to setup Eclipse to pull directly from the main repository so I can easily pull and merge changes into what I'm working on --OR-- fork the repository and work independently on my own copy, then somehow merge any changes my group members make into my own fork, then push my changes when I've complete my portion?

Is this a personal preference to pull from the original repository directly into Eclipse or to 'fork' the repository into my on Github account, then work from there? Is it better practice to do one over the other?

I can probably figure out how to do it both ways via online tutorials, but I'm not sure which route to take.

All help is appreciated.

Answer 1

For small groups recommend using option 2 below and submitting changes on pull requests

Essentially two options:

1. fork - read how to pull upstream changes here clone w/ pull. This approach is used when the project owners want to have control of how changes enter into the project. For a class project that's probably not necessary.
2. clone - use feature branches & pull requests to manage changes (few more details below)

A git workflow for a small team might look like the following. You can read more details here

• clone the team repo to your local workstation
• pick a feature to work on and create a branch to work on the feature
• make lots of messy commits until you have something ready to send to the team repo
• pull down upstream changes from the team that get committed to master and rebase your feature branch to incorporate those as needed
• rewrite your commit history with git rebase -i origin/master
• create a pull request to be merged into master

Answer 2

The way we work on stuff and work, and thus the way I would work on it for personal projects is as follows:

• Clone the main repository (no fork).

• Checkout a new branch where you are planning to do all of your work.

• When you're done checkout the main project branch (probably master, at work we use develop)

• Run a git pull origin master (or whatever the main branch name is)

• Checkout back to the branch you made all of your changes to.

• On your branch run a git rebase master, this will run all of your changes on top of whatever is on master.

• Then do a git push origin 'your new branch name'

• And finally, once the branch has been pushed to the main repo, submit a pull request.

This is a great way to keep a linear set of changes, and it works very well.