git

workflows
(for collaboration)
Centralized
Workflow
AKA Everyone Works On Master/Main
AKA The Most Basic Workflow Possible

The simplest collaborative workflow is to have

everyone work on the master branch (or main, or any
other SINGLE branch).

It's straightforward and can work for tiny teams, but it

has quite a few shortcomings!
Pamela clones the repo

master
David clones the repo

master
Forrest clones the repo

master
Forrest gets to work on a
new feature! Adding and
Committing all day long!
master
Forrest now pushes up his
new work to Github

master
Pamela has also been
hard at work on her own
new feature.
master
She tries to push her new
work up to Github, but she
runs into trouble!
master
Failed to push. Updates were rejected
because the tip of your current branch is
behind its remote counterpart. Merge the
remote changes (e.g. 'git pull') before
pushing again.
So she pulls to get the
changes from origin master
Forrest's work must be
merged in. Hopefully this master
goes relatively smoothly!
Now that she has merged the
latest work from Github, she
can push her master branch up!

master
David working on a new feature, but is
having some doubts.

He'd like to share his commits with the

rest of the team to start a discussion.
master
Before he can even share these iffy
commits, he has to pull from Github
and merge them in to master

master
Now he can finally push his work up to
Github. His teammates can pull to get
his new commits.

master
The Problem
While it's nice and easy to only work on the master branch,
this leads to some serious issues on teams!

Lots of time spent resolving conflicts and merging

code, especially as team size scales up.
No one can work on anything without disturbing the
main codebase. How do you try adding something
radically different in? How do you experiment?
The only way to collaborate on a feature together with
another teammate is to push incomplete code to
master. Other teammates now have broken code...
Enter
Feature
Branches
DON'T WORK ON MASTER SILLY GOOSE!
Feature Branches
Rather than working directly on master/main, all new
development should be done on separate branches!

Treat master/main branch as the official project history

Multiple teammates can collaborate on a single
feature and share code back and forth without
polluting the master/main branch
Master/main branch won't contain broken code (or at
least, it won't unless someone messes up)
Forrest clones the repo

master
Pamela clones the repo

master
David clones the repo

master
David starts work on a new
feature. He does all this work
on a separate branch!

add-dark-theme

master
David wants Pamela to take a look
at his new feature. Instead of
merging it into master, he just pushes
his feature branch up to Github!

add-dark-theme

master
Pamela is hard at work on her own
new feature. Just like everyone else,
she's working on a separate feature
branch rather than master.

master
animated-scroll
Pamela hears from David that he
wants her to take a look at his new
work. She pulls down his feature
branch from Github.
add-dark-theme

master
animated-scroll
Pamela takes a look at the code and
makes a couple improvements of her
own. She adds/commits on the same
feature branch.
add-dark-theme

master
animated-scroll
Pamela pushes up her new work on
the add-dark-theme feature branch
so that David can pull them down.

add-dark-theme

master
animated-scroll
David returns to work the next
morning. After an hour on reddit he
decides he should actually do some
work.

add-dark-theme

master
David fetches from Github and sees
that there is new work on the add-
dark-theme branch. He pulls the
changes down and continues work.

add-dark-theme

master
David decides he is happy with the
new feature, so he merges it into
master!
*At a real company, you don't just
decide you are "happy with" a feature.
There are mechanisms for code
approval and merging we'll discuss
shortly!
master
David pushes up the updated master
branch to Github. The others can
now pull down the changes.

master
Feature
Branch Naming
There are many different approaches for naming feature
branches. Often you'll see branch names that include
slashes like bug/fix-scroll or feature/login-form or
feat/button/enable-pointer-events

Specific teams and projects usually have their own

branch naming conventions. To keep these slides simple
and concise, I'm just going to ignore those best-
practices for now.
Merging In
Feature Branches
At some point new the work on feature branches will
need to be merged in to the master branch!
There are a couple of options for how to do this...

1. Merge at will, without any sort of discussion with

teammates. JUST DO IT WHENEVER YOU WANT.
2. Send an email or chat message or something to your
team to discuss if the changes should be merged in.
3. Pull Requests!
Pull Requests
Pull Requests are a feature built in to products like Github
& Bitbucket. They are not native to Git itself.

They allow developers to alert team-members to new

work that needs to be reviewed. They provide a
mechanism to approve or reject the work on a given
branch. They also help facilitate discussion and
feedback on the specified commits.

"I have this new stuff I want to merge in to the master

branch...what do you all think about it?"
The Workflow
1. Do some work locally on a feature branch
2. Push up the feature branch to Github
3. Open a pull request using the feature branch just
pushed up to Github
4. Wait for the PR to be approved and merged. Start a
discussion on the PR. This part depends on the team
structure.
I push my feature branch up to
Github, so that I can open a Pull
Request

my-new-feature

master
My Github
my-new-feature

master
My Github
my-new-feature

master

I click the PR button

My Github
My Boss's Github...

My boss leaves some feedback for me. She asks me to make a

couple changes before she merges the pull request.
Boss

I can respond! We can discuss and give feedback!

My Boss's Github...

Once I make the requested changes, my boss (or whoever is in

charge of merging) can merge in my pull request!
My Boss's Github...

Once I make the requested changes, my boss (or whoever is in

charge of merging) can merge in my pull request!
The above text will be used in the resulting merge commit.
My Boss's Github...

The changes from the my-new-feature branch have now been

merged into the master branch!!!
My Boss's Github...

Just like any other merge, sometimes there are conflicts that need
to be resolved when merging a pull request. This is fine. Don't panic.
You can perform the merge and fix the conflicts on the command
line like normal, or you can use Github's interactive editor.
My Boss's Local Machine
My boss can merge the branch and resolve the conflicts locally...

❯ git fetch origin

Switch to the branch in
question. Merge in master ❯ git switch my-new-feature
and resolve the conflicts. ❯ git merge master
❯ fix conflicts!

Switch to master. Merge in ❯ git switch master

the feature branch (now
with no conflicts). Push ❯ git merge my-new-feature
changes up to Github. ❯ git push origin master
Don't Worry
Github Gives You Instructions
If You Forget What To Do!
When merging, we can perform a Squash & Merge
which will reduce all the commits from the feature
branch down into a single commit on master.
My Boss's Github...

My boss can also decide to close my PR instead :(

Recap-ing
Pull Requests
Pull Requests are a fancy way of requesting changes
from one branch be merged into another branch.

Tools like Github & Bitbucket allow us to generate pull

requests via an online interface. Team members can then
view the changes and decide to merge them in or reject
them. PR's also provide a place to discuss the changes
and provide feedback.
Fork & Clone:
Another Workflow
The "fork & clone" workflow is different from anything
we've seen so far. Instead of just one centralized Github
repository, every developer has their own Github
repository in addition to the "main" repo. Developers
make changes and push to their own forks before making
pull requests.

It's very commonly used on large open-source projects

where there may be thousands of contributors with only a
couple maintainers.
Forking
Github (and similar tools) allow us to create personal
copies of other peoples' repositories. We call those
copies a "fork" of the original.

When we fork a repo, we're basically asking Github

"Make me my own copy of this repo please"

As with pull requests, forking is not a Git feature. The

ability to fork is implemented by Github.
This repo is not mine. I want a copy!
I click the "fork" button
Now I have my very own copy!
The original repo...

My newly-created fork...
Now What?
Now that I've forked, I have my very own copy of the
repo where I can do whatever I want!

I can clone my fork and make changes, add features,

and break things without fear of disturbing the original
repository.

If I do want to share my work, I can make a pull request

from my fork to the original repo.
Pamela is hard at work on her own
new feature. Just like everyone else,
she's working on a separate feature
branch rather than master.

master
animated-scroll
 The Official Project Repo

My Fork Taylor's Fork Lupe's Fork

Github
The Official Project Repo

My Fork Taylor's Fork Lupe's Fork

My Local Machine
I make a clone of my forked repository
so that I can start working on it locally
Github
The Official Project Repo

My Fork

origin

My Local Machine
When we clone a repo, Git automatically
adds a remote called origin that points to
our forked repo on Github.
Github
The Official Project Repo

upstream

My Fork

origin

My Local Machine
Next, I add a remote pointing to the original
project repo (NOT the fork). This remote can be
named anything, but you'll often see "upstream"
or "original" used.
Github
The Official Project Repo

upstream

My Fork

origin

My Local Machine
I do some new work locally. Normally, I
would work on a feature branch, but only to
keep the diagrams simpler I'm not going to!
Github
The Official Project Repo

My Fork

origin

My Local Machine
To share my changes with others, I cannot
push to upstream. I don't have permission!
But I can push to origin (my Github fork)
Github
Next, I can make a pull request from my fork
on Github to the original project repository
The Official Project Repo

Pull Request
My Fork

My Local Machine
Github
Now I wait to hear from the project maintainers! Do
they want me to make further changes? It turns out
they accept and merge my pull request! Woohoo! The Official Project Repo

Pull Request
Accepted!!!
My Fork

My Local Machine
Github
The next day, I get back to work. The official
project repo now contains work done by other
collaborators. I don't have their new work on my The Official Project Repo
machine! I'm behind!

upstream

My Fork

origin

My Local Machine
Github
The Official Project Repo

upstream

My Fork

origin

My Local Machine
All I need to do is pull from upstream
(the original repo) to get the latest
changes in my local repo.
Github
The Official Project Repo

My Fork

My Local Machine
Now I have the latest changes from
the upstream repo! I can work on
some new features locally without
working about being out of date.
Github
Pull
Request The Official Project Repo

Pull
My Fork
Push

My Local Machine
To Summarize!
1. I fork the original project repo on Github
2. I clone my fork to my local machine
3. I add a remote pointing to the original project repo.
This remote is often named upstream.
4. I make changes and add/commit on a feature
branch on my local machine
5. I push up my new feature branch to my forked repo
(usually called origin)
6. I open a pull request to the original project repo
containing the new work on my forked repo
7. Hopefully the pull request is accepted and my
changes are merged in!
An Even
Briefer Summary
1. FORK THE PROJECT
2. CLONE THE FORK
3. ADD UPSTREAM REMOTE
4. DO SOME WORK
5. PUSH TO ORIGIN
6. OPEN PR