git Workshop

The stupid content tracker

Joao O. Santos (FP-UL)

Acknowledgments

  • Prof. Sérgio (FP-UL)
  • Philip Metz, former Education Evangelist at GitLab (@Metzinaround)
  • RUGGED

Part I - Online Code Forges

  • Let’s take a look at GitLab

Issues

Editing a Single File

Adding a File

Using the WebIDE

Break

  • Let’s have a break from feeling like we understand things

  • After the break we’ll check out the basics of git, and feel stupid for not understanding them

    • Don’t worry git makes everyone feel like that

Part II - Let’s Learn About git

git

  • git defines itself as “The stupid content tracker”

  • We’ll learn that it actually is “The content tracker that makes you feel stupid”

Disclaimer

  • You are an amazing individual and you’re anything but stupid

  • git makes anyone feel stupid

  • Still, when you collaborate with a lot of people in projects with tons of files, where a syntax error can cause the whole thing to crash, git is your friend

Disclaimer

  • You’ve seen how to use git online without having to understand it

  • Now let’s try (and fail) to understand it

History

  • It was the brainchild of Linus Torvalds, the creator of Linux
    • Linus Torvalds has created Linux, git, and a scuba diving software
    • Linux has changed the world it runs on everything
    • git has changed the world too and is the dominant version control system (VCS) today
  • git is maintained by Junio C. Hamano from July 2005 to this day.

GitHub is NOT git

Please write this down until you memorize it:

  • GitHub is not git

  • git is not owned by GitHub

GitHub is NOT git

  • You do not need GitHub to use git

  • GitHub’s app is not the only way to use git

  • You only need git <command> <arguments> to use git

But, What’s git, Then?

  • git is a version control system (VCS)
    • You said that already…
    • What’s a version control system, then?
      • Well it’s a system for controlling the versions of your files/projects
        • If that’s the kind of anwsers we’re getting out of your workshop we’re leaving, now!
          • Wait, wait, I’ll explain
            • You better!

Version Control

  • Let’s say you have a file, maybe a simple TODO list, in a file TODO.md file
TODO:

- [X] Go to QHELP Arrifana 2023
- [X] Pay attention to the seminars
- [ ] Learn a lot
- [ ] Profit!

Version Control

  • Let’s say you change something
  • And you don’t want to lose the original version so you name it TODO_v2.md
TODO:

- [X] Go to QHELP Arrifana 2023
- [X] Pay attention to the seminars
    + [X] Ignore the `git` seminar that guy is just stupid
- [ ] Learn a lot (just not from the `git` seminar)
- [ ] Profit!

Version Control

  • Since you saved your changes in a different name (e.g., “save as”)

  • Instead of overwriting the original file (e.g., just “save”)

  • You now have two versions of the same file

    • The original
    • And the modified

Version Control

  • Every time you make changes to a file you’re faced with the same decision:
    • Should I overwrite the original file or should I save it in a different name?

Version Control

  • This leads to the far too familiar situation of

Version Control Systems (VCSs)

  • What if you could overwrite the original file without losing the previous versions?

Version Control Systems (VCSs)

  • You may be thinking:
    • What kind of sorcery is that!?!!?
    • Or, yeah…well…Google Docs does that
  • To which I reply:
    • No sorcery, it’s just a version control system (VCS)
    • Yes…but it does that for individual files

Version Control Systems (VCSs)

  • VCSs allow you to do that for entire projects (many files in many directories)

  • There are several VCSs out there (e.g., cvs, fossil, etc…)

  • git is by far the most popular, and the focus for today

    • You shouldn’t be speaking of focus…
    • This workshop is all over the place!

Basic git Demo

  • git takes snapshots a directory’s (folder) contents so let’s make a directory
mkdir git_demo

Basic git Demo

  • Let’s go to that empty directory
cd git_demo
# we're in the directory
pwd
/builds/rggd/sciops_workshop/slides/git_demo

Basic git Demo

ls
# it's empty

Basic git Demo

  • Let’s set some config options before we can use git
    • Using git config --global so you never have to configure these settings again
    • Please, don’t forget to replace the user.name and the user.email with your preferred user name and email address.
git config --global init.defaultBranch main
git config --global user.name Stupid_Lecturer
git config --global user.email i_hate_this_lecture@boring.com
git config --global push.autoSetupRemote true

Basic git Demo

  • Now, let’s initialize git for that directory
    • Let’s make that directory a git repository (repo)
git init
Initialized empty Git repository in /builds/rggd/sciops_workshop/slides/git_demo/.git/

Basic git Demo

  • We now have an empty git repo, with no tracked files, no commits, no nothing
git status
On branch main

No commits yet

nothing to commit (create/copy files and use "git add" to track)

Basic git Demo

  • Let’s create an empty file, so we have something to track
touch demo_file

git status
On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    demo_file

nothing added to commit but untracked files present (use "git add" to track)

Basic git Demo

  • Now we can add the file to the staging area
git add demo_file

git status
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   demo_file

Let’s stop and review

We have:

  • Created a directory (folder)

  • git initiated a repo there

Let’s stop and review

We have:

  • Created an empty file

  • Added the demo_file to the staging area

Let’s stop and review

  • We know what files and directories (folders) are
    • We have tons on our computers
  • We’re just learning about what a git repo is
    • It is a directory (folder) that is tracked by git

Let’s stop and review

  • We’ve heard of this staging area but we don’t know what it is
    • Because you haven’t explained it! You stupid!
      • Easy I was getting to that. That’s why we stopped for review…

Staging Area

  • The staging area is where you are going to stage your changes
    • Ok…you’re just messing with us now!
      • I’ve been doing that from the start… (evil laughter)
  • By staging your changes I mean “saving” the changes you’ve made to the repo

Staging Area

  • In our demo there were no files in the repo

  • There is one now—demo_file

  • The change we’ve made is “adding the demo_file to the repo”

Staging Area

  • We will have to get back to what a staging area is after we continue the demo

  • Just remember there is such a thing as a staging are

  • It contains the changes you’ve git added to the repo

Basic git Demo

git status

# we have one staged but uncommited change to commit
# let's commit it
On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   demo_file

Basic git Demo

git commit --message "Make initial commit"

git status
[main (root-commit) ee9bc81] Make initial commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 demo_file
On branch main
nothing to commit, working tree clean

Basic git Demo

git log
commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Let’s stop and review

We have:

  • created a git repo

  • git added a file to the staging area

  • git committed the contents of the staging are

Let’s stop and review

We have seen that git status is telling us the state of the repo

  • What files in the repo are untracked

  • What files in the repo have changed

  • What are the contents of the staging area

Let’s stop and review

We have seen that git commit --message:

  • commits the contents of the staging area
  • the staging area becomes empty
  • the commit appears on the git log
    • With the message that we’ve written as sort of an email to our collaborators/future selfs

Let’s stop and review

  • Our git repo now has one commit

  • No file has changed since the last commit

    • demo_file hasn’t been changed
    • No other file (or directory) has been created

Basic git Demo

git status
On branch main
nothing to commit, working tree clean
git status
# let's change `demo_file`
echo "This workshop sucks" >> demo_file
cat demo_file
On branch main
nothing to commit, working tree clean
This workshop sucks

Note

  • I’m using command line tools to create, view, and edit the files because I want everything to be visible on the slides and automatically generated by SciOps

  • That last edit to the file could have been made in RStudio, notepad, Microsoft Word, what have you.

Basic git Demo

# we've added a line to the demo_file
cat demo_file
This workshop sucks
# what's our `git status`
git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   demo_file

no changes added to commit (use "git add" and/or "git commit -a")

Basic git Demo

# Ok we have one file changed
# `git diff` tells us what has changed
git diff
diff --git a/demo_file b/demo_file
index e69de29..14f9b20 100644
--- a/demo_file
+++ b/demo_file
@@ -0,0 +1 @@
+This workshop sucks

Quick But Hard Question

What are the contents of our staging area:

    1. The staging area has the change made to the demo_file
    1. The staging area has our last commit
    1. The staging area is empty

Answer

  • Option (c) is correct the staging area is empty

  • We have changed the demo_file but we have not git added it

Basic git Demo

# let's check our `git status` once again
git status
On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   demo_file

no changes added to commit (use "git add" and/or "git commit -a")

Basic git Demo

# let's add the changes to the `demo_file`
git add demo_file
# let's check the status again
git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   demo_file

Let’s stop and review

  • Our git repo has one commit (adding the demo_file)

  • We’ve changed the demo_file and git added it to the staging area

  • We have NOT git committed it

Basic git Demo

# let's confirm the git status
git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   demo_file

Basic git Demo

  • Let’s do something different for a change
  • Let’s delete the demo_file
# delete `demo_file`
rm demo_file
ls
# Note you could do this in another program, like Windows (file) Explorer

Basic git Demo

# let's check our git status now
git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   demo_file

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    deleted:    demo_file

Let’s stop and review

We have:

  • One commit that creates the demo_file

  • One change to the demo_file git added to the staging area

  • Deleted the demo_file but we have NOT git added that change to the staging area

Quick But Hard Question

What happens after we git commit?

git commit --message "What has happened?"
[main e600b86] What has happened?
 1 file changed, 1 insertion(+)

Quick But Hard Question

  1. What happens to the demo_file in our directory?
    • Nothing. The demo_file stays deleted.
    • We recover the demo_file with the last change that we made.
    • We recover the demo_file in its original empty version?

Quick But Hard Question

  1. What change actually gets git committed?
    • The deletion of the file (made after we added a line)
    • The addition to the file (made before we deleted the file)
    • Nothing. git won’t make the commit because the file was deleted

Quick But Hard Question

  1. What happens to the staging area?
    • It becomes empty, since we have git committed its contents.
    • It will now contain the file deletion (made after the adittion)
    • Nothing. git won’t make the commit nor change the staging area because the file was deleted

Answers

  1. What happens to the demo_file in our directory?
    • Nothing. The demo_file stays deleted.
ls -al
total 12
drwxr-xr-x 3 root root 4096 Feb  6 17:12 .
drwxrwxrwx 4 root root 4096 Feb  6 17:12 ..
drwxr-xr-x 8 root root 4096 Feb  6 17:12 .git

Answers

  1. What change actually gets git committed?
    • The addition to the file (made before we deleted the file)
# we can use `git show` to see the contents of the commits
# If we don't give it any arguments it will show the last commit
git show
commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

diff --git a/demo_file b/demo_file
index e69de29..14f9b20 100644
--- a/demo_file
+++ b/demo_file
@@ -0,0 +1 @@
+This workshop sucks

Answers

  1. What happens to the staging area?
    • It becomes empty, since we have git committed its contents.
git status
On branch main
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    deleted:    demo_file

no changes added to commit (use "git add" and/or "git commit -a")

Let’s stop and review

  • We’ve created a git repo

  • We’ve learned about the staging area

    • It does not contain the contents of our git repo
    • It just contains the changes we have remembered to git add

Let’s stop and review

  • We’ve learned to git commit
    • the contents of our staging area (not the contents of the directory)
  • We’ve learned about the git log
    • It shows the commit history

Let’s stop and review

  • We’ve learned to see our git status

  • We’ve learned to see our last git commit with git show

Let’s stop and review

  • This exercise is very academic
    • We haven’t made any mistakes that we want to revert
  • Let’s do that now
    • I’m putting my talent to make mistakes to good use

Basic git Demo

  • Let’s say we git add and git commit the deletion of the demo_file by mistake
# `git add` everything in the directory (it's empty now)
git add .
# `git` learns that the `demo_file` has been deleted
git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    demo_file

Basic git Demo

# and we `git commit` that by mistake
git commit --message "Upsy daisy"
[main cef2e20] Upsy daisy
 1 file changed, 1 deletion(-)
 delete mode 100644 demo_file

Basic git Demo

# The staging area is now empty
git status
On branch main
nothing to commit, working tree clean

Basic git Demo

# The `git log` now features our Upsy daisy
git log
commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Basic git Demo

# And we can see we messed up with
git show
commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

diff --git a/demo_file b/demo_file
deleted file mode 100644
index 14f9b20..0000000
--- a/demo_file
+++ /dev/null
@@ -1 +0,0 @@
-This workshop sucks

Basic git Demo

  • To fix our mistakes we can git revert <commit_hash> our last commit

  • We can also git checkout the file that we want git checkout <commit_hash> <file>

  • But we need to know the commit hashes

Basic git Demo

# the commit hash is that sequence of numbers and letters after "commit "
git log
commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Basic git Demo

  • If we want to use git revert we need to use the hash from the last commit, since that commit deleted the file.

  • If we want to use git checkout we need to use the hash from the second to last commit since that was the last commit that still had the file.

Basic git Demo

  • Let’s git checkout the demo_file from the second to last commit
git log
commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Basic git Demo

# The slides are automatically generated so I'll have to use some
# hackery to find the hash, since I can't see the log.
# Please ignore the line below.
commit_hash=$(git log | grep -B4 "What has happened" | grep "commit" | sed 's/commit //')

# Just replace the commit_hash variable with the actual hash
git checkout $commit_hash demo_file
Updated 1 path from be292fa

Basic git Demo

# And now we can see if have recovered the file
# (hoping my hackery worked)
ls

# (hopefuly) we can see the `demo_file` is back in our directory
demo_file

Basic git Demo

# Now `git status` tells us we have a file
git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   demo_file
# We can commit the recovery of the `demo_file`
git commit --message "Recover demo file"
[main 8612228] Recover demo file
 1 file changed, 1 insertion(+)
 create mode 100644 demo_file

Basic git Demo

# And we can see this new commit is in the log
git log
commit 8612228066af5fee70305d4d0c0475e546ae2a14
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Recover demo file

commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Basic git Demo

# And inspect what it did with `git show`
git show
commit 8612228066af5fee70305d4d0c0475e546ae2a14
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Recover demo file

diff --git a/demo_file b/demo_file
new file mode 100644
index 0000000..14f9b20
--- /dev/null
+++ b/demo_file
@@ -0,0 +1 @@
+This workshop sucks

Branches

  • So far you have worked on a single branch—main

  • Branches are a very important feature of git

  • However, despite code forges like GitHub and GitLab making heavy use of them they are not easy to understand before you understand the basics

  • If you have never tried git before, I would try and work without branches for a while…

Branches

  • It is hard to explain what branches are…

  • Let me try…

    • and fail…
      • badly…

Branches

  • Let’s say you want to make changes but you want to easily preserve the original versions.

  • For instance, you were working on a report with several graphs, all of the same type.

Branches

  • You could be interested in creating a version with another type of graph, while preserving the original.

  • Maybe you want to postpone making a decision on which type of graph you will choose, and you want to keep working on both to see what they look like.

Branches

  • In such cases you might create two separate versions of your report, with different file names, and work on both at the same time.

  • However, your report could be calling different scripts, and each script might require modifications depending on the type of graph.

  • Now you’d be forced to create two versions of each of those scripts as well.

Branches

  • You can see how things start getting hard to manage…

Branches

  • Fortunately, with git you can have separate branches, each can hold a different version, from the other branches, of any number of files.

Branches

  • As we’ll see this means that a given file (e.g., demo_file) can look like one thing when you’re in a branch, and look like something completely different, when you’re in another branch.

Branches

  • Sounds confusing?
    • Well, I’ve warned you branches can be confusing.
      • You also told us you would try to explain them
        • And I’ve told you I’d fail badly.
          • In fact, I’m succeeding in failing badly.

Branches

  • Let’s create a new branch called testing.
git branch testing

Branches

  • Let’s see our git status
git status

# We're still on `main`
# Hummmm????
On branch main
nothing to commit, working tree clean

Branches

  • Let’s list our branches
git branch
* main
  testing

Branches

  • Okay… So we’ve created a branch but we’re not there yet.

  • Let’s git checkout that branch

git checkout testing
Switched to branch 'testing'

Branches

  • Are we there yet?
git status

# Yup!
On branch testing
nothing to commit, working tree clean

Branches

  • Now we’re in the testing branch

  • Let’s say you decide to make a new change to demo_file, you git add demo_file

echo "Everything is different in testing" > demo_file

cat demo_file
Everything is different in testing

Branches

  • Let’s say you git add and git commit your changes to the testing branch
git add demo_file

git commit --message "Change only this branch"
[testing bbd692c] Change only this branch
 1 file changed, 1 insertion(+), 1 deletion(-)

Branches

  • Now if testing branch’s git log will be the same as main’s git log up until the point you made this commit.
git log
commit bbd692cf8bdb5afed482e93f4aee189d84080ed2
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Change only this branch

commit 8612228066af5fee70305d4d0c0475e546ae2a14
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Recover demo file

commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Branches

  • Thus main and testing have a similar commit history, but with the last git commit to testing they have started to differ.

Branches

  • Now imagine you start making new commits on either one.

  • Their git logs will start to differ more and more from, but they will always have the same starting point

Branches

  • Branches allow you to branch of a point in branch’s history, creating another, and starting a new commit history from there

  • Your branches will always have some common history, but after that point they will have a different history

Branches

  • The cool thing about git is that it allows you to git merge branches, merging their histories, as if they have never branched of

Branches

  • Let’s go back to main
git checkout main

git status
Switched to branch 'main'
On branch main
nothing to commit, working tree clean

Branches

  • What does our demo_file look like in main
cat demo_file
This workshop sucks

Branches

  • Notice main’s git log doesn’t feature the last git commit from testing, with the message “Only in this branch”
git log
commit 8612228066af5fee70305d4d0c0475e546ae2a14
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Recover demo file

commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Branches

  • Recall that everything is different in testing
git checkout testing

git status
Switched to branch 'testing'
On branch testing
nothing to commit, working tree clean
cat demo_file
Everything is different in testing

Branches

  • Let’s get back to main
git checkout main

git status
Switched to branch 'main'
On branch main
nothing to commit, working tree clean

Branches

  • Let’s say we don’t want testing to be so arrogant and think it’s special.

  • Let’s say we want to git merge testing onto main, where we are, so the demo_file can look, here, in main, like it looks in testing

Branches

# how demo_file looks in main before merging testing
cat demo_file
This workshop sucks
git merge testing

# how it looks after the merge
cat demo_file
Updating 8612228..bbd692c
Fast-forward
 demo_file | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
Everything is different in testing

Branches

  • Take a look at main’s git log now
git log
commit bbd692cf8bdb5afed482e93f4aee189d84080ed2
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Change only this branch

commit 8612228066af5fee70305d4d0c0475e546ae2a14
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Recover demo file

commit cef2e205ef3d1d26bc2f97663ec6d57239adb118
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Upsy daisy

commit e600b861a7048b9c46e562920adc871a2f1ed332
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    What has happened?

commit ee9bc8107a612a8d84510cb15be0bfd2154420a0
Author: Stupid_Lecturer <i_hate_this_lecture@boring.com>
Date:   Tue Feb 6 17:12:24 2024 +0000

    Make initial commit

Branches

  • So we’ve taken a look at the amazing power of git branching

  • If this all sounds confusing its because it is…

  • Avoid working with branches until you have to

Branches

  • Unfortunately, when several people are working on the same project at the same time, you probably have to…

  • As it usually happens in QHELP…

Using a Remote

  • So far we’ve been using git locally

  • Unlike many people today think, that’s a perfectly valid use case

  • Still, when we get to host git repos online a new level of collaboration is possible

Using a Remote

  • Online git repos are basically a copy of your repository in the “cloud”

  • You can git push your changes to the remote repo by running git push

  • You can git pull any changes from the remote with git pull

Using a Remote

  • If you’re the only one working on the repo and your work only on one machine, there’s little need to git pull

  • There will be nothing there other than what you have git pushed

    • Unless you’ve been hacked…

Using a Remote

  • If you’re working with others, though, they might have git pushed their changes before you made yours

  • When working with others, it’s always a good idea to run git pull before you run git push

Using a Remote

  • If you made commits before you git pulled, your git log will differ from remote

Using a Remote

  • In that case, you have to try and git pull --rebase
    • git will try to restructure your commits as if they happened after the ones made by your colleagues

Using a Remote

  • If that doesn’t work there ways to fix it but they are beyond the scope for today

Using a Remote

  • Working with a remote is similar to working with branches

Using a Remote

  • Your local history may differ from the remote but you can merge histories by git pulling and git pushing

Using a Remote

  • git pull --rebase allows git to be creative in how it rewrites the history so everything works

Let’s Clean Up and Pause

rm -rf *
rm -rf .git/

Pause

  • Breath in
    • Breath out
  • Breath in
    • Breath out
  • Breath in
    • Breath out

High-level Review

  • We can make changes to files in our computers
    • We don’t need git for that

High-level Review

  • We can use git to keep track of the files

High-level Review

  • When we git add a file we add it to the staging area

High-level Review

  • It is only when we git commit it that we add it to the git log

Quick But Hard Question

What happens in the following situation

  1. I change a file

  2. I git add that file

  3. I change the file again (before git commiting it)

  4. I git add the file again (before git commiting it)

Answer

  • I override the changes that were in the staging area with the latest one

  • I don’t have a way to distinguish between the changes made in 1 and the ones made in 3.

Answer

  • It is the same as making all the changes at once and git adding them later

  • Only if I add git commited them would I keep both versions

  • Sometimes that’s what I want, sometimes that’s not

Tips for Working with git

  • I suggest you git pull, git add, git commit, and git push very frequently

  • The right time to git add and git commit was 30 minutes ago