Collaborative git

Joel Ross
Winter 2020

INFO 201

Late Days & Groups

I have adjusted the course syllabus to clarify policy around using late days for the group final project:

 

  • "Group assignments require one late day per group member for each 24h used."
    (treat group days as a pool)
     
  • You may use late days on the final project

Peer Evaluations

"What happens if someone doesn't contribute?"

We determine contribution level based on evidence available to us:

  • Peer evaluation surveys
  • Git commit history

Evaluating Teamwork

Consequences: Categorize contribution into categories:

  • Contributed above and
    beyond their fair share
  • Contributed their fair share
  • Contributed a little less than
    their fair share
  • Contributed a lot less than
    their fair share
  • Did not contribute

 

  • +5% adjustment
     
  • no adjustment
  • -5% to -10% adjustment
     
  • -25% adjustment
     
  • no credit,
    probably kicked out of group
    (and need to do project alone)

Questions about groupwork policies?

Today's Objectives

By the end of class, you should be able to

  • Use git branches to track different versions of your code
     
  • Merge changes between branches
     
  • Resolve merge conflicts
     
  • Use git to collaborate with a team of programmers

Code for Today

https://github.com/info201a-wi20/branch_practice

FORK and clone this repo!

Using GitHub

edit files

staging area

git add
git commit

starter repo

your copy

git clone

your machine

fork

git push

Commit History

"First"

 git commit -m "First"

"Second"

"Third"

"Fourth"

 git commit -m "Second"
 git commit -m "Third"
 git commit -m "Fourth"

Git history has been a linear sequence of commits.

HEAD

Why Non-Linear?

  • What if we want to try something new and crazy without breaking code that we've already written?
     

  • What if we want to work on two different features simultaneously?
     

  • What if we want multiple people to work on the same code without stepping on each other's toes?

Branches

Branches allow for non-linear commits.

master

master

master

master

experiment

bugfix

experiment

experiment

Branch Commands

 git branch

List available branches

 git branch [my_branch]

Create a new branch called "my_branch"

 git checkout [my_branch]

Switch to branch "my_branch"

 git checkout -b [my_branch]

Create and switch to branch "my_branch"

 git branch -d [my_branch]

Delete branch "my_branch"

Branch Practice!

  1. Open the README.md file (in Atom)

  2. Create and checkout a new branch called experiment

  3. Add another item to the end of the list

  4. Add and commit your change

  5. On Windows: close the file in Atom

  6. checkout the master branch

  7. Add yet another item to the beginning of the list

  8. Commit your change

  9. Switch between the experiment and master branches (clicking on Atom in between). See the file contents changing?

Branches

master

master

experiment

experiment

HEAD

HEAD

HEAD

HEAD 

git branch experiment

git checkout experiment

git commit

git commit

git checkout master

git commit

git checkout experiment

HEAD

HEAD

experiment

HEAD

Merging

We can merge two branches back together, producing a commit that contains the combined changes from both branches

master

master

experiment

HEAD

HEAD

Merging

 git merge [other_branch]

Merges changes from other_branch into the current branch.

A new commit is created on the current branch containing the merged content.

Merging Practice

  1. Make sure you are on the master branch
    (use git branch to check; the current branch has a *)

  2. Use git merge to merge the experiment branch into master branch.

    • If you get dropped into vi, hit :wq (colon then w then q) to accept the message.

  3. Check in Atom that the file now contains both sets of changes!

Merging Practice II

  1. You should be on the master branch.

  2. Create and checkout a new branch called danger

  3. On the danger branch, change the word "kittens" to "puppies". Remember to commit your change.

  4. checkout the master branch again.

  5. Change the word "kittens" to something else that is pleasant. commit your change.

  6. Use git merge to merge the danger branch into master branch
     

  7. DON'T PANIC

Merge Conflicts

A merge conflict is when two commits from different branches include different changes to the same code.

Git does not know which version to keep, so makes you choose. 

Merge conflicts must be resolved manually

Conflicts are expected!

Resolving Conflicts (Atom)

In order to resolve a conflict, you need to edit the file (code) so that you pick which version to keep.
git will add "code" where you need to make a decision:

Resolving Conflicts (R Studio)

In order to resolve a conflict, you need to edit the file (code) so that you pick which version to keep.
git will add "code" where you need to make a decision: 

<<<<<<< HEAD

# This is the code from the "local" version (the branch you merged INTO)
# a.k.a the version from the HEAD commit

message <- "I am an original"
lyric <- "I've got no strings to hold me down"

# There can be multiple lines that conflict, including lines being deleted

=======

# This is the code from the "remote" version (the branch you merged FROM)

message <- "I think I'm a clone now..."

# The lines need not be related in content, they've just changed in a way
# that git can't figure out which to keep!

>>>>>>> f292a3332aedc8df3e8e8cf22ca3debc214c6460

the two versions to pick from

a divider between the versions

end conflict area

git add .
git commit -m "Merge branch 'other'"

Resolving Conflicts

  • Use git status to see which files have merge conflicts. Note that files may have more than one!
     
  • Delete the <<<<<<< and ======= and >>>>>>> !!
     
  • Once you're satisfied that the conflicts are all resolved, add and commit your changes (the code you "modified" to resolve the conflict):

GitHub and Branches

Because GitHub just hosts normal repositories, GitHub has branches as well! These can (but need not) correspond with the branches on your local machine.

Remote Branch Cmds

 git branch -a

List all branches (including remote ones) 

 git pull [remote] [branch]

Shortcut for git fetch then git merge 

 git fetch

Import remote branches into local repo
Are still listed as "remote" branches that need to be merged

Can cause conflicts!

 git push [remote] [branch]

Remote Branch Cmds

Upload commits to remote
Essentially has the remote branch merge (rebase) your changes.

 git push [remote] --all

Push all branches

Branching Questions?

Multiplayer Git

Collaboration

Multiple people's local repositories can be linked to the same remote repository, allowing them to push and pull to the same central location.

Collaboration Practice

  1. Partner up with a partner ("Howdy pardn'r")

  2. One person should add the other as a collaborator





     

  3. The added person will then need to clone their partner's repo on their machine

    • Remember to do this in a different folder!

Collaboration Practice

  1. Person 1: edit the README.md file so it includes a message to your partner (be nice)

    • add and commit your change as usual.
       

  2. Person 2: create a new script partner.R that prints a message to your partner (be nice)

    • add and commit as usual.
       

  3. Person 1 should push their changes to Github
     

  4. Then Person 2 should push their changes to Github

    • What happened?!

Collaboration Practice

  1. Person 2: pull to merge in Person 1's message

    • Both people should confirm the changes are local!
       

  2. Person 2: push your changes to Github
     

  3. Person 1: pull in Person 2's message and merger

    • You both should now have up-to-date code!

Collaboration Practice II

  1. Person 1: edit the partner.R file so that it prints a different message. Change the existing line of code.

    • add and  commit your change as usual.
       

  2. Person 2: edit the partner.R file so that it prints a different message. Change the existing line of code.

    • add and commit as usual.
       

  3. Person 2 should push their changes to Github

    • What happened?

  4. Then Person 1 should push their changes to Github.
    But they need to pull first...

git add .
git commit -m "Merge branch 'other'"

Resolving Conflicts

  • Use git status to see which files have merge conflicts. Note that files may have more than one!
     
  • Delete the <<<<<<< and ======= and >>>>>>> !!
     
  • Once you're satisfied that the conflicts are all resolved, add and commit your changes (the code you "modified" to resolve the conflict):

Make sure both partners have all the changes!!

Action Items!

  • Project Report due week from Monday

    • Start early! Like now!

  • (No exercises this week)

  • Reread Chapter 20 (required)

 

Tue: More with git branches; project time

Thu: Shiny

info201wi20-git-collab

By Joel Ross

info201wi20-git-collab

  • 585

More from Joel Ross