GIT HUB PROJECT WORKFLOW

Collaborators

1. To start off, we need a project to collaborate on. In order for this to work, you and everyone in your group will need to know their GitHub username and GitHub password, and will need access to the email account they used to sign up for GitHub.
2. First, in your group, designate one person the "owner" of the project, and designate everyone else a "collaborator".
3. Next, find one of Upperline Code's template repositories and click the "Use This Template" button. Name the project something unique.
4. Then, owner of the repo, add your group members as collaborators.
5. Finally, everyone clone the project down.

Branches

Different copies of the same project by folks working on the same team are called branches. Every project starts out with a "master" branch, which is the main one, but as you and your team need to add features without breaking your main project, you'll add more branches.

Normally a branch is associated to a specific feature or update, and once the feature is finished and merged back to the main or master branch, that feature branch is often removed (or "pruned"). However, when you're just starting out, it's helpful to use a simpler structure, so we're going to name our branches after the person whose environment that branch lives on.

Getting started

Assuming both the owner and collaborator have cloned the repo, and that the collaborator has been given access to the repo, you're ready to create branches.

1. Create Your Branch - DO THIS ONE TIME ONLY

where branch-name is replaced with your name (or any name for the branch you're working on).

2. Make a change.

The easiest change to make at this time to avoid a merge conflict is for both you and your partner to add a new file.

3. Commit those changes.

Once you've made a change, follow the usual workflow to commit those changes.

Where filename is the name of the file or files you'd like to commit, and "description of changes" is an actual description of those changes.

4. Push those changes up!

Normally pushing changes is pretty simple:

However, you are likely to get an error telling you that there is no specified remote branch on GitHub for you to push it to. It will prompt you with code you can use to CREATE that branch.

Run the code exactly as prompted in the terminal, and you'll see that your changes are on GitHub, but are only reflected on your branch - not on the master branch. You'll only need to do this once. After the first time, git push will assume you want to push to the remote branch that corresponds to the one you're working on locally.

5. Merge the changes in

Finally, it's time to create a pull request on GitHub and merge the changes back in to the master branch. It's typically good practice to have one person CREATE the pull request, and the other person MERGE the pull request, that way one person isn't unilaterally pushing in changes that might break the project.

At this stage, if you and your partner edited the same file, you might have a merge conflict. A merge conflict looks somewhat complicated, but is actually really simple to solve on GitHub. There's a browser-based tool that simply says "I found two versions of the code at this point - which version should we keep?" and once you answer all those questions, you can finish the merge.

6. Pull the merged version down.

Once both you and your partner's code has been merged to the master branch, you and your partner will each want to pull the merged version of the other's code from the remote master down onto your local branch.

If BOTH partners added, committed, pushed, and merged, this part should go without error. If not, you may have to resolve merge conflicts locally.

7. Push it back up (just to sync everything).

Finally, once all this is set up, push your local, merged code back up to your remote branch.

This should make it so that your remote code is caught up to your local code, and you'll be ready to continue on.

8. Repeat steps 2 to 7!