Lecture 41

git part 3:

Branching and collaboration

MCS 275 Spring 2023
David 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

Revision history

  • 2023-04-28 Initial publication.