Git Collaboration
Outline
Review
Collaboration Overview
Centralized Workflow
Branches
{review}
Using Github
Your machine
fork
Your copy
Starter repo
git clone
git add *
Edit files
Staging area
git commit -m ".."
git push
Information retrieval
Your machine
remote
Create local repo: git clone
Check for updates: git fetch
Integrate updates: git pull
Let's do a quick demo
{collaboration overview}
Why?
Facilitate collaboration
Work on the same documents at the same time
Manage conflicts
Assign tasks to group members
Centralized Workflow
Only one remote repsository
Don't fork! (only clone)
Remote (GitHub) is truth
One (of many) workflow structures
Create a repository
One team member should create a new repository on GitHub
Create a Readme.md file
On GitHub, create a Readme.md file when you make the repository. It should say, "My fav candy is Gushers"
Add collaborators
The creator should grant permission to other team members by adding them as collaborators
Clone the repository
Each person should clone the same repository to their local machine
GitHub Issues
Provide tools for assigning and tracking tasks
Awesome for planning projects
Facilitate communication
Creating Issues
Create 2 issues: 1) Edit Readme.md. 2.) Create assignment.r file. Assign each issue to a different group member
Closing Issues
You can close issues via a commit message!
Do this throughout today's exercise
# Close issue number 7
git commit -m "Added a new file. Close #7"Next Steps
Person 1: edit Readme.md
Person 2: create assignment.r (with some code/text in it)
Each person should add and commit as usual (and close the corresponding issues!)
Person 1 should push their changes to GitHub
What happens when person 2 pushes?
Remote
Person 1
Person 2
clone
clone
commit
commit
push
commit
push
Remote
Person 1
Person 2
clone
clone
commit
commit
push
commit
push
pull --rebase
Rebasing
Git gave us an error (luckily), preventing us from overwriting the truth (remote)
The --rebase option pulls down code, and integrates your changes with the changes on the remote
Achieves this by rewinding your code to a common ancestor, and the applying changes on top of it
Rebase documentation
Person 2 rebase and push
# Simple case of pulling in changes (i.e., no conflict)
git pull --rebase origin master
# Push changes
git push origin masterEditing the same lines of code
Person 3: Write your favorite candy in Readme.md
Person 4: Write your favorite candy in Readme.md
Person 3: Add, commit, push
Person 4: Add, commit, push, rebase.....
CONFLICT!
Conflict
Arises when the same part of a file differs across commits
Must be resolved manually
Common part of the process
Multiple ways to resolve conflict
What happened
You tried to pull --rebase to to integrates changes
But you got an error
Git has initiated a rebase:
# Put local commits on top of changes to the remote
git pull --rebaseAuto-merging your-file-name.r
CONFLICT (content): Merge conflict in your-file-name.r# What is happening
git status
What's happening
but how?
open up the file with a conflict
Conflict resolution
<<<<<<< HEAD
# This is the code section in your local version
# It can be multiple lines
x <- 6
======= # This is the divider between local and remote code
# This is the code section in your REMOTE version
# It can be multiple lines
x <- 7
>>>>>>> remote-branch-name-or-hashEdit this file to keep the code you want. Remove all extraneous info and characters (i.e., >>>>>, =====)
Rebasing: step by step
Pull in remote changes
Manually resolve conflict in the file
Run git add to add changes to the rebase
Continue with the rebase (no need to commit)
# Put your changes on top of the remote changes
git pull --rebase<<<<<<< HEAD # delete this non-sense!
# Keep relevant comments and code
x <- 7
# Add any/all edited files
git add .# Continue through rebase, then push changes to GitHub
git rebase --continue
git push origin masterI suggest..
# When you sit down to do work, pull down changes. --rebase shouldn't matter here
git pull --rebase origin master
# Do some work. Some great work!
# Add and commit your work. Make sure messages are clear, and close issues.
git add .
git commit -m "Specific message that can close issues"
# Push your changes up to GitHub (the origin)
git push origin master
### If you get an error (b/c someone else has pushed), pull in changes w/ a rebase:
git pull --rebase origin master
# Open up files and edit them, removing >>>>, =====
# Add changes to the rebase
git add .
# Continue the rebase, no need to commit!
git rebase --continue
# After the rebase, push your changes to GitHub
git push origin master{branches}
Branches
A branch in GitHub is a way of labeling a sequence of commits. You can create labels (branches) for different commits, and effectively have different "lines" of development occurring in parallel and diverging from each other
master
new-idea
# Create a new branch of the current commit
git branch new-idea
# Start working on the branch by checking it out
git checkout new-idea
# You can do those in one line, if you prefer
git checkout -b new-ideaNext Steps
Create a new branch called "super-hungry"
Checkout your new branch
Edit the Readme.md to have your favorite snack when you're super hungry
Add and commit those changes
# Label the current commit as a new branch super-hungry
git branch super-hungry# Checkout (i.e., start working in) your super-hungry branch
git checkout super-hungry# Add and commit changes as usual
git add .
git commit -m "Added super-hungry snacks"Next Steps
Switch back to your master branch
Change your favorite snack in Readme.md to another snack
Merge your super-hungry branch into your master branch
# Checkout (i.e., switch to working in) your master branch
git checkout masterAdd and commit those changes
# Add and commit changes as usual
git add .
git commit -m "Changed my favorite snack"# Merge super-hungry branch into master (current) branch
git merge super-hungryCONFLICT!
Resolving merge conflicts
Just like resolving conflicts for a rebase: edit & save files
Once you merge, you'll have to add and commit
<<<<<<< HEAD
# This is the code section in your local version
# It can be multiple lines
x <- 6
======= # This is the divider between local and remote code
# This is the code section in your REMOTE version
# It can be multiple lines
x <- 7
>>>>>>> remote-branch-name-or-hash# Add and commit changes as usual
git add .
git commit -m "Changed my favorite snack"Resolving merge conflicts
All together:
# Make and checkout new branch
git checkout -b super-hungry
# Make some changes to your file, then add and commit
git add .
git commit -m "Added super-hungry fav. food"
# Switch back to master branch
git checkout master
# Make some changes, then add and commit
git add .
git commit -m "Made changes to master"
# Merge in changes from super-hungry branch
git merge super-hungry
# Resolve the conflict MANUALLY in the file, then add and commit
git add .
git commit -m "Merged in super-hungry branch"