I have adjusted the course syllabus to clarify policy around using late days for the group final project:
"What happens if someone doesn't contribute?"
We determine contribution level based on evidence available to us:
Consequences: Categorize contribution into categories:
By the end of class, you should be able to
edit files
staging area
git add
git commit
starter repo
your copy
git clone
your machine
fork
git push
"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
Branches allow for non-linear commits.
master
master
master
master
experiment
bugfix
experiment
experiment
git branch
git branch [my_branch]
git checkout [my_branch]
git checkout -b [my_branch]
git branch -d [my_branch]
Open the README.md file (in Atom)
Create and
checkout
a new branch called
experiment
Add another item to the end of the list
Add and commit your change
checkout
the
master branch
Add yet another item to the beginning of the list
Commit your change
Switch between the experiment and master branches (clicking on Atom in between). See the file contents changing?
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
We can
merge
two branches back together, producing a commit that contains the combined changes from both branches
master
master
experiment
HEAD
HEAD
git merge [other_branch]
Make sure you are on the
master branch
(use
git branch
to check; the current branch has a
*
)
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.
Check in Atom that the file now contains both sets of changes!
You should be on the master branch.
Create and
checkout
a new branch called
danger
On the
danger branch, change the word "kittens" to "puppies". Remember to
commit
your change.
checkout
the
master branch again.
Change the word "kittens" to something else that is pleasant.
commit
your change.
Use
git merge
to merge the
danger branch into
master branch
DON'T PANIC
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
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:
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'"
git status
to see which files have merge conflicts. Note that files may have more than one!
<<<<<<<
and
=======
and
>>>>>>>
!!
add
and
commit
your changes (the code you "modified" to resolve the conflict):
Because GitHub just hosts normal repositories, GitHub has branches as well! These can (but need not) correspond with the branches on your local machine.
git branch -a
git pull [remote] [branch]
git fetch
then
git merge
git fetch
Can cause conflicts!
git push [remote] [branch]
git push [remote] --all
Multiple people's local repositories can be linked to the same remote repository, allowing them to push and pull to the same central location.
Partner up with a partner ("Howdy pardn'r")
One person should add the other as a collaborator
The added person will then need to clone their partner's repo on their machine
Remember to do this in a different folder!
Person 1: edit the README.md file so it includes a message to your partner (be nice)
add and commit your change as usual.
Person 2: create a new script partner.R that prints a message to your partner (be nice)
add and commit as usual.
Person 1 should push their changes to Github
Then Person 2 should push their changes to Github
Person 2: pull to merge in Person 1's message
Both people should confirm the changes are local!
Person 2:
push your changes to Github
Person 1: pull in Person 2's message and merger
You both should now have up-to-date code!
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.
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.
Person 2 should push their changes to Github
What happened?
Then Person 1 should push their changes to Github.
But they need to pull first...
git add .
git commit -m "Merge branch 'other'"
git status
to see which files have merge conflicts. Note that files may have more than one!
<<<<<<<
and
=======
and
>>>>>>>
!!
add
and
commit
your changes (the code you "modified" to resolve the conflict):
Project Report due week from Monday
Start early! Like now!
(No exercises this week)
Tue: More with git branches; project time
Thu: Shiny