Wilson Mar bio photo

Wilson Mar

Hello!

Calendar YouTube Github

LinkedIn

Git stores changes to use GitHub for backup and change management

US (English)   Norsk (Norwegian)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   Napali   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean

Overview

This video shows how Git works with GitHub (or GitLab) to download files, and how Git’s clone and push makes GitHub a better backup than redundant copies of files.

Video

(The diagram above was created using Camtasia 3 on Mac based on screenshots in PowerPoint containing the narrative below.)

Narrative (captioning)

GitHub.com (and its equivalents) store repositories, or repos for short.

If we want a copy of a repo on our local machine, we have several choices.

If we don’t intend on changing anything, on GitHub we can click Download ZIP to download a file to our machine’s Downloads folder.

github-download-599x257-59kb

The name of the zip file downloaded has two parts: the repo’s name and the branch downloaded. This is because a zip file is designed to contain only one rather than multiple branches like Git.

After we unzip to a new folder, its files are accessible by a Mac Finder or Windows File Explorer as well as IDEs and custom apps.

Apps usually have their own default folder so they have a consistent place to look for assets. So many unzip directly into that default folder.

There is always risk of hardware or human failure, so we need to be able to fall back on older versions. Traditionally, duplicate copies of files and entire disks are created occasionally as backups, with zip files copied to an external location (usually with a date and time stamp in the file folder name). But these occasional copies usually don’t happen often enough, so there is still risk of loss.

And, external copies make it difficult to compare differences among different versions, even though IDEs have their own utility to compare files to find differences.

So most people think this a messy, error-prone approach.

The more popular alternative today is, instead of making duplicate copies, install a Git client program that stores the entire history of changes in its local .git folder containing objects that track every change in every file.

Git clients have a low-level mechanism to identify differences. So you don’t need to keep multiple full backups copies locally. The program recognizes various git commands that many IDEs also can issue.

So you don’t need to use Terminal commands all the time.

Instead of manual downloads and unzips, the client program clone repos from a remote GitHub.

Incremental changes are pushed back to the remote repository.

GitHub is, essentially, the ultimate external backup.

git-why-650x274-80kb

About Git People

https://www.openhub.net/p/git

https://www.openhub.net/accounts/gitster Gitster Junio C Hamano in San Jose. programs in C.

https://www.openhub.net/accounts/Linus-Torvalds

More

This is one of a series on Git and GitHub:

  1. Git and GitHub videos

  2. Why Git? (file-based backups vs Git clone)
  3. Git Markdown text

  4. Git basics (script)
  5. Git whoops (correct mistakes)
  6. Git messages (in commits)

  7. Git command shortcuts
  8. Git custom commands

  9. Git-client based workflows

  10. Git HEAD (Commitish references)

  11. Git interactive merge (imerge)
  12. Git patch
  13. Git rebase

  14. Git utilities
  15. Git-signing

  16. Git hooks
  17. GitHub data security
  18. TFS vs GitHub

  19. GitHub actions for automation JavaScript
  20. GitHub REST API
  21. GitHub GraphQL API
  22. GitHub PowerShell API Programming
  23. GitHub GraphQL PowerShell Module