Using Github With a Team

Last week we got a chance to develop a full stack website in class. It was very rewarding and quite the learning experience. We were a group of four people — four personalities at work on a single vision….well for the most part. This was our second project but our first working with a group or “team”. Being able to work with a team while being ablee to be a team player is just as valuable as being a good developer.

What is Github? Github is a version control systems that keeps revisions straight, storing the modifications in a central repository. This allows developers to easily collaborate, as they can download a new version of the software, make changes, and upload the newest revision.

One of the most valuable lessons I learned throughout our project was how to work with Github using a single repository. Seems pretty simple correct? Well so we thought so — then came the merge conflicts —

So I thought I would share some valuable information that I learned along the way:

1.Have a single person be the administrator of the repository — they should have sole access to git to the master repo. If you aren’t the administrator clone the repo to your computer.

2. Anytime you are working on a specific file create a branch and name it something that is specific to what you are working on. (or if you have already created that file make sure to switch to the branch that you would like to continue to work on.)

$ git checkout -b branchName

3. If you aren’t the administrator and you have forked the repo you’ll want to create an upstream. This will enable you to push your new code to Github where it can then be merged with the master.

  • origin is your fork: your own repo on GitHub, clone of the original repo of GitHub
  • upstream generally refers to the original repo that you have forked.

4. Anytime you are getting ready to push your new code ALWAYS pull from master! ALWAYS pull from master — this ensures that you have up to date code and it lowers your chances of having conflicts.

5. Once you have pulled and have the most current code — push your branch to upstream master — where it will be sent to the master repo and be reviewed before getting merged.

Communication is key with working in a group or team. Organizing and delegating how your repo will work will help with any future conflicts you may encounter. It seems they will always occur no matter the skill level of the developer. So communicate, communicate, communicate!

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.