# Command Line & GIT
---
## Useful Links
### Command Line General
[Navigating the Filesystem Cheatsheet](https://www.codecademy.com/learn/learn-the-command-line/modules/learn-the-command-line-navigation/cheatsheet)
### Git & GitHub
[Git Handbook from GitHub ](https://guides.github.com/introduction/git-handbook/)
[Git Cheat Sheet from GitHub ](https://education.github.com/git-cheat-sheet-education.pdf)
[Codecademy Cheat Sheets ](https://www.codecademy.com/learn/learn-git/modules/learn-git-git-workflow-u/cheatsheet)
[Cheat Sheet from GitHub 2 (not as good)](https://training.github.com/downloads/github-git-cheat-sheet/)
[GitHub HelloWorld walkthrough ](https://guides.github.com/activities/hello-world/)
## Table of Contents
[TOC]
# Command Line
Command line: text interface for the computer's operating system
* you can use it to traverse and edit your computers filesystem
you can:
* create new files
* edit the contents of files
* delete files
**Bash**
We access the command line through bash
## Filesystem
**Directories** - when using command line we refer to folders as directories
**filesystem** - files and directories on your comp are organized into filesystems
Tree structure (a heirarchy)
1. **root directory:** 1st directory. the parent of all other directories + files in filesystem
2. each parent directory can contain more child directories and files
3. The parent-child relationship continues as long as directories and files are nested.
**path** - sequence of directories
**argument** - when a file directory, or program is passed into a command line, its called an argument
## Commands
### ls
lists the directory contents
`ls` options
* `-a` \- lists all contents, including hidden files and directories
* `-l` \- lists all contents of a directory in long format, as well as the file permissions
* `-t` \- orders files and directories by the time they were last modified.
#### Combining Options
`ls -alt` lists all contents including
* hidden files and directories
* in long format
* ordered by the date and time they were last modified.
### pwd
stands for "print working directory"
Outputs the name of directory you are currently in
this is called the *working directory*
### cd
**cd**: stands for "change directory"
changes the working directory
argument = directory name
to move up one directory use `cd..`
`
$ cd ..
`
To navigate directly to a directory:
use cd with a **path** as an argument -
ex `cd jan/memory`
### ~
home director - ~ is a shortcut for the home directory
> which contains your personal files
### mkdir
`mkdir` command stands for “make directory”.
🗳 Argument: ==directory name==
what it does: creates a **new directory** in the current working directory.
* takes in a directory name as an argument
* and then **creates a new directory** in the current working directory.
### touch
`touch` command
what it does: creates a **new (empty) file** inside the current working directory
🗳 Argument: ==filename==
filename argument - name of new empty document
### Helper Commands
:::info
`clear`
used to clear terminal
note: doesn't change or undo previous commands
* just clears view
:::
tab(button) can be used to autocomplete your command.
> When typing name of an existing file or directory, use tab to finish the rest of the name.
:arrow_up: :arrow_down: Up & down arrows can be used to cycle through your previous commands.
:arrow_up: will take you up through your most recent commands
:arrow_down: will take you back through to the most recent one.
## Manipulation
### cat
`cat` command outputs content of a specific file (to the terminal)
useful for:
* peeking at files without opening them
* confirming results of other commands that change the contents of files
### Copying Moving & Removing Files
#### cp
`cp` command copies files or directories
below, we copy the contents of a source file into a destination file:
```
cp source.txt destination.txt
```
We could also copy a file to a destination directory:
```
cp source.txt destination/
```
To copy multiple files into a directory:
use `cp` with 2 arguments
1st arg: a list of source files
last arg: the destination directory
here we copy files file1.txt and file2.txt into the same directory
```
cp file1.txt file2.txt my_directory/
```
#### Wildcards *
use special character `*` to select groups of files
#### mv
`mv` command moves files
without making a copy
:::info
*To move a file into a directory:*
use `mv` with the source file as 1st argument
& destination directory as the 2nd argument.
Here we move **my_file.txt** into **my_directory/**.
```
mv my_file.txt my_directory/
```
*To move multiple files into a directory:*
use `mv` with a list of source files as 1st arguments
& destination directory as last argument.
Here, we move **my\_file\_1.txt** and **my\_file\_2.txt** into **my_directory/**.
```
mv my_file_1.txt my_file_2.txt my_directory/
```
*To rename a file:*
use `mv` with old file as the 1st argument
new file as 2nd argument.
By moving **file_original.txt** into **file_renamed.txt**, we rename the file as **file_renamed.txt**.
```
mv file\_origin.txt file\_renamed.txt
```
:::
#### rm
`rm` command deletes files and directories
```
git rm file
```
*options*
`-r` option
* stands for recursive
* used to delete a directory and all of its child directories
:::danger
Be careful when you use `rm`! It deletes files and directories permanently. There's no undelete command
:::
### Redirecting Input & Output
`stdin` standard input - information inputted into terminal through keyboard or input device
`stdout` standard output - info outputted after a process is run
`stderr` standard error - error message outputed by a failed process
Redirection reroutes standard input, standard output, and standard error to or from a different location.
`echo` command. - takes a string as stdin and prints that string as stdout
#### >
`>` command redirects standard output to a file
```
$ cat deserts.txt > forests.txt
```
`>` takes the standard output of the command on the left, and redirects it to the file on the right.
:pushpin: Note: `>` overwrites all original content in **forests.txt**.
#### >>
use `>>` to add to a file without losing original text
```
$ cat deserts.txt >> forests.txt
```
`>>` takes the standard output of the command on the left and _appends_ (adds) it to the file on the right.
#### <
```
$ cat < deserts.txt
```
`<` takes the standard input from the file on the right and inputs it into the program on the left
#### |
`|` is a “pipe.”
The `|` takes the standard output of the command on the left, and _pipes_ it as standard input to the command on the right.
You can think of this as “command to command” redirection.
```
$ cat volcanoes.txt | wc
```
Above, the output of `cat volcanoes.txt` becomes the standard input of `wc`. in turn, the `wc` command outputs the number of lines, words, and characters in **volcanoes.txt**, respectively.
#### sort
`sort` takes stdin and orders it alphabetically for stdout (it doesn't change the file itself)
```
$ cat glaciers.txt | sort > sorted-glaciers.txt
```
Here, the command takes the standard output from `cat glaciers.txt` and “pipes” it to `sort`. The standard output of `sort` is redirected to a new file named **sorted-glaciers.txt**.
#### uniq
`uniq`
* stands for unique
* filters out adjacent, duplicate lines in a file
```
$ sort deserts.txt | uniq
```
this is more effective way to use `uniq` -
1. calls `sort` to alphabetize a file,
2. “pipe” the standard output to `uniq`.
By piping `sort deserts.txt` to `uniq`, all duplicate lines are alphabetized (and thereby made adjacent) and filtered out.
#### grep
* stands for "global regular expression print"
* searches files for lines that match a pattern and then returns the results
* is case sensitive
`grep -i` enables command to be case insensitive
`grep -R` searches all files in a directory - outputs filenames and lines containing matched results
* -R stands for "recursive"
`grep -Rl` searches all files in a directory and outputs only filenames with matched results (so no lines). `l` (a lowercase `L`, not a capital `i`) stands for “files with matches.”
#### sed
`sed` stands for "stream editor"
* accepts stdin and modifies it based on an expression, before displaying it as output data
* its similar to "find and replace"
```
sed 's/snow/rain/' forests.txt
```
Let’s look at the expression `'s/snow/rain/'`:
* `s`: stands for “substitution.” It is _always_ used when using `sed` for substitution.
* `snow`: the search string, or the text to find.
* `rain`: the replacement string, or the text to add in place.
In this case, `sed` searches **forests.txt** for the word “snow” and replaces it with “rain.” Importantly, the above command will only replace the first instance of “snow” on a line.
```
sed 's/snow/rain/g' forests.txt
```
The above command uses the `g` expression, meaning “global.” Here `sed` searches **forests.txt** for the word “snow” and replaces it with “rain” _globally_. This means _all_ instances of “snow” on a line will be turned to “rain.”
## bash
A bash profile is a file used to store environment settings for your terminal, and it’s accessible by the name **~/.bash_profile**.
* When a session starts, it loads the contents of the bash profile before executing commands.
* The `~` represents the user’s home directory.
* The `.` indicates a hidden file.
* The name **~/.bash_profile** is important, since this is how the command line recognizes the bash profile.
To open and edit the bash profile, you can use the command:
```
nano ~/.bash_profile
```
* when you edit a bash profile you can add commands to execture every time a new terminal session is started
To activate changes made in ~/.bash_profile for the current session - use the command:
```
source ~/.bash_profile
```
this makes changes in bash profile available right away without closing the terminal and needing to start a new session
### alias
`alias`command allows you to create keyboard shortcuts, or aliases, for commonly used commands.
### Environment Variables
variables that can be used across commands and programs and hold information about the environment
---
---
---
# GIT
**Git**: software that allows you to keep track of changes made to project over time
Git records the changes you make to a project, stores those changes, and allows you reference them as needed
## Why Git?
* Git lets developers see the entire timeline of their changes, decisions, and progression of any project in one place. From the moment they access the history of a project, the developer has all the context they need to understand it and start contributing.
* With a DVCS like Git, collaboration can happen any time while maintaining source code integrity. Using branches, developers can safely propose changes to production code.
* Businesses using Git can break down communication barriers between teams and keep them focused on doing their best work. Plus, Git makes it possible to align experts across a business to collaborate on major projects.
## Git Workflow
**Working Directory:** where you'll be doing all the work:
* creating, editing, deleting and organizing files
**Staging Area**: where you'll list changes you make to the working directory
**Repository**: where Git permanently stores those changes as different version
**
## Git Commands
### Basic terminology
#### respository
encompasses the entire collection of files and folders associated with a project, along with each file’s revision history
### Setting up
to check if Git is already installed on your comp: you can type the command
```git --version```
* if already installed - will see version you have
CLONING
```shell
$ git clone https://github.com/USERNAME/REPOSITORY.git
```
When you run `git clone`, the following actions occur:
- A new folder called `repo` is made
- It is initialized as a Git repository
- A remote named `origin` is created, pointing to the URL you cloned from
- All of the repository's files and commits are downloaded there
- The default branch is checked out
### Approaches
source: [Set Up With Git & GitHub](https://www.codecademy.com/articles/f1-u3-git-setup)
Create a new directory locally and make the new directory your working directory
1. `mkdir git_practice` to make a new directory to practice.
2. `cd git_practice` to make the new directory your working directory.
3. `git init` to turn the current, empty directory into a fresh Git repository
### Initialize
Turn it into a git project:
```
git init
```
init - means initialize
### Working Directory and Staging Area
#### status
inspects the contents of the working directory and staging area:
```git
git status
```
#### add
To start tracking changes - you need to add file to staging area
Add a file to staging area:
```git
git add filename
```
stage all files in current directory
```
git add .
```
Stage all files
```
git add -A
```
#### diff
To check differences between working directory and staging area:
```
git diff filename
```
Use `git diff filename` before adding new content to ensure that you are making the changes you expect.
### Commit
**Commit**: the last step in github workflow
* Permanently stores changes for straging area inside repository
```
git commit -m "Complete first line of dialogue"
```
Standard Conventions for Commit Messages:
* Must be in quotation marks
* Written in the present tense
* Should be brief (50 characters or less) when using -m
#### Rules to live by for commit messages:
- Don’t end your commit message with a period.
- Keep your commit messages to 50 characters or less. Add extra detail in the extended description window if necessary. This is located just below the subject line.
- Use active voice. For example, "add" instead of "added" and "merge" instead of "merged".
- Think of your commit as expressing intent to introduce a change.
#### log
To view earlier versions of project
```
git log
```
From the terminal, log a list of your commits.
In the output, notice:
* A 40-character code, called a SHA, that uniquely identifies the commit. This appears in orange text.
* The commit author (you!)
* The date and time of the commit
* The commit message
To show the commits on branchA that are not on branchB:
```
git log branchB..branchA
```
### Backtracking
#### checkout HEAD
`git checkout HEAD filename`
* Discards changes in the working directory.
* rolls back all changes that have been made to `filename` since the last commit.
* will change your working directory to look exactly as it did when you last made a commit.
Use`git diff` to see if **rollback was successful**
> if it doesn't output anything = your working directory matches your last commit
#### reset HEAD
To unstage from staging area:
```
git reset HEAD filename
```
Removes `filename` from staging area
:pencil: NOTE: does _not_ discard file changes from the working directory
example use: might use this command if you’ve added a file to the staging area, but the file includes incorrect edits.
Use `git status` to make sure file was properly removed from staging area
#### reset commit_SHA
`git reset commit_SHA`
* Resets to a previous commit in your commit history
* replace SHA with first 7 characters of commit you want to backtrack to
this commit will become new head and all commits that came after will be deleted
Github cheatsheet
[https://education.github.com/git-cheat-sheet-education.pdf](https://education.github.com/git-cheat-sheet-education.pdf)
## Branches
Check which branch i'm on
```
git branch
```
>In the output, the `*` (asterisk) is showing you what branch you’re on
### New branch
Creates a new branch:
```
git branch branch_name
```
#### Branch Name
Branches should be named something that describes the purpose of the branch.
:pencil: Note: branch names can’t contain whitespace
>valid branch names: `new-feature` and `new_feature`
not valid: `new feature`
Renaming
Rename local branch that is current HEAD branch
```git
git branch -m <new-name>
```
### Switch Branches
To switch from one branch to another:
```
git checkout branch_name
```
_Git version 2.23, a new command called `git switch` was introduced to eventually replace `git checkout`_
#### New branch AND switch
```git
git checkout -b yourbranchname
```
### MERGE Branches
To join file changes from one branch to another:
```
git merge branch_name
```
### Delete branch
delete branch (only if it’s merged)
```
git branch -d branch_name
```
Deletes branch (even if not merged)
```
git branch -D <branch>
```
* Force delete the specified branch, even if it has unmerged changes.
* use this command if you want to permanently throw away all of the commits associated with a particular line of development
## Collaboration
remote : a shared Git repository, that lives _outside_ your Git project folder, and allows multiple collaborators to work on the same Git project from different locations.
Remotes can live on the web, on a shared network or even in a separate folder on your local computer.
### Clone
```
git clone remote\_location clone\_name
```
`remote_location` : tells Git where to go to find the remote. This could be a web address, or a filepath
`clone_name` : name you give to the directory in which Git will clone the repository.
### See Remotes
To get a list of remote repositories that the current project is tied to:
```
git remote -v
```
* Git lists the name of the remote, `origin`, as well as its location.
* Git automatically names this remote `origin`, because it refers to the remote repository of origin. However, it is possible to safely change its name.
* The remote is listed twice: once for `(fetch)` and once for `(push)`.
### Fetch
see if changes have been made to the remote and bring the changes down to your local copy is with:
```
git fetch
```
Will NOT merge changes from remote into your local repository.
Instead, it brings those changes onto what’s called a _remote branch_.
#### origin/branch-name
to see the existing branches, we can see that fetched data has been stored in a new `origin/master` branch.
```
git branch -a
```
You can use git diff origin/branch-name to see the changes made in the remote
To list only remote branches:
```
git branch -r
```
##### Merge fetched changes
merge fetched changes, stored in `origin/branch-name` to the current `branch-name` branch:
```
git merge origin/branch-name
```
1. create new branch to work on changes
2. List git remotes`git-remote -v`
3. fetch
4. git branch -a to see all branches - specifically origin/branch-name
5. `git diff origin/branch-name` to see differences
6. merge fetched changes `git merge origin/branch-name`
### push
Push the branch, and all committed changes, to the remote
```
git push origin your_branch_name
```
branch can now be reviewed by collaborators
### Workflow
The workflow for Git collaborations typically follows this order:
1. Fetch and merge changes from the remote
2. Create a branch to work on a new project feature
3. Develop the feature on your branch and commit your work
4. Fetch and merge from the remote again (in case new commits were made while you were working)
5. _Push_ your branch up to the remote for review
---
## Merge Conflicts
**Merge conflict** occurs when:
* changes are made to the same part of the same file on two different branches.
* when one person edits a file and another person deletes the same file
You usually find out about conflicts in a pull request
### GitHub Conflict Editor
you canonly resolve merge conflicts on GitHub that are **caused by competing line changes**,
> such as when people make different changes to the same line of the same file on different branches in your Git repository.
For all other types of merge conflicts, you must resolve the conflict locally on the command line.
[Resolving a merge conflict on GitHub](https://docs.github.com/en/github/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-on-github)
1. Under your repository name, click **Pull requests**.
2. In the "Pull Requests" list, click the pull request with a merge conflict that you'd like to resolve.
3. Near the bottom of your pull request, click **Resolve conflicts**.
**Tip:** If the **Resolve conflicts** button is deactivated, your pull request's merge conflict is too complex to resolve on GitHub. You must resolve the merge conflict using an alternative Git client, or by using Git on the command line. For more information see "[Resolving a merge conflict using the command line](https://docs.github.com/en/articles/resolving-a-merge-conflict-using-the-command-line)."
4. Decide if you want to keep only your branch's changes, only the other branch's changes, or make a brand new change - may incorporate changes from both branches.
Delete the conflict markers `<<<<<<<`, `=======`, `>>>>>>>` and make the changes you want in the final merge.
5. If you have more than one merge conflict in your file, scroll down to the next set of conflict markers and repeat steps four and five to resolve your merge conflict.
6. Once you've resolved all the conflicts in the file, click **Mark as resolved**.
7. If you have more than one file with a conflict, select the next file you want to edit on the left side of the page under "conflicting files" and repeat steps four through seven until you've resolved all of your pull request's merge conflicts.
8. Once you've resolved all your merge conflicts, click **Commit merge**. This merges the entire base branch into your head branch.
9. If prompted, review the branch that you are committing to.
If the head branch is the default branch of the repository, you can choose either to update this branch with the changes you made to resolve the conflict, or to create a new branch and use this as the head branch of the pull request.
If you choose to create a new branch, enter a name for the branch.
If the head branch of your pull request is protected you must create a new branch. You won't get the option to update the protected branch.
Click **Create branch and update my pull request** or **I understand, continue updating _BRANCH_**. The button text corresponds to the action you are performing.
10. To merge your pull request, click **Merge pull request**
### Recap
* Use Git commands to help keep track of changes made to a project:
* `git init` creates a new Git reposit
* `git status` inspects the contents of the working directory and staging area
* `git add` adds files from the working directory to the staging area
* `git diff` shows the difference between the working directory and the staging area
* `git commit` permanently stores file changes from the staging area in the repository
* `git log` shows a list of all previous commits
* `git clone` creates a local copy of a project that already exists remotely. The clone includes all the project’s files, history, and branches.
* `git branch` shows the branches being worked on locally.
* `git merge` merges lines of development together. This command is typically used to combine changes made on two distinct branches.
For example, a developer would merge when they want to combine changes from a feature branch into the main branch for deployment.
* `git push` updates the remote repository with any commits made locally to a branch
# GitHub
Anything on the main branch is deployable
## GitHub Workflow
resources: [https://guides.github.com/introduction/flow/](https://guides.github.com/introduction/flow/)
Create branch :arrow_right:
Make Commits :arrow_right:
Pull Request :arrow_right: Deploy Branch
### Creat Branch
create a branch: new branch is an environment where you can try out new idea
* Changes you make on a branch don't affect the `main` branch
* new branch should be created off the main branch
* because anything on main branch is deployanle
* branch name should be descriptive (e.g., `refactor-authentication`, `user-content-cache-key`, `make-retina-avatars`), so that others can see what is being worked on.
### Make Commits
* when you add, edit, or delete a file, you're making a commit, and adding them to your branch.
* This process of adding commits keeps track of your progress as you work on a feature branch.
* commits create transparent history that others could follow
* each commit = sepearte unit of change
* lets you roll back changes if a bug is found
**commit message**: description explaining why change was made
### Pull Request
resources: [github guide pull requests](https://guides.github.com/activities/hello-world/)
A pull request allows other team members to review, evaluate, and offer feedback on your code in order to verify that your branch will function as intended and not break the code within the
> Pull requests show _diffs_, or differences, of the content from both branches. The changes, additions, and subtractions are shown in green and red.
>As soon as you make a commit, you can open a pull request and start a discussion, even before the code is finished.
>When you create a pull request, include a summary of the changes and what problem they solve. You can include images, links, and tables to help convey this information. If your pull request addresses an issue, link the issue so that issue stakeholders are aware of the pull request and vice versa. If you link with a keyword, the issue will close automatically when the pull request merges.
### Deploy Branch
You can deploy from a branch for final testing in production before merging to main.
Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production.
If your branch causes issues, you can roll it back by deploying the existing main branch into production.
### merge branch into main
Now that your changes have been verified in production, it is time to merge your code into the main branch.
---
#### Contribute to an existing repository
```
# download a repository on GitHub.com to our machine
git clone https://github.com/me/repo.git
# change into the `repo` directory
cd repo
# create a new branch to store any new changes
git branch my-branch
# switch to that branch (line of development)
git checkout my-branch
# make changes, for example, edit `file1.md` and `file2.md` using the text editor
# stage the changed files
git add file1.md file2.md
# take a snapshot of the staging area (anything that's been added)
git commit -m "my snapshot"
# push changes to github
git push --set-upstream origin my-branch
```
---
#### Start a new repository and publish it to GitHub
```
# create a new directory, and initialize it with git-specific functions
git init my-repo
# change into the `my-repo` directory
cd my-repo
# create the first file in the project
touch README.md
# git isn't aware of the file, stage it
git add README.md
# take a snapshot of the staging area
git commit -m "add README to initial commit"
# provide the path for the repository you created on github
git remote add origin https://github.com/YOUR-USERNAME/YOUR-REPOSITORY.git
# push changes to github
git push --set-upstream origin main
```
## README file
resources: [How to write a good README](https://bulldogjob.com/news/449-how-to-write-a-good-readme-for-your-github-project)
File extension typically used for README file on GitHub : `.md`
README is first file you should read when starting a new project
* on GitHub - appears under list of files in a repository
Purpose of a good README:
* for others to understand what our code includes and why its noteworthy
* also essential to retreive aproject - on GitHub but also in browser
* enables you to relaunch a project - without wasting your time on recalling: _What was it all about? _
Writing a good README
* make sure file always inclues:
* titles and internal titles
* introduction - the project's aim
* technologyies
* launch
* consider also using additonal elements such as:
* table of contents
* illustrations
* scope of functionalities
* examples of use
* project status
* sources
* other
### Tites and internal titles
Should explain clearly what we have here
usueally a project's name
### Introduction
* like a summary
* shouldn't be too long
* should describe in an interesting manner what's the project aim, and what problems does a given application solve
* 2 or 3 sentences are enough for a small project
If its a training project, mention your incentive
> Why did you want to create it? To learn a particular technology? Was it a hackathon project? Was it for a non-profit organization? Is it an application created to memorize the material from workshops or and online course? It's worth mentioning here, without a doubt.
Google Drive
Gist
Clipboard
Sign in with Wallet
