Link to these slides: https://bit.ly/shellgit

 

Lift the curtain of the graphical user interface and experience your computer by command line.

Shell and Git: Level 2

Branches!

Shell commands for  navigation and intel

REVIEW: Finding, moving, searching, getting info on your directories and files in the shell

Link to these slides: https://bit.ly/shellgit

space or tab to this section  

cd

cd [space]

cd directoryName

cd ..

pwd

ls

ls -lh

change directory (go walking the directory tree up or down)

print working directory
(show me the full filepath location where I am right now)

list files and directories below me
("look see")

cd [space] takes you to the "home" directory of your computer. Try it, and then enter pwd to see where it takes you.

cd directoryName goes down a level into the directory you indicate

cd .. climbs UP to the parent directory

ls -lh adds a special flag to return lots of information about last-access dates and file sizes and more.

mkdir directory

 mkdir myNewDirectory

touch file

"make directory": Use this as a convenient way to create and name a new directory. Remember: do NOT put spaces in your directory or file names!  

Spaces in folder and filenames makes it very difficult to navigate or share them!

Use this to create a new file. It will be empty until you edit it to add new content. You could, for example, start a new file named newFile.xml, open it in oXygen and edit it. 

touch newFile.xml

grep

 grep -n "slime" Slime.xml

grep -r "string" .

grep "string" file.xml

cat

grep literally means "global regular expression print". It means, go searching for a string in a file or a directory.

You can ignore case with -i.

You can plug in regex patterns with -E or egrep

literally, "concatenate", or just show all the contents of a file

 cat Slime.xml

 grep -E rec.p Slime.xml

wc

 wc Slime.xml

"word count". Gives you four columns:
numbers of lines, number of words, number of characters, filename
 

Piping commands: take the result of one command and feed it to the next

ls | wc -l

that reads:
ls "pipe" wc -"el"

This is handy way to count the files in a directory!  ls sends a list of your files to the wc function, which counts their lines, giving you a file count.

Moving, renaming, copying files with shell commands

mv

cp

These commands can rename a file, or move it to a new location. Indicate the source file and the destination directory. If renaming indicate the new name.ext
mv deletes the original. cp copies without deleting the original

Renaming a file: Navigate to its directory, and use mv to change the name: 

eeb4@salamander textAnalysis-Hub % cp Class-Examples/XML/joeyClassPush.xml Sandbox/

Copies the file without deleting the original. Use the [tab] key to autocomplete to help you be sure a directory or filename is where you think it is. 

mv joeyClassPush.xml joeyExample.xml

Shell Commands Linked Resources

 

git commands:

getting started with branches

Link to these slides: https://bit.ly/shellgit

space or tab to this section 

Why use Git?

  • Git preserves a mindful, human-curated version history!
  • Git allows for multiple versions to coexist!
     
  • Git permits creating alternative versions of files that can co-exist in forks or branches​
  • Forks and branches help people share a standard, stable version of a file or directory alongside a "development" / prototype new version, stored in fork or branch.
  • A fork is a whole repo that is cloned to another user's space.
  • A branch is an alternative version shared inside the same repo.
  • When approved and the time is right, forks and branches can be merged or reconciled with a source repo or main branch.
  • Once a fork or branch is merged into another branch, it's typically deleted.
  • Make a new fork or branch when it's time to do some new draft development.

Thanks to Mia Borgia, (DIGIT grad, 2022) for the git twinkie visuals!

git branch

When you share a repo,

work in a branch

lists all of the branches on a repo

git checkout -b elisaBranch

creates a new branch on your repo named elisaBranch, and "checks it out" by moving you to the branch. Name your branch something easy to distinguish from your peers!

git push -u origin elisaBranch

Pushes the new branch (elisaBranch) up to the remote repo for tracking there.   

git pull

 

Pull in anything new from remote before you start making changes!

pulls in new files committed to the branch you've checked out.

Scenario 1: Could  you have pushed something to your remote repo from a school computer or the web interface? Are you at home now? Pull in your changes!

 

Scenario 2: Did your teammates or Dr. B push something to your branch the remote class or project repo? Pull in their changes!

As you get ready to work...

Working at your repo: Overview 

  1. git branch
  2. git checkout branch (if necessary)
  3. git pull
  4. Make your changes and save them to the repo
  5. git add -A  (This adds every change for tracking.
    To add only a specific file, use     git add filename.ext)
  6. git commit -m "your commit message" 
  7. git push

Working at your repo: detailed explanation (1)

Make sure you know what branch you want to be working in. Look and make sure you're on that branch. git branch lists the branches.

git branch

git checkout yourbranch

git checkout yourbranch switches you to the local branch that you indicate.

git fetch origin remotebranch
git checkout remotebranch

This pair of commands is how you access a branch that's on the remote repo and not your local computer yet. First you fetch the branch from the remote origin, then you can use the checkout command.  

Working at your repo: detailed explanation (2)

git pull

Usually you should git pull before you add, commit, and push anything new.
Exception to this: You have a change that you needed to commit but neglected. someone else added changes to the file. If you pulled in those changes, you'd lose your work. In this case, you should add the file first, with git add filename.ext

git status

This tells you the status of your local repo only, whether there is anything new to be added, committed, or pushed.

git remote show origin

Super useful command! git remote show origin provides information on the status of the remote repo on this branch by comparison with your local repo.

Working at your repo: detailed explanation (3)

git add -A

git add filename.ext

git commit -m "your commit message"

This "stages" your files or deletions in git's system to indicate that they are important and should not be overwritten when you do a git pull. You must git add your files before you can commit them. You can add every change with -A, or add only specific files.

You must remember to write a meaningful commit message (ideally short and clear). This will be logged in the git repo's history. Your message documents what this change is about. 

git push

Sends your commit to the remote repo's version of your branch.

Reconciling Branches

After a pull request is merged in to the main branch:

  • The pull request will suggest deleting the remote branch. Good idea: do it!
  • Also delete your local branch. Consider it stale! ​
  • Make a new branch (giving it a distinctive name) when you start work on a new task. (Don't keep an old branch around for this.)

Pull Request: Go to the remote repo and issue a pull request for your peers to merge your branch to the main branch

Git Courtesy: Do not approve your own pull requests. Someone else on your team should review and approve them. You will only approve other people's pull requests. Make a plan for this.

How to delete your local branch: overview of steps

 

After someone has merged your pull request into the main branch on the remote repo, they should delete your remote branch

But your local branch will still persist in your local repo on your computer. You need to delete it.

You cannot delete a branch that you're currently using.

So switch to another branch before you delete.

How to delete your local branch:

git commands (part 1 of 2)

 

If I need to delete a branch named elisaBranch, first I'll have a look at what branches are in my local repo with:  git branch

eeb4@salamander XML % git branch
* elisaBranch
  main

This tells me I have two branches, elisaBranch and main. The asterisk (*) shows I'm currently in the elisaBranch.
To delete elisaBranch, switch to main with:  git checkout main

eeb4@salamander XML % git checkout main
D	Class-Examples/XML/joeyClassPush.xml
Switched to branch 'main'
Your branch is up to date with 'origin/main'.

When you checkout the other local branch, git will show you that your files change. The other branch may not have the same files you worked on, so it will show these as deleted.

If you've had a pull request from your branch accepted, that's okay! You just need to pull in the changes to from the remote main branch. 

How to delete your local branch:

git commands (part 2 of 2)

 

So now that we've moved onto the local main branch, we should run:  git pull

You might see something like this: 

eeb4@salamander Class-Examples % git pull
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 8 (delta 4), reused 8 (delta 4), pack-reused 0
Unpacking objects: 100% (8/8), 343.71 KiB | 1.83 MiB/s, done.

Now that we're on the main branch and we've updated it from the accepted pull request, we can safely delete the local elisaBranch with:
git branch -d elisaBranch

The response shows us the branch was deleted. We can always confirm that by running: git branch
which displays the branches in your remote repo.

eeb4@salamander Class-Examples % git branch -d elisaBranch
Deleted branch elisaBranch (was c67ace1).

More details!

freecodecamp tutorial on deleting or renaming a local branch

Update a Special Branch from the Main Branch—on the Web Remote

  • Sometimes you've been working on a special branch for a while, and your teammates on the main branch have moved on with some important new commits.
  • You're not ready to send your branch to them yet, but you want the latest commits from their branch.
  • On the web repo, make a Pull Request to merge from the main branch into the (base) specialized branch (not the other way around). This is the one instance when it's okay to accept your own PR.
  • You'll be prompted about whether you want to rebase or merge. Usually its best to merge, but read on to learn the difference!

 

Be sure you are clear on:

  • which branch has the new material to deliver
  • which branch is the receiving the new material.
  • Notice if there are going to be merge conflicts and prepare to resolve them file by file. The web repo guides you through this process.

Updating a Special Branch from the Main Branch—On your local machine

You can also merge in changes from another branch to your own branch on your local computer. This can be tricky, but may be useful.

 

Again, be sure you are clear on:

  • which branch has the new material to deliver
  • which branch is the receiving the new material.
  • Say you are working on something specialized in your dev branch.
  • Your teammates have updated the main branch with something new that you need in your branch
  • You may want to merge the changes from the main branch into your dev branch
  • Here is one way to do that:
    • First, switch to the main branch and bring it up to date (pull in all changes.
      • git checkout main
      • git pull
    • Then switch to the dev branch and merge in the new changes from main.
      • git checkout dev
      • git merge main

One way to update your branch: merging

What merging does:

Think of it as weaving or interlacing the commits on your branches, keeping them in order and preserving their time-stamps

Image source: https://needoneapp.medium.com/git-merge-vs-git-rebase-17392c4d870d

Merging gets complicated...

When you merge multiple branches, it starts to create a complicated web in your git repo history, maybe difficult to follow: 

Image source: https://needoneapp.medium.com/git-merge-vs-git-rebase-17392c4d870d

  • To avoid the "tangled" history produced by merging, you may want to rebase your branch.
  • Rebasing pulls in the updates from the main branch and pushes your special commits to the end of the history.
    • Warning: this does resequence the commit history; some coders prefer to avoid rebasing as a result. Others prefer rebasing to simplify the git history.
  • First, switch to the main branch and bring it up to date (pull in all changes.
    • git checkout main
    • git pull
  • Then switch to the dev branch and rebase its commits with the latest from main branch:
    • git checkout dev
    • git rebase main
    • git push --force
  • Note the **forceful** git push at the end. Git requires this because rebase resequences the repo's history! 

Another way to update your branch: rebasing

Rebasing: Pushing your branch's commits to the tip of the main branch

Image source: https://itnext.io/advantages-of-git-rebase-af3b5f5448c6

For more details see:

 

Remember:

  • Use git mindfully and it will serve you well!
  • You'll gain fluency with practice.
  • Working on a shared project using git gives you plenty of practice!