Lecture 41

git part 3:

Branching and collaboration

MCS 275 Spring 2023
Emily Dumas

Lecture 41: Branching and collaboration

Reminders and announcements:

Project 4 due at 6pm today
Don't forget your course evaluation
I will post on Blackboard about what comes next (e.g. course material archive)

Last time

We pushed our git repo to GitHub.

We experimented with changes on GitHub and changes locally (without truly "collaborating").

GitHub collaboration

We can mark other GitHub users as collaborators on a repo, allowing them to push to it.

(Private repos are invisible except to collaborators.)

Key consideration: Online repo can change with no action from us.

Revised workflow

git pull – get updates
git log – see what's changed
Make and test your changes
git add file1
git add file2
git commit
git push – make changes available to others

`git push`

Contact a remote repository and send it commits that are in our database but not theirs.

`git pull`

Contact a remote repository and get commits from its database that are not yet in ours.

When can you push/pull?

The local and remote repos have a commit labeled HEAD, the "latest".

You can push only if the local HEAD derives from the remote HEAD.

You can always pull, but it may trigger a merge.

Failed push

If a git push fails, the solution is to:

git pull – starts a merge, often completes automatically
git push – to send the unified updates to the remote

Branches

You can have multiple lines of development underway at once, each with their own name and history. You can switch between them at will.

A repo starts with one branch called main.

Each branch is just a pointer to its latest commit.

Branches can be local or shared.

Working with branches

git checkout -b my_branch_name – Create new branch
git checkout my_branch_name – Switch to existing branch
git checkout main – Switch to the main branch
git branch -d my_branch_name – Delete a branch
git commit – commit staged stuff to active branch
git push origin my_branch_name – push a branch to remote (default is to keep them local)

Why branches?

Often projects keep main clean, and do all work on changes in branches.

One branch per feature (or task) is common.

This way, features can be worked on in parallel.

End of a branch

Branches "end" in two ways:

Abandon: switch away, never go back (maybe delete)
Merge: bring changes from one branch into another (often into main)

Merging

To merge alpha into beta, ending alpha:

git checkout beta
git merge alpha
Resolve any conflicts identified.

The merge is a commit to beta.

Loose ends

`git blame`

git blame FILE shows commit that most recently changed each line of a file.

If you know where a problem is, this helps figure out how it got there.

Cloning an existing GitHub repo

git clone URL – make a local copy of an existing repository.

Works with local repositories, too. Substitute directory for URL.

Like git init, this is a rare event.

Our semester together

References

git home page
Official git documentation (includes tutorial videos, Pro Git book)
git - the simple guide (nice practical introduction, with mild profanity)

Revision history

2023-04-28 Initial publication.