DEV Community: Mustafa Hashmani

Rebasing: The Scariest Git Command?

Mustafa Hashmani — Wed, 23 Aug 2023 18:12:49 +0000

Why do we need Rebasing?

I'm working on a collaborative project
I make a feature branch!
I do some work on the branch and some more work on the branch
Meanwhile, Master has new work on it and my feature branch doesn't have this work!
I merge master into feature and this results in a new merge commit
I keep working on my feature branch and a coworker adds new work to master
I merge master in to my feature branch and this results in yet another merge commit!
The feature branch has a bunch of merge commits. If the master branch is very active, my feature branch's history is muddied

Why Rebase?

We get a much cleaner project history.
No unnecessary merge commits!
We end up with a linear project history.

Rebasing

We can instead rebase the feature branch onto the master branch. This moves the entire feature branch so that it BEGINS at the tip of the master branch. All of the work is still there, but we have re-written history.
Instead of using a merge commit, rebasing rewrites history by creating new commits for each of the original feature branch commits.
It is not going to change the master branch, instead it is going to rewrite history by taking the feature branch commits and creating new ones that are based on the originals and putting them all at the tip of the master branch
We are BASING that branch on the tip of the master branch

git switch feature
git rebase master

There are two main ways to use the git rebase command:
1. as an alternative to merging
2. as a cleanup tool
Warning
- Never rebase commits that have been shared with others. If you have already pushed commits up to Github...DO NOT rebase them unless you are positive no one on the team is using those commits.
- You do not want to rewrite any git history that other people already have. It's a pain to reconcile the alternate histories!

Interactive Rebase

Sometimes we want to rewrite, delete, rename, or even reorder commits (before sharing them). We can do this using git rebase!
Running git rebase with the -i option will enter the interactive mode, which allows us to edit commits, add files, drop commits, etc. Note that we need to specify how far back we want to rewrite commits.
Also, notice that we are not rebasing onto another branch. Instead, we are rebasing a series of commits onto the HEAD they currently are based on.
```
   git rebase -i HEAD~4 # go back four commits
```
In our text editor, we'll see a list of commits alongside a list of commands that we can choose from. Here are a couple of the more commonly used commands:
- pick - use the commit
- reword - use the commit, but edit the commit message
- edit - use commit, but stop for amending
- fixup - use commit contents but meld it into previous
- commit and discard the commit message
- drop - remove commit

The Different Types of Collaboration Workflows in Git

Mustafa Hashmani — Tue, 22 Aug 2023 06:19:39 +0000

Centralized Workflow

AKA Everyone Works On Master/Main
AKA The Most Basic Workflow Possible
The simplest collaborative workflow is to have everyone work on the master branch (or main, or any other SINGLE branch).
It's straightforward and can work for tiny teams, but it has quite a few shortcomings!
Pamela, Forrest and David clone the repo
Forrest gets to work on a new feature and pushes his work to Github
At the same time, Pamela also worked on a new feature. She tries to push her new work up to Github, but she runs into trouble as the current branch is behind its remote counterpart. So she pulls to get the changes from origin master, merges them and then pushes them
David is working on a new feature, but is having some doubts. He'd like to share his commits with the rest of the team to start a discussion but before he can commit he has to pull from Github and merge them into master Now he can finally push his work up to Github. His teammates can pull to get his new commits.

The Problem

While it's nice and easy to only work on the master branch,
this leads to some serious issues on teams :
- Lots of time is spent resolving conflicts and merging code, especially as team size scales up.
- No one can work on anything without disturbing the main codebase. How do you try adding something radically different in? How do you experiment?
- The only way to collaborate on a feature together with another teammate is to push incomplete code to master. Other teammates now have broken code...

Feature Branches

Rather than working directly on master/main, all new development should be done on separate branches!
- Treat master/main branch as the official project history
- Multiple teammates can collaborate on a single feature and share code back and forth without polluting the master/main branch
- Master/main branch won't contain broken code (or at least, it won't unless someone messes up)
Pamela, Forrest and David clone the repo
David starts work on a new feature. He does all this work on a separate branch!
David wants Pamela to take a look at his new feature. Instead of merging it into master, he just pushes his feature branch up to Github!
Pamela is hard at work on her own new feature. Just like everyone else, she's working on a separate feature branch rather than master.
Pamela hears from David that he wants her to take a look at his new work. She pulls down his feature branch from Github.
Pamela takes a look at the code and makes a couple of improvements of her own. She adds/commits on the same feature branch.
Pamela pushes up her new work on the add-dark-theme feature branch so that David can pull them down.
David fetches from Github and sees that there is new work on the add dark theme branch. He pulls the changes down and continues work.
David decides he is happy with the new feature, so he merges it into master!
David pushes up the updated master branch to Github. The others can now pull down the changes.

Feature Branch Naming
There are many different approaches for naming feature branches. Often you'll see branch names that include slashes like bug/fix-scroll or feature/login-form or feat/button/enable-pointer-events
Specific teams and projects usually have their own branch naming conventions.

Merging In Feature Branches
- At some point, the new work on feature branches will need to be merged into the master branch! There are a couple of options for how to do this :
  - Merge at will, without any sort of discussion with teammates. JUST DO IT WHENEVER YOU WANT.
  - Send an email or chat message or something to your team to discuss if the changes should be merged in.
  - Pull Requests!

Pull Requests

Pull Requests are a feature built into products like Github and Bitbucket. They are not native to Git itself.
They allow developers to alert team-members to new work that needs to be reviewed. They provide a mechanism to approve or reject the work on a given branch. They also help facilitate discussion and feedback on the specified commits.
"I have this new stuff I want to merge into the master branch...what do you all think about it?"

The Workflow

1. Do some work locally on a feature branch
2. Push up the feature branch to Github
3. Open a pull request using the feature branch just pushed up to Github
4. Wait for the PR to be approved and merged. Start a discussion on the PR. This part depends on the team structure.

### Merging Pull Requests with Conflicts

- Just like any other merge, sometimes there are conflicts that need to be resolved when merging a pull request.
- You can perform the merge and fix the conflicts on the command line like normal, or you can use Github's interactive editor.

Fork and Clone

The "fork and clone" workflow is different from anything we've seen so far. Instead of just one centralized Github repository, every developer has their own Github repository in addition to the "main" repo.
Developers make changes and push to their own forks before making pull requests.
It's very commonly used on large open-source projects where there may be thousands of contributors with only a couple of maintainers.
It allows a project maintainer to accept contributions from developers all around the world without having to add them as actual owners of the main project repository or worry about giving them permissions to push to the repo

Forking
- Github (and similar tools) allow us to create personal copies of other people’s repositories. We call those copies a "fork" of the original.
- When we fork a repo, we're basically asking Github "Make me my own copy of this repo please"
- As with pull requests, forking is not a Git feature. The ability to fork is implemented by Github.
- When you click on the fork button on that repository, it will create a copy on your account
- Now that I've forked, I have my very own copy of the repo where I can do whatever I want!
- I can clone my fork and make changes, add features, and break things without fear of disturbing the original repository.
- If I do want to share my work, I can make a pull request from my fork to the original repo.
Workflow
- When we clone a repo, Git automatically adds a remote called origin that points to our forked repo on Github.
- Next, I add a remote pointing to the original project repo
  (NOT the fork). This remote can be named anything, but
  you'll often see "upstream" or "original" used.
```
git remote add upstream <url>
```
- I do some new work locally. To share my changes with others, I cannot push to upstream. I don't have permission! But I can push to origin (my Github fork)
- Next, I can make a pull request from my fork on Github to the original project repository. Now I wait to hear from the project maintainers! Do they want me to make further changes? It turns out they accept and merge my pull request!
- The next day, I get back to work. The official project repo now contains work done by other collaborators. I don't have their new work on my machine! I'm behind!
- All I need to do is pull from upstream (the original repo) to get the latest changes in my local repo.
- Now I have the latest changes from the upstream repo! I can work on some new features locally without working about being out of date.

### Summary

I fork the original project repo on Github
I clone my fork to my local machine
I add a remote pointing to the original project repo. This remote is often named upstream.
I make changes and add/commit on a feature branch on my local machine
I push up my new feature branch to my forked repo(usually called origin)
I open a pull request to the original project repo containing the new work on my forked repo
Hopefully, the pull request is accepted and my changes are merged in!

Unveiling the Art of Sync: Mastering Fetching and Pulling in Git

Mustafa Hashmani — Sun, 20 Aug 2023 11:39:17 +0000

How Cloning Works

After cloning there will be two branch references:
1. A regular branch reference that I can move around myself.(the default branch of the Github repo)
2. origin/master. This is a "Remote Tracking Branch". It's a reference to the state of the master branch on the remote. I can't move this myself. It's like a bookmark pointing to the last known commit on the master branch on origin remote.

Remote Tracking Branches

"At the time you last communicated with this remote repository, here is where x branch was pointing"
They follow this pattern remote/branch.
- origin/master references the state of the master branch on the remote repo named origin.
- upstream/logoRedesign references the state of the logoRedesign branch on the remote named upstream (a common remote name)
Run git branch -r to view the remote branches our local repository knows about.
After committing, the master branch will move but the remote tracking branch will remain unchanged
When you run git status , it will show that the master branch is ahead of ‘origin/master’ by 1 commit. To sync the remote branch with the local branch ,run git push
```
git status
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
```

To go back to the original cloned state, run git checkout origin/master

Remote Branches

Once you've cloned a repository, we have all the data and Git history for the project at that moment in time. However, that does not mean it's all in our workspace!
The github repo has a branch called puppies, but when I run git branch I don't see it on my machine! All I see is the master branch. So what's going on?
Run git branch -r to view the remote branches our local repository knows about.
By default, my master branch is already tracking origin/master but there are no branches to track other remote branches. I want my own local branch called puppies, and I want it to be connected to origin/puppies, just like my local master branch is connected to origin/master.
Run git switch <remote-branch-name> to create a new local branch from the remote branch of the same name and connect it to the remote branch. For example, git switch puppies makes me a local puppies branch AND sets it up to track the remote branch origin/puppies.

Git Fetch

Suppose that while you are working on the Local repository, the Github Repo has changed. How would you get those changes?

Fetching allows us to download changes from a remote repository, BUT those changes will not be automatically integrated into our working files.
It lets you see what others have been working on, without having to merge those changes into your local repo.
Think of it as "Please go and get the latest information from Github, but don't screw up my working directory."
The git fetch <remote> command fetches branches and history from a specific remote repository. It only updates remote tracking branches. For example, git fetch origin would fetch all changes from the origin remote repository.
We can also fetch a specific branch from a remote using git fetch <remote> <branch>. For example, git fetch origin master would retrieve the latest information from the master branch on the origin remote repository.
```
git fetch <remote>
# If not specified, <remote> defaults to origin
```

I now have those changes on my machine, but if I want to see them I have to checkout origin/master. My master branch is untouched!

Git Pull

git pull is another command we can use to retrieve changes from a remote repository. Unlike fetch, pull actually updates our HEAD branch with whatever changes are retrieved from the remote.
"go and download data from Github AND immediately update my local repo with those changes"

To pull, we specify the particular remote and branch we want to pull using git pull <remote> <branch>. Just like with git merge, it matters WHERE we run this command from. Whatever branch we run it from is where the changes will be merged into.
git pull origin master would fetch the latest information from the origin's master branch and merge those changes into our current branch.
If we run git pull without specifying a particular remote or branch to pull from, git assumes the following:
- remote will default to origin
- branch will default to whatever tracking connection is configured for your current branch which is already setup.
For example, if I am on my local master branch, then git pull would pull from origin/master automatically.
Pulls can result in conflicts hence we should always pull first, then merge conflicts and then push.

Git Fetch	Git Pull
Gets changes from remote branch(es)	Gets changes from remote branch(es)
Updates the remote-tracking branches with the new changes	Updates the current branch with the new changes, merging them in
Does not merge changes onto your current HEAD branch	Can result in merge conflicts
Safe to do at anytime	Not recommended if you have uncommitted changes!

Undoing Changes and Time Travelling in Git

Mustafa Hashmani — Fri, 18 Aug 2023 13:39:07 +0000

Checkout

The git checkout command is like a Git Swiss Army knife. Many developers think it is overloaded, which is what lead to the addition of the git switch and git restore commands
We can use checkout to create branches, switch to new branches, restore files, and undo history!
We can use git checkout <commit-hash> to view a previous commit. We just need the first 7 digits of a commit hash which can be obtained through git log --oneline. Doing so will result in a Detached Head. Now the git log will change because we have moved back in time
git checkout supports a slightly odd syntax for referencing previous commits relative to a particular commit.
- HEAD~1 refers to the commit before HEAD (parent)
- HEAD~2 refers to 2 commits before HEAD (grandparent
```
git checkout HEAD~1
```
Discarding Changes
- Suppose you've made some changes to a file but don't want to keep them. To revert the file back to whatever it looked like when you last committed, you can use:
  - git checkout HEAD <filename> to discard any changes in that file, reverting back to the HEAD.

Restore

git restore is a brand new Git command that helps with undoing operations. git restore was introduced alongside git switch as an alternative to some of the uses for checkout.
Suppose you've made some changes to a file since your last commit. You've saved the file but then realize you definitely do NOT want those changes anymore!
To restore the file to the contents in the HEAD, use git restore <file-name>
git restore <file-name> restores using HEAD as the default source, but we can change that using the --source option.
For example, git restore --source HEAD~1 home.html will restore the contents of home.html to its state from the commit prior to HEAD. You can also use a particular commit hash as the source.
git status will always remind you what to use!

Unstaging Files with Restore
- If you have accidentally added a file to your staging area with git add and you don't wish to include it in the next commit, you can use git restore to remove it from staging.
- Use the --staged option like this:
```
git restore --staged <file-name>
```

Git Reset

Suppose you've just made a couple of commits on the master branch, but you actually meant to make them on a separate branch instead. To undo those commits, you can use git reset.
git reset <commit-hash> will reset the repo back to a specific commit. The commits are gone but the changes will be kept in the working directory.
If you want to undo both the commits AND the actual changes in your files, you can use the --hard option.
For example, git reset --hard HEAD~1 will delete the last commit and associated changes.

Git Revert

git revert is similar to git reset in that they both "undo" changes, but they accomplish it in different ways.
git reset actually moves the branch pointer backwards, eliminating commits.
git revert instead creates a brand new commit which reverses/undos the changes from a commit. Because it results in a new commit, you will be prompted to enter a commit message.
The history of the commit is preserved but the changes are reverted
```
git revert <commit-hash>
```

Which Command To Use?

Both git reset and git revert help us reverse changes, but there is a significant difference when it comes to collaboration.
If you want to reverse some commits that other people already have on their machines, you should use revert.
If you want to reverse commits that you haven't shared with others, use reset and no one will ever know!

Theory of Git Checkout

Usually, HEAD points to a specific branch reference rather than a particular commit. The HEAD is a pointer to the current branch reference and the branch reference is a pointer to the last commit made on a particular branch
When we make a new commit, the branch reference is updated to reflect the new commit. The HEAD remains the same, because it's pointing at the branch reference. When you switch branches, HEAD is updated to point to the specific branch reference. This is all to say that HEAD usually refers to a branch NOT a specific commit.
When we checkout a particular commit git checkout git checkout d8194d6, HEAD points at that commit rather than at the branch pointer

Detached Head

You have a couple of options:
1. Stay in detached HEAD to examine the contents of the old
commit. Poke around, view the files, etc.
2. Leave and go back to wherever you were before - reattach
the HEAD

   git switch master

Create a new branch after checking out the old commit and switch to it. You can now make and save changes since HEAD is no longer detached.
1. Suppose you want to go back to an old commit and make some new changes
2. Checkout the old commit. Now in detached HEAD state.
3. While in detached HEAD, Make a new branch and switch to it. Head is now back to pointing at a branch reference!
4. Now on the new branch, make as many new commits as you want! It's like you time traveled! We went back to an old commit and made a new branch based on it.

        git checkout <d8194d6>
        git switch -c newbranch
        git add .
        git commit -m "new commit"

Comparing Changes with Git Diff

Mustafa Hashmani — Wed, 16 Aug 2023 03:21:43 +0000

Git Diff

We can use the git diff command to view changes between commits, branches, files, our working directory, and more!
We often use git diff alongside commands like git status and git log, to get a better picture of a repository and how it has changed over time.
Without additional options, git diff lists all the changes in our working directory that are NOT staged for the next commit.
git diff --staged will list the changes between the staging area and our last commit. You can think of it as "Show me what will be included in my commit if I run git commit right now"
git diff HEAD lists all changes in the working tree since your last commit. It compares the HEAD and the working directory and shows both staged and unstaged changes.
git diff branch1..branch2 will list the changes between the tips of branch1 and branch2. The order matters as the first branch is referred to as File A and second as File B.
To compare two commits, provide git diff with the commit hashes of the commits in question in the form of git diff commit1..commit2
We can also view the changes within a specific file by providing git diff with a filename.
```
git diff HEAD [filename]
git diff --staged [filename]
```

Reading Git Diffs

For each comparison, Git explains which files it is comparing. Usually this is two versions of the same file.
Git also declares one file as "A"(old) and the other as "B"(new).

Markers
- File A and File B are each assigned a symbol.
  - Changes in File A are indicated with a minus sign (-)
  - Changes in File B are indicated with a plus sign (+)
Chunks
- A diff won't show the entire contents of a file, but instead only shows portions or "chunks" that were modified.
- A chunk also includes some unchanged lines before and after a change to provide some context
- Each chunk starts with a chunk header, found between @@ and @@.
- There are two sets of numbers in the chunk. One set belongs to File A and the other belongs to File B, that is what the sign indicates
- The number with the sign indicates from which line no, the lines are extracted from and the second number indicates how many lines have been extracted.
- From file a, 4 lines are extracted starting from line 3.
- From file b, 5 lines are extracted starting from line 3

Changes

Every line that changed between the two files is marked with either a + or - symbol and lines without any sign exist in both files
Simply the - can be interpreted as removed and + as added.
lines that begin with - come from file A
lines that begin with + come from file B

    diff --git a/rainbow.txt b/rainbow.txt
    index 72d1d5a..f2c8117 100644
    --- a/rainbow.txt
    +++ b/rainbow.txt
    @@ -3,4 +3,5 @@ orange
    yellow
    green
    blue
    -purple
    +indigo
    +violet

An Introduction to Stashing in Git

Mustafa Hashmani — Tue, 15 Aug 2023 07:16:01 +0000

Problem

Imagine a Scenario where you are on the master branch and you make a new branch and switch to it
You do some new work but don’t make any commits. What happens when you switch back to master?
1. My changes come with me to the destination branch
2. Git won't let me switch if it detects potential conflicts so it advises us to either commit or stash them

Stashing

Git provides an easy way of stashing these uncommitted changes so that we can return to them later, without having to make unnecessary commits.
git stash is super useful command that helps you save changes that you are not yet ready to commit. You can stash changes and then come back to them later. Now that you have stashed my changes, you can switch branches, create new commits, etc.
Running git stash will take all uncommitted changes (staged and unstaged) and stash them, reverting the changes in your working copy. We don’t see the changes but they are saved.
Use git stash pop to remove the most recently stashed changes in your stash and re-apply them to your working copy.
You can use git stash apply to apply whatever is stashed away, without removing it from the stash. This can be useful if you want to apply stashed changes to multiple branches

Stashing Multiple Times

You can add multiple stashes onto the stack of stashes. They will all be stashed in the order you added them.
Run git stash list to view all stashes
Git assumes you want to apply the most recent stash when you run git stash apply, but you can also specify a particular stash like git stash apply <stash-id>
To delete a particular stash, you can use git stash drop <stash-id>
To clear out all stashes, run git stash clear

A Guide to Working with Branches and Merging Branches

Mustafa Hashmani — Tue, 15 Aug 2023 07:11:10 +0000

Context

On large projects, we often work in multiple contexts:

You're working on 2 different color scheme variations for your website at the same time, unsure of which you like best
You're also trying to fix a horrible bug, but it's proving tough to solve. You need to really hunt around and toggle some code on and off to figure it out.
A teammate is also working on adding a new chat widget to present at the next meeting. It's unclear if your company will end up using it.
Another coworker is updating the search bar autocomplete.
Another developer is doing an experimental radical design overhaul of the entire layout to present next month.

If they all work in a linear fashion(one commit after the next) this would be impossible and break other people’s code

Branches

Branches are an essential part of Git!
Think of branches as alternative timelines for a project.
They enable us to create separate contexts where we can try new things, or even work on multiple ideas in parallel.
If we make changes on one branch(files,folders,code), they do not impact the other branches (unless we merge the changes)

The Master Branch

In git, we are always working on a branch. The default branch name is master when we are working on a new git repository.
It doesn't do anything special or have fancy powers. It's just like any other branch.
Many people designate the master branch as their "source of truth" or the "official branch" for their codebase, but that is left to you to decide.
From Git's perspective, the master branch is just like any other branch. It does not have to hold the "master copy" of your project.
In 2020, Github renamed the default branch from master to main. The default Git branch name is still master, though the Git team is exploring a potential change.

Head

We'll often come across the term HEAD in Git.
HEAD is simply a pointer that refers to the current "location" in your repository. It points to a particular branch reference.
So far, HEAD always points to the latest commit you made on the master branch, but soon we'll see that we can move around and HEAD will change!
The most recent commit on our master branch is always referred to as head → master which means that the HEAD is pointing to the master branch
Each branch has a branch pointer and the HEAD is a pointer to a branch pointer which points to where the branch currently is.

Viewing Branches

Use git branch to view your existing branches. The default branch in every git repo is master, though you can configure this.
You can also use -v option to view branches with last commits
Look for the * which indicates the branch you are currently on.
```
git branch
git branch -v
```

Creating and Switching Branches

Use git branch <branch-name> to make a new branch based upon the current HEAD so where you make the branch, matters
The branch name should not include spaces, separated by a colon and should be informative
This just creates the branch. It does not switch you to that branch (the HEAD stays the same)
You should always add and commit changes before switching branches
Once you have created a new branch, use git switch <branch-name> to switch to it. If you have unstaged changes, they may come with you or git may abort the change
Then HEAD will point to the and the master branch will be left behind
We can also use git switch with the -c flag to create a new branch AND switch to it all in one go. Remember -c as short for "create"
```
git branch <branch-name>
git switch <branch-name>
git switch -c <branch-name>
```
Historically, we used git checkout <branch-name> to switch branches. This still works.
The checkout command does a million additional things, so the decision was made to add a standalone switch command which is much simpler

Deleting and Renaming Branches

You can use the -d option with git branch to delete a branch. You cannot delete a branch you are currently on.
To forcefully delete a branch use the -D option
You can rename a branch using the -m option and you have to be on the branch that you want to rename.
```
git branch -d deleteMe
git branch -D deleteMe
git branch -m deleteIt
```

Merging Branches

Branching makes it super easy to work within self-contained contexts, but often we want to incorporate changes from one branch into another!
We treat the master branch as the most stable build of an application where you don’t want to screw anything up so people work on a feature branch and then that work is incorporated back into the master branch if it is useful
We can do this using the git merge command
We merge branches, not specific commits
We always merge to the current HEAD branch
Both branches will still remain separate after merging
To merge, follow these basic steps:
1. Switch to or checkout the branch you want to merge the changes into (the receiving branch)
2. Use the git merge command to merge changes from a specific branch into the current branch.
```
git switch master
git merge bugfix
```
  This Is Called A Fast-Forward. The Master branch simply caught up/fast-forwarded on the commits from Bugfix
Not All Merges Are Fast Forwards! What if we add a commit on master?

Rather than performing a simple fast forward, git performs a "merge commit" We end up with a new commit on the master branch. Git will prompt you for a message. The new commit will have two parents

Resolving Merge Conflicts

Depending on the specific changes you are trying to merge, Git may not be able to automatically merge.
This results in merge conflicts, which you need to manually resolve.
When you encounter a merge conflict, Git warns you in the console that it could not automatically merge.
The content from your current HEAD (the branch you are trying to merge content into) is displayed between the <<<<<<< HEAD and =======
The content from the branch you are trying to merge from is displayed between the ======= and >>>> symbols.
```
<<<<<<< HEAD
I have 2 cats
I also have chickens
=======
I used to have a dog :(
>>>>>>> bug-fix
```
Whenever you encounter merge conflicts, follow these steps to resolve them:
1. Open up the file(s) with merge conflicts
2. Edit the file(s) to remove the conflicts. Decide which branch's content you want to keep in each conflict. Or keep the content from both.
3. Remove the conflict "markers" in the document
4. Add your changes and then make a commit using the message “resolve conflicts”!
Or you can use VSCode to resolve the conflicts

Basics of Git: Adding and Committing

Mustafa Hashmani — Mon, 14 Aug 2023 20:18:18 +0000

Repository

A Git "Repo" is a workspace which tracks and manages files within a folder.
Anytime we want to use Git with a project, app, etc we need to create a new git repository.
We can have as many repos on our machine as needed, all with separate histories and contents
git status gives information on the current status of a git repository and its contents
Use git init to create a new git repository. Before we can do anything git-related, we must initialize a repo first!
Before running git init, use git status to verify that you are not currently inside of a repo.
This is something you do once per project. Initialize the repo in the top level folder containing your project

🚨 Do not INIT a repo inside of a repo

The Basic Git Workflow

Make new files, edit files, delete files, etc
1. Then run git status which will tell you the untracked and modified files
Group specific changes together, in preparation of committing(git add)
Commit everything that was previously added(git commit)

Adding

We use the git add command to stage changes to be committed.
It's a way of telling Git, "please include this change in our next commit"
Use git add to add specific files to the staging area. Separate files with spaces to add multiple at once.
Use git add . to stage all changes at once rather than typing the filenames
After adding git status , will show that the changes in the file are ready to be committed
```
git add file1 file2
git add .
```

Committing

Making a commit is similar to making a save in a video game. We're taking a snapshot of a git repository in time and marking a checkpoint.
When saving a file, we are saving the state of a single file. With Git, we can save the state of multiple files and folders together.
We have to make changes first and then save them to our files before we can commit. Once we have made changes and added them, we can group them together into a commit.
We use the git commit command to actually commit changes from the staging area.
When making a commit, we need to provide a commit message that summarizes the changes and work snapshotted in the commit
Running git commit will commit all staged changes. It also opens up a text editor and prompts you for a commit message. You can also use the -m flag which allows us to pass in an inline commit message, rather than launching a text editor.
git log --oneline gives a summary for the log of the commits for a given repository
You can also pass -a option to git commit which will add and commit altogether.
Use git config --global core.editor "code --wait” to configure VSCode to pass the commit messages when you are not using -m to pass longer messages
```
git commit -m "my message"
git commit -a -m "my message"
```
Atomic Commits
- When possible, a commit should encompass a single feature, change, or fix. In other words, try to keep each commit focused on a single thing.
- This makes it much easier to undo or rollback changes later on. It also makes your code or project easier to review.
Writing Commit Messages
- Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "I changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.
- Many developers prefer the past tense “added head”
Amending Commits
- Suppose you just made a commit and then realized you forgot to include a file! Or, maybe you made a typo in the commit message that you want to correct.
- Rather than making a brand new separate commit, you can "redo" the previous commit using the --amend option
```
git commit -m 'some commit'
git add forgotten_file
git commit --amend
```

Ignoring Files

We can tell Git which files and directories to ignore in a given repository, using a .gitignore file. This is useful for files you know you NEVER want to commit, including:
- Secrets, API keys, credentials, etc.
- Operating System files (.DS_Store on Mac)
- Log files
- Dependencies & packages
You will have the file locally but you don’t want git to track it
Create a file called .gitignore in the root of a repository using touch .gitignore. Inside the file, we can write patterns to tell Git which files & folders to ignore:
- .DS_Store will ignore files named .DS_Store
- folderName/ will ignore an entire directory
- *.log will ignore any files with the .log extension

A Guide to Permissions in Ubuntu

Mustafa Hashmani — Wed, 09 Aug 2023 14:49:18 +0000

As regular users, we do not have permission to write or even read every file on the machine.
For example, if I try to read the file /etc/sudoers using cat /etc/sudoers I get a "permission denied" message.
On unix systems, a single user may be the owner of files and directories, meaning that they have control over their access.
You can view permissions by running ls -l

File Attributes

The weird looking 10 characters we see printed out first are the file attributes.
```
-rw-rw-r--
```
These characters tell us the type of the file, the read, write, and execute permissions for the file's owner, the file's group owner, and everyone else.

The very first character indicates the type of the file. Some of the more common types and their corresponding attributes are:
- - regular file
- d directory
- c character special file
- l symbolic link

Character	Effect On Files	Effect on Directories
r	file can be read	directory's contents can be listed
w	file can be modified	directory's contents can be modified (create new files, rename files/folders) but only if the executable attribute is also set
x	file can be treated as a program to be executed	allows a directory to be entered or "cd"ed into
-	file cannot be read, modified, or executed	directory contents cannot be shown, modified, or cd'ed into

In the example below we see that the file's owner has read and write permissions but NOT execute permissions. No one else has any access
```
- rw- --- ---
```
In the example below, we see that the file's owner has read, write, AND execute permissions. No one else has any access
```
- rwx --- ---
```
In the example below, we see that the file's owner has read, and write BUT NOT execute permissions. Members of the file's owner group can only read the file and everyone else can read the file too.
```
- rw- r-- r--
```
In the above example, we see that the directory's owner and member's of the owner group can enter the directory, rename, and remove files from within the directory
```
d rwx rwx ---
```

Altering Permissions

`chmod`

To change the permissions of a file or directory, we can use the chmod command (change mode).
```
chmod mode file
```
To use chmod to alter permissions, we need to tell it:
- Who we are changing permissions for
- What change are we making? Adding? Removing?
- Which permissions are we setting?
When specifying permissions with chmod, we use a special syntax to write permission statements.
First, we specify the "who" using the following values:
- u - user (the owner of the file)
- g - group (members of the group the file belongs to)
- o - others (the "world")
- a - all of the above
Next, we tell chmod "what" we are doing using the following characters:
- - (minus sign) removes the permission
- + (plus sign) grants the permission
- = (equals sign) set a permission and removes others
Finally, the "which" values are:
- r - the read permission
- w - the write permission
- x - the execute permission
```
# Before : - rw- r-- r--
chmod g+w file.txt
# After : - rw- rw- r--

# Before : - rw- rw- r--
chmod a-w file.txt
# After : - r-- r-- r--

# Before : - rwx rwx r--
chmod a=r file.txt
# After : - r-- r-- r--
```
chmod Octals
- chmod also supports another way of representing permission patterns: octal numbers (base 8). Each digit in an octal number represents 3 binary digits.

chmod 755 file.txt # rwx r-x r-x

Root User

In Linux systems, there is a super user called root. The root user can run any command and access any file on the machine, regardless of the file's actual owner.
The root user has tons of power and could easily damage or even destroy the system by running the wrong commands!
For this reason, Ubuntu locks the root user by default.

`sudo`

Even if the root user is locked by default, we can still run specific commands as the root user by using the sudo command.
Individual users are granted an "allowed" list of commands they can run as the super user.
Run sudo -l to see the permitted commands for your particular user.
To run a command as the root user, prefix it with sudo. You will then need to enter the password for your account.
For example to update Ubuntu, I would need to run apt update. However, I can't do this as my "regular" user, as it's something that impacts all users. Instead, I need to run the command as the root user using sudo apt update
If you run into permissions denied, prefix the command with sudo

A Guide to Searching through the Command Line

Mustafa Hashmani — Wed, 09 Aug 2023 00:01:03 +0000

`locate`

The locate command performs a search of pathnames across our machine that match a given substring and then prints out any matching names.
You have to install this command as it does not comes pre-installed
It is nice and speedy because it uses a pre-generated database file rather than searching the entire machine.
For example, locate chick will perform a search for all files that contain chick in their name
It does not matter which directory you are in as you can locate folders which are in other directories
The -i option tells locate to ignore casing
The -l or --limit option will limit the number of entries to a number.

`find`

The locate command is nice and easy, but it can only do so much! The find command is far more powerful! Unlike locate, find does not use a database file.
By default, find on its own will list every single file and directory nested in our current working directory and also nested in the sub-directories.
We can also provide a specific folder. find friends/ would print all the files and directories inside the friends directory (including nested folders)
You can also find empty files by running find -empty

Finding by Type
- We can tell find to only find by file type: only print files, directories, symbolic links, etc using the -type option.
- find -type f will limit the search to files
- find -type d will limit the search to directories
Finding by Name
- We can provide a specific pattern for find to use when matching filenames and directories with the -name option. We need to enclose our pattern in quotes.
- To find all files on our Desktop that end in the .txt extension, we could run find ~/Desktop -name "*.txt"
- Use the -iname option for a case insensitive search
Finding by Size
- We can use the -size option to find files of a specific size. For example, to find all files larger than 1 gigabyte we could run find -size +1G
- To find all files under 50 megabytes, we could run find -size -50M
- To find all files that are exactly 20 kilobytes, we could run find -size 20k
Finding by Time
- mtime, or modification time, is when a file was last modified AKA when its contents last changed.
- ctime, or change time, is when a file was last changed. This occurs anytime mtime changes but also when we rename a file, move it, or alter permissions.
- atime, or access time, is updated when a file is read by an application or a command like cat.
- We can use the -mtime num option to match files/folders that were last modified num*24 hours ago.
- find -mmin -20 matches items that were modified LESS than 20 minutes ago.
- find -mmin +60 matches items that were modified more than 60 minutes ago
```
find -mmin -30
```
- find -amin n will find files that were last accessed n minutes ago. We can specify +n for "greater than n minutes ago" and -n for "less than n minutes ago"
- find -cmin -20 matches items that were changed LESS than 20 minutes ago.
- find -cmin +60 matches items that were changed more than 60 minutes ago
Logical Operators
- We can also use the -and, -or, and -not operators to create more complex queries.
```
find -type -f -not -name "*.html" # any file except .html
```

User-Defined Actions

We can provide find with our own action to perform using each matching pathname.
The syntax is find -exec command {} ;
The {} are a placeholder for the current pathname (each match), and the semicolon is required to indicate the end of the command.
To delete every file that starts with contains "broken" in its file name, we could run:
```
find -name "*broken*" -exec rm '{}' ';'
```
Note that we need to wrap the {} and ; in quotes because those characters have special meanings otherwise

`xargs`

When we provide a command via -exec, that command is executed separately for every single element.
We can instead use a special command called xargs to build up the input into a bundle that will be provided as an argument list to the next command.
```
find -name "*.txt" -exec ls '{}' ';'
find -name "*.txt" | xargs ls
```
This example finds four individual chapter files (chapter1, chapter2, chapter3, and chapter4) and then passes them to the cat command, which then outputs the combined contents to a file called fullbook.txt.
```
find -name "chapter[1-4].txt" | xargs cat > fullbook.txt
```
xargs reads items from standard input, separated by blanks (spaces or newlines) and then executes a command using those items
The mkdir command expects us to pass arguments. It doesn't work with standard input, so this example does NOT make any folders for us

We can instead add in the xargs command, which will accept the standard input coming from echo and pass them as arguments to mkdir.

echo "hello" "world" | mkdir # mkdir: missing operand
echo "hello" "world" | xargs mkdir
ls # hello world two folders made

Grep

The grep command searches for patterns in each file's contents. Grep will print each line that matches a pattern we provide.
For example, grep "chicken" animals.txt will print each line from the animals.txt file that contains the pattern "chicken"
```
grep PATTERN FILE
```
Use the -i option with grep to make the search case insensitive.
grep -i "Chapter" book.txt will print all matching lines from the book.txt file that contain the word "chapter" in any casing.
Use the -w option to ensure that grep only matches words, rather than fragments located inside of other words.
grep -w "cat" book.txt would match cat but not catheter!
Use the -r option to perform a recursive search which will include all files under a directory, subdirectories and their files, and so on.
grep -r "chicken" will search the current working directory and any nested directories for lines that contain "chicken"
The -c option tells grep to print the number of matches instead of printing the actual matches
The -o option tells grep to only print out the matches, rather than the entire line containing each match.
We can also provide regular expressions to grep by using the -E option

Redirecting and Piping Command through the Command Line

Mustafa Hashmani — Mon, 07 Aug 2023 18:43:04 +0000

Standard Streams

The three standard streams are communication channels between a computer program and its environment.
They are:
- Standard Input
- Standard Output
- Standard Error
Standard Output
- Standard output is a place to which a program or command can send information.
- The information could go to a screen to be displayed, to a file, or even to a printer or other devices.

Standard Error

Commands and programs also have a destination to send error messages: standard error.
By default, the shell directs standard error information to
the screen for us to read, but we can change that
destination if needed!

Standard Input
- Standard input is where a program or command gets its input information from. By default, the shell directs standard input from the keyboard.
- The input information could come from a keyboard, a file, or even from another command!

Redirection

"redirection" describes the ways we can alter the source of standard input, and the destinations for standard output and standard error.

Redirecting Output
- The redirect output symbol (>) tells the shell to redirect the output of a command to a specific file instead of the screen.
- By default, the date command will print the current date to the screen. If we instead run date > output.txt the output will be redirected to a file called output.txt
- If the file does not exist, it will be automatically created.
- Note: the > symbol needs to occur after any options and arguments!
```
command > filename
echo "moo" > cow.js # redirects the output of echo
ls -l > files.txt # saves the output of ls -l to a file.
```
Appending
- When we redirect output into a file using > any existing contents in the file are overwritten. Sometimes this is not what we want!
- Instead, keep the existing contents in the file and add new content to the end of the file, use >> when redirecting.
```
echo "hello" >> greeting.txt
echo "world" >> greeting.txt
cat greeting.txt
#hello
#world
```
Redirecting Input
- To pass the contents of a file to standard input, use the < symbol followed by the filename.
- For example, we could pass the contents of the chickens.txt file to the cat command using cat < chickens.txt
- cat (and many other commands) are set up to accept filenames as arguments directly, but we can also redirect to standard input manually.
```
command < filename
cat < chickens.txt
```
- We can redirect standard input and output at the same time! In this example, we are using cat to read in the contents of original.txt and then redirecting the output to a file called output.txt
- In this example, we are redirecting the names.txt file to the sort command. We are also redirecting the output of sort to a file called sorted.txt
```
cat < original.txt > output.txt
sort < names.txt > sorted.txt
```
Redirecting Standard Error
- By default, error messages are output to the screen, but we can change this by redirecting standard error.
- The standard error redirection operator is 2>
- If we ran a command like cat nonexistentfile (where the file does not exist) we would see an error printed to the screen. We can instead redirect standard error to a file with cat nonexistentfile 2> error.txt

We can use the same >> syntax to append when redirecting standard error.

cat nonexistentfile 2> error.txt
ls -zzz 2>> error.txt # ls with illegal option

Why 2> ?

Each stream gets its own numeric file descriptor, and for standard error the number is 2.
The > operator actually defaults to using 1 as the file descriptor number, which is why we didn't need to specify 1> to redirect standard output
Similarly, the < operator uses a default file descriptor number of 0, so we don't need to specify 0< to redirect to standard input (though we can!)

All Together now

We can redirect multiple streams at once! In this example, we are concatenating two files, redirecting standard output to a file called insects.txt, and redirecting standard error to a file called error.txt
When redirecting both standard output and standard error, make sure standard output comes FIRST. Always redirect standard error after standard output.
```
cat bees.txt ants.txt > insects.txt 2> error.txt
```

Pipes

Pipes are used to redirect a stream from one program to another program. We can take the output of one command and redirect it to the input of another.
We use the pipe character ( | ) to separate two commands. The output of the first command will be passed to the standard input of the second command.
This example shows the output of the date command being piped to the rev command. The result is the reverse of the current date!
```
command1 | command2
date | rev
```

This example pipes the output of ls to less. The /usr/bin directory typically contains a bunch of stuff, so it can be nice to use less to read the results in a more manageable way.
```
ls -l /usr/bin | less
```
This example counts the number of files (non hidden files) in a directory. We pipe the output of ls to the word count command. The -l option tells wc to count the number of lines.
```
ls | wc -l
```

In this example, we are calling tac with a file and then piping the output to rev. The final result is the content of file.txt printed "horizontally" and "vertically" reversed
```
tac file.txt | rev
```

This example concatenates two files using cat and then sorts them alphabetically
```
cat colors.txt pets.txt | sort
```

> vs |

Though both the > character and the | character are used to redirect output, they do it in very different ways.
> connects a command to some file.

| connects a command to another command.

ls -l /usr/bin > list.txt
ls -l /usr/bin | less

`tee`

What if I wanted to create a file with the output of cat? Enter the tee command
The tee program reads standard input and copies it both to standard output AND to a file. This allows us to capture information part of the way through a pipeline, without interrupting the flow.
It takes some informations coming from one command and gives it to a file we specify and also passes it to the next command. Hence this allows us to take information in the middle of a pipeline and save it to a file without stopping.
```
command1 | tee file.txt | command2
cat file1 file2 file3 | tee combo.txt | wc -w
```

Working with Files through the Command Line

Mustafa Hashmani — Mon, 07 Aug 2023 10:05:47 +0000

`cat`

The cat command con*cat*enates and prints the contents of files.
cat <filename> will read the contents of a file and print them out. For example, cat instructions.txt will read in from the instructions.txt file and then print the contents out to the screen.
If we provide cat with multiple files, it will concatenate their contents and output them.
cat peanutbutter.js jelly.css will output peanutbutter.js first and immediately after print the contents of jelly.css
```
cat <filename>
cat <file1> <file2>
```

`less`

The less command displays the contents of a file, one page at a time. We can navigate forwards and backwards through the file, which is especially useful with very large files.
less somefile.txt will display the contents of somefile.txt using less.
When viewing a file using less :
- press space to go to the next page of the file
- press b to go back to the previous page
- press Enter or Down arrow to scroll by one line
- to search, type forward slash / followed by a pattern
- press q to quit
```
less <filename>
```

`tac`

tac (cat spelled backwards) will concatenate and print files in reverse. It prints each line of a file, starting with the last line. You can think of it as printing in reverse "vertically"
```
tac file.txt
```

`rev`

The rev command prints the contents of a file, reversing the order of each line. Think of it as a "horizontal" reverse, whereas tac is a "vertical" reverse.
```
rev file.txt
```

`head`

The head command prints a portion of a file, starting from the beginning of the file. By default, it prints the first 10 lines of a file.
head warAndPeace.txt would print the first 10 lines of the warAndPeace.txt file
We can also specify a number of lines for head to print using the -n option (or --lines) followed by an integer.
head -n 21 warAndPeace.txt would print the first 21 lines of the warAndPeace.txt file
We can also use an even shorter syntax to specify a number of lines: head -3 filename.txt will print the first 3 lines of the file.
```
head filename.txt
head -n 13 filename.txt
```

`tail`

The tail command works similarly to the head command, except it prints from the END of a file. By default, it prints the last 10 lines of a file.
tail warAndPeace.txt would print the last 10 lines of the warAndPeace.txt file
The same -n option with head also works with the tail command.
```
tail filename.txt
```

`wc`

The word count command can tell us the number of words, lines, or bytes in files. By default, it prints out three numbers: the lines, words, and bytes in a file.
We can use the -l option to limit the output to the number of lines.
The -w option limits the output to the number of words in the file.
```
wc -l students.txt
```

`sort`

The sort command outputs the sorted contents of a file (it does not change the file itself). By default, it will sort the lines of a file alphabetically.
sort names.txt would print each line from names.txt, sorted in alphabetical order
The -r option tells the sort command to sort in reverse order.
sort names.txt -r would print each line from names.txt, sorted in REVERSE alphabetical order.
```
sort filename.txt
sort -r filename.txt
```
Sorting Numerically
- The -n option tells the sort command to sort using numerical order.
- sort -n prices.txt would print each line from names.txt, sorted in numerical order.
- We could also reverse it with sort -nr prices.txt
- The -u option tells the sort command to ignore duplicates and instead only sort unique values
```
sort -n prices.txt
sort -u prices.txt
```