CSE 391

Git branches, merging

Remote repositories

​

Slides created by Josh Ervin and Hunter Schafer. �Based off slides made by Marty Stepp, Jessica Miller, Ruth Anderson, Brett Wortzman, and Zorah Fung

​

​

AGENDA

• Logistics, be sure to check your homework scores
• More git
• Branching
• Merging
• Working with remote repositories

ROADMAP

• Introduction to the command line
• Input/output redirection, pipes
• More input/output redirection, tee, xargs
• Git: Fundamentals
• Git: Branches, merging, and remote repositories
• Regular expressions
• More regular expressions, sed
• Users and permissions
• Bash scripting
• Industry applications

REVIEW: FOUR PHASES

Working Directory

Staging Area/Index

Local Repository

Remote Repository

Working changes

Changes you’re preparing to commit

Local copy of the repository with your committed changes

Remote shared repository (Usually stored with a platform like GitHub/Gitlab)

GIT: BRANCHING

• So far, all the operations we’ve done have been on the master branch.
• However, it’s very rare you’ll be working on master directly. Instead, you’ll work on a separate branch:
• Master is the “single source of truth” - the history of the project
• The code on master should be stable and compile
• Because of this, it’s difficult to share and collaborate on in progress work.
• Working directly on master makes it difficult to work simultaneously on unrelated features.

NOTE: On most newer repos, master has been renamed to main. In practice you will see both names used in documentation and repos.

​

COMMIT HISTORY

A

B

C

These are commits. “A” is the first commit, “C” is the most recent

Each commit references it’s parent - the one that came before it in time.

master

HEAD

COMMIT HISTORY

A

B

C

master

HEAD

• HEAD: This is a pointer, or reference, to the git branch that you are currently working on.
• Master: This the main branch of your repository, the single “source of truth”, and the only branch created by default.
• NOTE: The pointer from one commit to another points to the previous commit, so the arrows go back in time.

COMMIT HISTORY

A

B

C

master

HEAD

To view this same information on the command line:

$ git log

​

Or, to make it more similar to what we see here:

$ git log --graph --oneline

BRANCHING

A

B

C

master

HEAD

Commands that have been run:

​

$ git branch feature

$ git checkout feature

​

​

​

feature

BRANCHING

A

B

C

master

HEAD

Commands that have been run:

​

$ git branch feature

$ git checkout feature

$ echo “D” >> file.txt

$ git add file.txt

$ git commit -m “D”

​

​

feature

D

BRANCHING

A

B

C

master

Commands that have been run:

​

$ git branch feature

$ git checkout feature

$ echo “D” >> file.txt

$ git add file.txt

$ git commit -m “D”

$ git checkout master

$ echo “E” >> file.txt

$ git add file.txt

$ git commit -m “E”

​

feature

D

E

HEAD

BRANCHING

A

B

C

master

Commands that have been run:

​

$ git branch feature

$ git checkout feature

$ echo “D” >> file.txt

$ git add file.txt

$ git commit -m “D”

$ git checkout master

$ echo “E” >> file.txt

$ git add file.txt

$ git commit -m “E”

$ git merge feature

feature

D

E

M

HEAD

WORKING WITH REMOTE

A

B

master

Local

Remote

A

B

origin/master

master

HEAD

WORKING WITH REMOTE

A

B

master

Local

Remote

A

B

origin/master

C

master

HEAD

WORKING WITH REMOTE

A

B

master

Local

Remote

D

A

B

origin/master

C

master

HEAD

WORKING WITH REMOTE

A

B

master

Local

Remote

D

git push

A

B

origin/master

C

master

HEAD

WORKING WITH REMOTE

A

B

master

Local

Remote

D

git push

A

B

origin/master

C

master

HEAD

WORKING WITH REMOTE

A

B

A

B

master

Local

Remote

origin/master

C

master

HEAD

D

git fetch

D

WORKING WITH REMOTE

A

B

A

B

master

Local

Remote

origin/master

C

master

HEAD

D

D

git merge

M

Note: It’s more common to do git pull which is an alias for git fetch + get merge

WORKING WITH REMOTE

A

B

Local

Remote

origin/master

C

master

HEAD

D

M

git push

A

B

C

master

D

M

PULL REQUESTS

• In practice, it’s very rare that we would merge branches locally and push them to remote.
• Instead, we use a service like GitHub or GitLab to help us:
• Step 1: Create a local branch and make some commits
• Step 2: Push those commits to remote
• Step 3: Open a pull/merge request on GitLab
• Step 4: Collaborate with others, leave comments, and fix conflicts
• Step 5: Merge into master (or other branch)
• BUT, it’s important to know what’s going on when you branch and merge, because that’s what’s going on under the hood on GitHub/GitLab
• The main goal here is to be very deliberate about what we put on master.

WORKING WITH REMOTE

Local

A

B

origin/master

C

master

HEAD

D

M

Remote

A

B

A

B

C

D

M

master

WORKING WITH REMOTE

Local

A

B

origin/master

C

master

D

M

X

feature

HEAD

Remote

A

B

A

B

C

D

M

master

WORKING WITH REMOTE

Local

Remote

A

B

A

B

origin/master

C

master

D

M

A

B

C

D

M

X

feature

HEAD

master

Y

Commit happens on origin

WORKING WITH REMOTE

Local

Remote

A

B

A

B

origin/master

C

master

D

M

A

B

C

D

M

X

feature

HEAD

master

Y

X

feature

git push feature

WORKING WITH REMOTE

Local

Remote

A

B

A

B

origin/master

C

master

D

M

A

B

C

D

M

X

feature

HEAD

master

Y

X

feature

Do this on GitLab

M1

WORKING WITH REMOTE

Local

Remote

A

B

A

B

origin/master

C

master

D

M

A

B

C

D

M

X

feature

HEAD

Y

X

M1

master

feature

M2

PULL REQUEST!!!