Old-School Repository Systems

• Every copy of the repo knew if it was a copy or the main
• Only one person could work on a file at a time.
• They were conceptually simpler and didn't require tutorials like this one.

Old-School Repository Systems

Git

• Each copy could be either the main or a copy.
• Each copy has references to "remotes", which are just other instances of that repository.
• The main repository is agreed upon by convention; usually at GitHub, GitLab, etc. But doesn't have to be.
• Several people can work on the same file at the same time.

Git

Branching

• A Branch is an independent line of development.
• A Branch is a series of commits.
• Branching is done within an instance of a repo.
• Everyone with access to that repo instance can see all its branches.
• Branching creates a copy of all the tracked files at the time of branching.
• As you edit files in the new branch, the files in the original branch remain unchanged from the time you created the new branch.
• Anyone with access to that instance of that repo can create a new branch from the original (without your changes) or your new branch (with your changes up to the last commit on your branch); or edit the files in the original branch.

Branching

A repo starts out with a main branch: a set of files with a history of changes (ie: commits).

Branching

• Create a branch when you're going to start doing work (fixing a bug, adding a new feature).
• Work should rarely, if ever, be done on the main branch.
• $ git checkout -b branchName

Branching

• If you're part way through adding a feature, and need to fix a bug: create a branch from main that won't include any of the unfinished code in your new feature.
• As long as the changes on the different branches aren't in the same spot in the same file, Git should be smart enough to merge them without issue.
• If there are changes to the same spot in the same file, then a merge conflict will arise, and will needed to be sorted out manually. That's beyond the scope of this tutorial.
• $ git checkout main
  then
  $ git branch other_new_branch_name

Cloning

• Cloning creates a copy of the repo on your computer.
• Downloads all files in the main branch, including config files.
• Sets the cloned-from repo as the origin remote.
• Use this (ie: cloning) when you first want to contribute to a repo.
• Only use once on each computer. Once you've cloned, the repo is there. You have it. From then on, to get the latest code, use git pull or git rebase.
• $ git clone [git address]

Cloning

Forking

• Forking a repo creates an instance of a repo (branches, commit history, etc.) on your own GitHub account.
• When forking, your forked repo automagically sets the original repo as "Upstream" allowing you to easily get new changes.

Forking

Forking

Cloning, Branching, and Forking

Cloning

Copies a repo (files and some configuration) from one computer to another

Used when starting to contribute to a project for the very first time on that computer.

Branching

Creates a copy of all files in a repo so they can be edited without affecting the original files

Used when adding a feature or fixing a bug

Forking

Creates a copy of a repo (on the same system as the original repo) to the forkers account

Used when either creating a brand new thing based on an old thing. (Ex: Waterfox is a fork of Firefox. Waterfox will never merge back into Firefox).

Also can be used where there are a lot of people on a project when "branch hell" and "commit history hell" is to be avoided.

Also can be used when you want to do some experimental things knowing you'll problably throw your copy away when you're done.

Workflow With Write Access To Repo

• For our example, Jane Schmoe is part of the organization. She doesn't need to clone (because that was already done before when she first joined the org).
• But she needs to pull before she gets started.
• Pulling gets the latest commits from elsehwere and merges them here.
• In this case, Jane pulls from the origin so she has everything on her computer.

Starting Work

• After pulling, but before starting to work, she creates a new branch. It's dangerous to work on the main branch.

Working

Your Local Repo

At this point it's worth mentioning how your local repo works.

• Your local copy has three parts: The Index or Working Directory, Staging, and the repo itself.
• When you're editing files locally, simply saving them has no effect on the repo itself.
• When you add a new file into your folder, it still isn't part of the repo. It's not being tracked.
• All your edits, additions, and removals are all part of the "Working Directory" or the "Index".
• In order to get Git to start tracking new files and updated files you need to move them to "Staging".
• Moving to staging can be done by $ git add filename, or to add all at once: $ git add . (inlcuding the ".").
• Then, once staged, files can be committed to the repo.
• This can be done with: $ git commit -m "Some notes about the commit here".
• Once changes have been committed, a new commit (ie: a snapshot in time) is created.
• This commit can now be merged into another local branch, or pushed to a remote.

Add Changes to Staging

$ git add .

Commit Changes to Repo

$ git commit -m "Added a feature"

Push Changes to Origin

$ git push origin myNewFeature

Pushed Changes to Origin

Now GitHub has Jane's myNewFeature branch.

Merge Changes on Origin

Create a Pull Request on GitHub and delete myNewFeature branch.

Note that myNewFeature branch still exists on Jane's local machine until she deletes it. ($ git branch -D myNewBranch)

Workflow With A Forked Repo

• For this example, Joe Schmoe is not part of the organization, but still wants to contribute.
• To get started, he'll need to fork to create his own copy of the repo on GitHub.

Workflow With A Forked Repo

Then he'll clone to get a copy of the repo on his own computer.

Local Repo With Two Remotes

Now Joe pulls from the upstream remote (organization's repo) and pushes to the origin remote (Joe's copy on his GitHub account).

Basic Workflow With A Forked Repo

After pushing changes, Joe submits a Pull Request (PR) to have his changes added to the main repo.

Full Workflow With A Forked Branch

Useful git Commands

git status

Tells you what branch you're on, what files are in your working directory, but not staging; staging but not the repo. Sometimes gives you hints as to what to do next.

git checkout [branch_name]

Sets your current working directory to be in the branch called "branch_name".
Example: $ git checkout myNewFeature puts you into the myNewFeature branch. Now all changes you make won't affect any other branch in your repo until you merge the changes into them.

Useful git Commands (cont.)

git pull [remote_name] [branch_name]

Fetches the branch called "branch_name" from the remote called ["remote_name"] into your local repo, and merges the changes into your Working Directory into whatever branch you have checked out at the moment.
Example (continuing from above): $ git pull origin main pulls the main branch of the origin remote into your myNewFeature branch.

git add .

Get's all your changes ready for commiting by adding them from your Working Directory into your Staging Area.

Useful git Commands (cont.)

git commit -m "Commit notes go here"

Makes a snapshop in time; commits your changes to your local copy of the repo. It's ready to be pushed. Note: You can add the -a option to skip the previous step if there are no new files added.
Example: $ git commit -a -m "Fixed a typo identified in Issue #34"

git push [remote_name] [branch_name]

Copies your latest commits to the branch called "branch_name" on the remote called "remote_name". If [branch_name] doesn't exist on [remote_name], then one will be created.
Example (continuing from above): $ git push origin myNewFeature copies your changes in your myNewFeature branch to your repo on GitHub.