Git and CLI

Author

Affiliations

Md Rasheduzzaman

FLI Insel Riems

& Freelancer

Last updated

September 9, 2025

Content summary

Git, GitHub and some basic shell commands

Lesson Summary

So, the summary goes first. Once you finish reading, fall back here to remind you the important things and steps of working with gitand GitHub and terminal. Regular practice will be easier in this way.

git and GitHub configuration is a bit tedious process (to make it secure for us though), but we are supposed to do it one time only. We don’t need to do it again and again.
Another important aspect is we are learning “how to follow instructions”.
Many personal things in programming are in generic terms. We have to replace them accordingly. For example, your_name@gmail.com, your_user_name, your_password, path/to/your/file,your meaningful message etc.
Learning to ask questions.
The standard workflow to work with a GitHub repository follows these few steps:

Go to your GitHub account → Find the + sign and click on it → Click on New Repository.
Clone it in your computer (inside your preferred folder) running git clone git@github.com:yourusername/test1.git. Don’t forget to replace git@github.com:yourusername/test1.git with the SSH link you copied for your repo.
Make changes in your folder by adding or creating files/folders. You can optionally check status of your folder running git status.
Stage/prepare/add them all to git running git add ..
Commit/decorate it with a meaningful message running git commit -m "your meaningful message".
Now push it to your remote (GitHub) repo running git push origin main.

We are recognizing code chunks in the document/page. Single line, multi-line code, and how to run them (run codes from the code chunks, even if I don’t explicitly say Run). Did you catch that running a code means writing (or copy-pasting) and pressing “Enter”/“Return” key on keyboard? Also, run multi-line code line by line, meaning next line after finishing the previous one running.
Getting used to different vocabulary related to Computer and programming.
We learned navigating the file system from the bash/terminal.

Prelude

Well, why gitand command line at the very beginning? I want you to be able to interact with me for all the lessons, take part in the GitHub discussion and make you competent with basic git tasks (pushand pull). You actually need 4-5 lines of code to push and pull. You will associate bash alternatives to Windows’ Graphical User Interphase (GUI, which is mouse clicking). Just get used to these stuffs. You will get the sense of accomplishment everyday. You know what, people get demotivated just because they don’t get the sense of accomplishment. Smaller task completion helps to pile up “done” things. I am here holding your hands. Don’t afraid to tinker and ponder around. You can always delete the problematic folder(s).

You can push the codes/scripts from the classes or your own practice codes. You will FEEL better and stronger after a bit of hustling!

GET ENGAGED!

Intro

GitHub is just like Google Drive, Dropbox or similar where you can upload (or push) files and folders of your project/package. What is special about the GitHub repositories then? Well, they are tracked for changes. How so? Well, git does that. git is the version control system (or tool) to track changes you make in a specific directory/repository (directory means folder as well). So you can have snapshot of your changes and fall back and forth if needed.

Imagine this situation: You made a working version of whatever you are doing/making. But then you were trying to polish it more. And alas, your so-called polishing is messing you up! You don’t know what is wrong! You closed the file many times and you can’t just undo and redo things. What would you do now except cursing (or other similar behavior of frustration)? Here comes git in your rescue. It kept the snapshot of your previous working version(s) in GitHub (if pushed) and you can easily fall back and forth (clone/download/pull it in your machine again). Maybe, the terms “upload” and “download” make a bit more sense, rather than push and pull/clone! But you got the (equivalent) idea, right?

Set git and GitHub

Install Git

For Windows

Download: Download Git from https://git-scm.com/download/win
Install: Now install, accept the default settings while installing
Open git bash: After installation, open Git Bash (not cmd/PowerShell). Find it and open by double clicking. Just keep it open, nothing else. We will return to this a bit later.

For MacOS

It should already be there. Open your terminal/shell now (Press "command" + "space" buttons together and write “terminal”. Choose the terminal). Then run:

git --version

If Git isn’t installed, macOS will prompt you to install the Xcode Command Line Tools. Click “Install” and you are done. But find the recommended below. Just run these two commands to keep your directory/repo clean.

echo .DS_Store >> ~/.gitignore_global
git config --global core.excludesfile ~/.gitignore_global

MacOS makes .DS_Store which is not really needed for any projects (this is just an internal thingy for MacOS). But to make it work, we should have chosen the option for a gitignore file while opening the GitHub repository. We will know more about it later. Don’t worry. We are adding it to gitignore and telling git to ignore it for file tracking.

For Ubuntu/Debian

Open your terminal (Press Ctrl + Alt + T.) and run these two commands one after another:

sudo apt update
sudo apt install git

Provide your password if prompted. You are all set!

Create a GitHub Account

Now go to https://github.com → Sign up with your email
Choose a username and password. Make the username easy to remember (for example, with your names, maybe), password should be as difficult as possible.

Hint, it can be different than your email password. Use combination of capital and small letters, numbers and special characters like “@”, “!”, “?”, etc.

Verify email (with the OTP) and you are set.

Set Up Git (for the first time only)

git config --global user.name "Your Name"
git config --global user.email "your_email@example.com"

Info!

It is a multi-line code chunk (2 lines). Run the first one first, then the second one.

Stop!

Here, Your Name and your_email@example.com means your user name (the one you set up just a bit ago. You don’t remember? Explore your GitHub account, you will see it there.) and the email address you used for GitHub. Use them correctly. Space, punctuation marks, capital or small letters should exactly match (Don’t be a “Murad Takla”).

You can check your config:

git config --global --list

Isn’t it showing things correctly? It should!

Generate SSH Key and Connect to GitHub

Recommended, need to do only once

Stop!

This step is creating a private and public key for you to identify that it is really you who is interacting (pushing, pulling, cloning for example) with the GitHub account later. We only upload the public key to GitHub, but never the private key. That is exclusively for yourself. Never share it with anybody.

ssh-keygen -t ed25519 -C "you@example.com"

Read and just press Enter for all the prompts

Stop!

Did you replace you@example.com with yours? If not, do it again replacing it with correct email address for your GitHub account.

Stop!

Did you press Enter or return key multiple times or just kept staring at the screen? Read the messages on your screen to understand, and keep pressing Enter.

Add SSH Key to GitHub

Now, we are going to add the public key to GitHub. But do we know it? Get it this way:

Run:

cat ~/.ssh/id_ed25519.pub

Copy the output: Be careful here. Just copy the output. No extra space after your email address (i.e. till .com).

Stop!

Did you copied it correctly? Check again, maybe.

How is your key?

It has 3 fields separated with 2 spaces. Did you notice that?

Go to GitHub → Settings → SSH and GPG keys → New SSH Key

Title: Whatever you want (but keep it simple, like my ssh key) Paste the key you copied and save it by clicking on Add SSH key. You are done.

Stop!

Did you copy-pasted it correctly and is the key visible if you check under SSH and GPG keys now? It shows only the second field of your key though. If not, it is not done correctly. Work around!

Test it:

ssh -T git@github.com

How is it?

Hi Your_user_name! You’ve successfully authenticated, but GitHub does not provide shell access.

It is totally fine, ignore the warning.

Setting and configuration is done. Voila!

Basic Git Workflow (Local + GitHub)

Create a New Repository on GitHub

Go to your GitHub account Find the + sign and click on it → Click on New Repository. Or there is another way. Find it.
Name it (e.g., test1).
Don’t initialize with README (we’ll do it ourselves). You can decide to add a .gitignore template from the drop-down as well. But don’t do it now.
Keep it public (as the default setting).
Save it by clicking on Create repository.

Clone It to Your Computer Now:

So, the repository (basically a folder in GitHub) is in GitHub server. It is not in your machine. Let’s copy it exactly how it is in our computer.

At first, go to correct location you want to be in. For example, let’s say, you want to be inside the Downloads folder. Run this:

cd Downloads

Information

It works because you are inside the home/root directory (denoted as ~) when you just open the terminal or git bash.

Well, If you want to be inside the Desktop or Documents folder, you could run cd Desktop or cd Documents instead of the one for Downloads. You got the idea for the navigation, right? Just use the correct folder name. Now, go to your GitHub repo. Click on <>Code and select SSH (or find the SSH link of your repo). Copy the link from there. Use/replace the link in the code below:

git clone git@github.com:yourusername/test1.git

Warning

Did you replace the git@github.com:yourusername/test1.git with your copied ssh link?

So, you are copying/cloning your empty repository you just have created to your laptop/machine. Good job! Ignore the warning from git. The warning is ok, right?

Add a new `README.md` file

Let’s add a new README.md file to our empty repo now. Poeple add basic information about the repo in this file. But it is something simple for us for now. Let’s proceed!

cd test1 
echo "# Hello GitHub" > README.md
ls

Information

So, it is a new file we created, right? It is on our computer, but not in our remote (GitHub) repository. So, let’s proceed to upload/push it to our GitHub repo named test1. It won’t go to other repo. Think about the logic. Why should it go to other repo/folder, right?

Diversion

echo "# Hello GitHub" actually prints # Hello GitHub on the terminal/git bash (you can check/run by copy-pasting only this part). The > operator is sending # Hello GitHub to the file named README.md. We did not need to create this file from before. See the power of echo, > together.

Track and Commit Changes

We said git is a tracking tool (version control system). So, let’s see how it tracked our test1 folder.

git status

Isn’t it showing that our README.md file is untracked (in red color)?

Note

It shows the status of the files and folders. You see the untracked files here. Untracked files mean the ones those are different than your GitHub repo. If you add something more in any of your file in this folder – even an extra space, it would be a change of the file and it would be stated as “untracked”.

git add README.md

It stages/prepares the untracked files to be added.

git commit -m "Add README"

You add a meaningful commit message for yourself to remind you what you did in this step (a decoration). Make it meaningful. But all these steps are still on your local machine. You have prepared (by using git add) and decorated (by using git commit -m) your file(s). You are just one step away to push it to your remote repo. Just run the command below, and feel like a soft-dev!

Push to GitHub

git push origin main

Go to your GitHub repo to see the changes. Refresh your browser, maybe.

Note

git status is not a compulsory thing to do/run, but the other 3 downstream commands are. In summary, you should always run these 3 commands to push something:

git add README.md    # Stage the specific file named README.md
git commit -m "Add README" #you added a meaningful message for yourself
git push origin main #push it now to main branch

What are the things with # sign?

Those are comments to tell you about the commands task (or anything). One just need to write a # sign to make it a comment in R.

Well, if you have added or created many files and folders inside this test1 folder (in whatever way), you should run:

git add .

The . means “everything” inside the current folder/directory. Well, you could run it all the time instead of mentioning specific file name (i.e. README.md) earlier.

Note

You can add and push as many files as you want. Just create/modify them inside the correct folder/directory and instead of git add README.md, use git add . when you think you’re done modifying. The dot here means all the files/folders. Then you could follow the next steps as usual. So, you could do:

git add .
git commit -m "a meaningful message for you"
git push origin main

Important

Did you replace "a meaningful message for you" to a real meaningful one for you?

Check your GitHub repo now! Refresh, maybe!

You are feeling like a PRO, no?

Let’s practice some more Linux navigation. See a toy folder structure below:

~/
├── Desktop/
│   ├── project_overview.pdf
│   └── meeting_notes.txt
├── Documents/
│   ├── resume.docx
│   ├── thesis/
│   │   ├── chapter1.md
│   │   └── references.bib
│   └── tax_2024.xlsx
└── Downloads/
    ├── folder1/
    │   ├── file1.txt
    │   ├── file2.txt
    │   └── notes.md
    ├── folder2/
    │   ├── data.csv
    │   ├── report.docx
    │   └── image.png
    └── folder3/
        ├── script.sh
        ├── config.json
        └── README.md

Important

If you had your git bash opened from before, close it and reopen it. Notice that there is no folder names after ~ sign in your git bash.

In real life, you have many more things like Pictures, Video, Music and others under ~, right? That’s why this one is a toy example.

So, Downloads is inside our ~ directory. We are inside our ~ directory when we open the git bash or terminal for the first time.

Important

HOMEor root directory is shown as ~ in your computer. Notice the things in different color in your terminal or git bash where you write commands.

Check your location (current working directory) by running:

pwd

pwd means “print working directory”. It means print one’s current location in the file system. Then we should try to see which files are inside this folder, right? Run:

ls

Note

ls means list everything at that location/folder. According to the picture, we can go to Downloads or Documents or Desktop folder from ~ (it is also called root. Isn’t the folder structure looks like a upside-down tree? That’s why it is the root).

Let’s say we are focusing on the Downloads folder now. Let’s go inside Downloads. Wait a moment. How would you do that in Windows? You would see Downloads now and would double click on it, right (open your file explorer from Windows to see things while reading and running commands to associate better)? But there is no double click in a git bash or terminal. cd does it for us. Do you see what is equivalent to that double click? Do you see what is equivalent to seeing the file in Windows and folder structure in the git bash or terminal? It’s not so difficult. Think……

Ok, follow me exactly now, run these commands:

cd Downloads
mkdir -p folder1 folder2 folder3
ls

I assume you have many files and folders inside Downloads. But you should see folder1, folder2, folder3 among others now. Don’t worry. Just run it. We are using -p flag/parameter with mkdir command. It says mkdir to make the directories, but if the folder(s) exist, it won’t make any changes there. So, your files and folders are safe.

Let’s navigate out of Downloads now and list everything inside Downloads in another way.

cd ..
ls Downloads

Did you notice that I used the folder name Downloads after ls command now? Well, where are we? Inside the root directory (~), right? Since we are at our root directory, if we run only ls, it will list everything inside the root (~) directory. Did we wanted that? So, we have to write the folder name/path and Downloads is just a step forward from ~. That’s why we used ls Downloads to list everything inside the Downloads folder. We could go inside Downloads folder first and then run ls only. We would achieve the same thing (try it if you want and come back to the root directory again).

Downloads is just one-step ahead from our root, do you catch this logic? If you wanted to list everything inside the folder3 folder, you could run ls Downloads/folder3 from the ~ directory. Do you see its logic? If not, think about this:

How far is your father’s generation from your grandfather’s?
How far behind is your grandfather’s generation compared to your father’s?
How far is your generation from your grandfather’s?
How far is your generation from your father’s?
How far behind is your father’s generation from yours?
How far behind is your grandfather’s generation from yours?
Isn’t the generation/level of your father, aunt(s) and uncle(s) the same? What about yours, your siblings or cousins?

Think of a family tree, computer filesystem is having exactly the same logic. Try to associate (Maybe draw the toy example from above horizontally, it will help to see things which belong to the same level).

In our toy example above, folder1, folder2, folder3 are on the same level/generation (they are children of Downloads, and Downloads is their parent). Similarly, Downloads, Documents and Desktop are on the same level (children of ~, so they are siblings). Makes sense?

Do you see how powerful this simple navigation logic is? You can list (using ls command) way too far (folder inside folder inside folder inside folder …….[or folder outside folder outside folder outside folder ……]) from where you are.

Optional: Maybe search for absolute path and relative path, and read a bit.

Let’s go inside Downloads now.

cd Downloads
ls

Note

ls is equivalent of seeing things inside a folder in Windows. Did you catch that?

ls shows folder1, folder2, folder3 among many other things, right?

Q. How to go inside, let’s say, folder2 now, and make a file named data.csv file? Well, since you are already inside Downloads, you need to go one step forward to go inside of it and create the (empty) file. Run one after another:

cd folder2
touch data.csv

Do you see what touch is doing?

Note

Well, touch is creating the file (named data.csv). Run ls to see who else is the resident there. As expected, no?

Q. How to come out of folder2 to Downloads again?

Note

Think backward now, see the picture for the folder structure to get visual help. You need to go one step behind, right? So? How to go backwards?

Run this:

cd ..

Could you relate what .. is meaning here?

Note

Well, one step/folder backward, right?

Note

Ahha…. Wondering why do we have / after the folder names? Well, that is the way to denote a folder. We could use ls Downloads/, but we dropped the / since we are not denoting any more folder after Downloads. If you want to see things inside folder3, we should have use ls Downloads/folder3 or ls Downloads/folder3/ from the ~ directory, we could not do it like ls Downloadsfolder3 or ls Downloadsfolder3/. Now it is looking for Downloadsfolder3 folder which is not there in your computer. You will get error stating cd: no such file or directory:.

Another point: Did you notice that ls Downloads/folder3 is just listing everything inside Downloads/folder3 on the fly, we are not really changing our physical location there, we are still in ~. To go inside folder3, we should use cd Downloads/folder3. Caught this correctly? Ponder….

Homeworks

Go inside folder1, folder2, folder3 folders one after another and create the empty files as you see in the picture (with exact names). If you can do it, you are almost a PRO in Linux/command line.
Now, remove all the folders running this command below:
```
rm -r folder1 folder2 folder3
```
Here, rm means “remove” and -r means “recursively”. So, delete the 3 mentioned directories recursively. It needs to recurse since the folders are not empty (have files, although empty for us. But they can have contents as well). Deleting/just running the command is your task. Did it work?
Make all the folders and files as it is shown in the toy file structure again. Don’t delete this time. Keep them.
Navigate to Downloads again. Stay there. Next task is coming.
Go to your GitHub account and make a repository named hw_repo1. Clone it inside your Downloads folder (navigate to this folder correctly after cloning). Add something (files, folder, whatever) in this folder (hw_repo1) and push following the standard workflow. Make as many changes and pushes you like.
Go to your GitHub account again and make a repository named hw_repo2. Clone it inside your Downloads folder (you know how to be inside Downloads, right?) again (go inside the hw_repo2 folder correctly after cloning, you know how). Add something (files, folder, whatever) in this folder (hw_repo2) again and push following the standard workflow. Make as many changes and pushes you like.
You learned these bash commands today:

pwd
ls
cat
echo
mkdir
cd
rm
touch
Can you relate them with Windows alternatives? I am giving a hint for touch. touch is the alternative of naming a new file while creating in Windows. Windows is doing it visually to help us (using different tools though, for example, Microsoft Words for .docx files. You can’t name a file like file_name.jpeg using Microsoft Words, though. Right? You need some other tools for that image file naming (.jpeg). But bash or terminal has no apparent limit). Think of the other commands now. Can you make a mind map of which command comes before or after which one if you are navigating your folders and creating some empty CSV files and inserting content in those files? For example, a shuffled list of the alphabets becomes A → B → C → D → E → ….. → Z if we organize them, right? Or a map of Father, Son, Grandson, Me, My_Siblings, Grandma will be Grandma → Father → Son → Me + My_Siblings → Grandson if we think of generations, right? Try to make one for those commands and add it in a file inside one of your hw_repo*. echo it in a file, make a .doc, .ppt, .png/jpeg/jpg or .txt file or whatever. I don’t mind, I just want to see that you got the idea. GitHub also doesn’t care what you are pushing to it (it is just a storage with special functionality to track files – well, some more though, we will know later). Let’s see. If you need help, don’t hesitate to reach out! There is no shame in asking for help while learning.

Optional: Navigate your other folders as well. Catch the logic of navigation. Also, can you make a list of words I used alternatively (back and forth) and maybe add them in one of your homework repo again? For example, folder, repo, and directory are basically the same thing; similarly, HOME, root and ~ are the same.
Share your repos with me (email me by Friday 10PM BD Time). I need time to check, right? Please, help me here….

Final Thought

You might not know how powerful you are getting! But trust me, you are too strong…….

Advance Tasks

What if your cloned repo is out of date (new changes happened)?

Run this to pull the up to date repo.

git pull origin main

(Use master if that’s your primary branch name.)

Git will then download any new commits and files from GitHub and integrate them into your local branch. If there are no new changes, it will simply tell you “Already up to date.”

Important: It’s a good habit to git pull before you start working on a project each day, or before you begin a new set of changes, to ensure you’re always working with the most current version. This helps avoid potential merge conflicts later on.

How to make changes directly on GitHub and then pull them

N.B. After this discussion, we’ll get into the exciting world of branches and collaboration!

Do these
1. Navigate to your repository on GitHub.com 2. Edit the file
3. Commit the changes
4. Pull the changes to your local machine

Open your terminal or Git Bash.
Navigate to your local repository folder using cd your-repo-name.

Run the git pull command:

git pull origin main

(Again, use master if that’s your primary branch name.)

Collaborating with Others: Branches and Pull Requests

Now for some really powerful stuff! So far, we’ve been working on a single line of development (the main or master branch). But what if you’re working with a team, or you want to experiment with new features without breaking the main, working version of your project? This is where branches come in.

1. Understanding Branches

Think of a branch as an independent line of development. When you create a branch, you’re essentially making a copy of your project at a specific point in time. You can then make changes on this new branch without affecting the original (main) branch.

main (or master) branch: This is typically considered the stable, production-ready version of your project.
Feature branches: You create these for new features, bug fixes, or experiments. You work on them in isolation. Once you’re done with your work on a feature branch and it’s stable, you can merge it back into the main branch.

Why use branches?

Isolation: Work on new features without impacting the stable code.
Collaboration: Multiple developers can work on different features simultaneously without stepping on each others toes.
Experimentation: Try out new ideas without fear of breaking the main project.

2. Creating and Switching Branches Locally

Let’s practice creating a new branch.

Scenario: You want to add a new “Contact Us” page to your well set website (code), but you don’t want to touch the live code until it’s ready.

Steps:

Ensure you’re on the main branch and up to date:

git checkout main
git pull origin main

git checkout main ensures you’re on the main branch. git pull ensures your main branch has all the latest changes from GitHub.

Create a new branch:

git branch feature/contact-page

It’s common to name branches descriptively, often starting with feature/, bugfix/, hotfix/, etc. Name them meaningfully as you need them for.

This command creates the branch but doesn’t switch you to it yet.

Switch to your new branch:

git checkout feature/contact-page

You’ll see a message like “Switched to branch ‘feature/contact-page’”.

Pro Tip: You can combine steps 2 and 3 into one command:

git checkout -b feature/contact-page

Verify your current branch:

git branch

The branch you’re currently on will have an asterisk (*) next to its name.

Now you are on your feature/contact-page branch. Any changes you make, commit, and push will be on this branch, completely separate from main.

git status
git add .
git commit -m "created contatc.txt file in the feature branch"
git push origin feature/contact-page

Once you’ve finished your work on a branch and thoroughly tested it, the next step is to merge it back into the main branch.

3. Merging a Branch (Bringing Your Changes Back)

Merging is the process of integrating the changes from one branch (like your feature/contact-page branch) into another branch (typically main).

Scenario: You’ve added your “Contact Us” page, it’s working perfectly, and you’re ready to make it part of the main website (main branch).

Steps:
1. Ensure you’re on the main branch and up to date:

git checkout main
git pull origin main

This is crucial! You want to merge your changes into the latest version of main.

Merge your feature branch into main:

git merge feature/contact-page

This command tells Git to take all the changes from the feature/contact-page branch and apply them to the main branch.

Automatic Merging: If Git can figure out how to combine the changes without any conflicts, it will do so automatically. You might see a message like “Successfully merged.”

Merge Conflicts: Sometimes, if both branches have changed the same lines in the same file, Git won’t know how to proceed. This results in a merge conflict. We’ll cover how to resolve these in a moment.

(If the merge was successful) Push the merged main branch to GitHub:

git push origin main

This uploads the merged changes to the remote main branch on GitHub.

4. Deleting the Feature Branch (Optional but Recommended)

Delete the branch locally: First, ensure you’re not on the branch you want to delete. Switch back to main:

git checkout main

Then, delete the local branch:

git branch -d feature/contact-page

The -d flag is for “delete.” Git will prevent deletion if the branch has unmerged changes.
If you really want to delete a branch with unmerged changes, for whatever reason, (use with caution!), you can use the force delete flag: git branch -D feature/contact-page (capital D).

Dealing with Merge Conflicts Merge conflicts happen when Git can’t automatically reconcile changes between branches. It’s not a disaster! It just means you need to manually tell Git how to combine the changes.

Scenario: You and a collaborator both edited the same section of a file on different branches.

What you’ll see:

Git will add special markers to the conflicting file, showing the changes from both branches. It will look something like this:

<<<<<<< HEAD
// Your changes on the main branch
=======
// Your collaborator's changes on the feature branch
>>>>>>> feature/contact-page

<<<<<<< HEAD: Marks the beginning of the changes on your current branch (main).
=======: Separates your changes from the changes on the other branch.
>>>>>>> feature/contact-page: Marks the end of the changes on the feature/contact-page branch.

How to resolve a conflict:

Open the conflicting file in a text editor: You’ll see the conflict markers.
Manually edit the file: Decide how you want to combine the changes. You might:

Keep only your changes.
Keep only the other branch’s changes.
Combine parts of both.
Rewrite the section entirely.
Remove the conflict markers: Delete the <<<<<<< HEAD, =======, and >>>>>>> feature/contact-page lines.

Save the file.
Stage the resolved file:

git add your-conflicting-file.txt

Commit the merge:

git commit -m "Resolve merge conflict in your-conflicting-file.txt"

Push the merged branch:

git push origin main

Now the conflict is resolved, and your changes are safely merged!

5. Pull Requests (PRs): The Heart of Collaboration

While you can merge branches locally, in a collaborative environment, the most common way to integrate changes is through a Pull Request (PR) on GitHub. A Pull Request is essentially a formal proposal to merge your changes from a feature branch into another branch (usually main).

Why use Pull Requests?

Code Review: It allows other team members to review your code, provide feedback, and suggest improvements before the changes are merged into the main codebase. This catches bugs and ensures code quality.
Discussion: PRs provide a dedicated space for discussion about the changes.
Automated Checks: GitHub can be configured to run automated tests or checks on PRs, ensuring the new code doesn’t break existing functionality.
Record Keeping: PRs create a clear history of how and why changes were integrated.

Scenario: You’ve completed your tasks for feature/contact-page and pushed it to GitHub. Now you want your team to review it and eventually merge it into main.

Steps to create a Pull Request:
1. At first, pull the repo to your local machine and make changes:

git clone git@github.com:yourusername/repoLink.git
git checkout main
git checkout -b feature/contact-page
#you can name your branch with something else depending on your task 
#Now make changes (files) or do whatever you want to do with coding
#Then push the changes
git status
git add .
git commit -m "My contribution"
git push origin feature/contact-page

Before you can create a PR, your branch needs to exist on GitHub. If you just created it locally and committed changes, you’ll need to push it up.

The first time you push a new branch, Git might give you a hint like: git push --set-upstream origin feature/contact-page Just copy and paste that command if you see it.
2. Go to your repository on GitHub.com: Once your branch is pushed, GitHub will often display a banner at the top of your repository page, suggesting you “Compare & pull request” for your newly pushed branch. If not, click on the “Pull requests” tab.
3. Click “New pull request”: If the banner isn’t there, click the green “New pull request” button.
4.Select your branches:

Base branch: This is the branch you want to merge into (e.g., main).
Compare branch: This is your feature branch that contains the changes (e.g., feature/contact-page).

GitHub will show you a comparison of the changes between the two branches. Review them to ensure they’re what you expect.
5. Create the Pull Request:

Provide a clear and concise title for your PR (e.g., “Add Contact Us Page”).
Write a detailed description explaining what changes you made, why you made them, any potential issues, or how to test them. This is crucial for reviewers!
You can also:
- Assign reviewers: Choose team members who need to review your code.
- Link issues: Connect your PR to any relevant GitHub issues.
- Add labels: Categorize your PR (e.g., feature, bug).

Click the green “Create pull request” button.

Reviewing and Merging a Pull Request

Once a Pull Request is created, the collaborative process begins!

As a Reviewer:

Review Changes: Look at the “Files changed” tab to see the code modifications.
Leave Comments: You can click on specific lines of code to add comments, ask questions, or suggest alternative solutions.
Approve/Request Changes: Once you’ve reviewed, you can either “Approve” the PR, “Request changes” (if modifications are needed), or simply “Comment” without a formal decision.

As the Author (or team lead):

Address Feedback: Respond to comments and make any necessary changes to your code. If you make new commits on your feature branch locally and git push origin feature/contact-page, those new commits will automatically appear in your open Pull Request on GitHub.
Merge the Pull Request: Once all feedback is addressed, required checks pass, and the PR is approved, anyone with merge permissions can click the “Merge pull request” button on GitHub.
- GitHub offers different merge strategies:
  - Merge commit: Creates a new commit that records the merge.
  - Squash and merge: Combines all your feature branch commits into a single new commit on main. Great for keeping main’s history clean.
  - Rebase and merge: Reapplies your feature branch commits on top of main, creating a linear history.

Deleting the Feature Branch (Optional but Recommended)

After your feature branch has been successfully merged into main and pushed to GitHub, you typically don’t need the feature branch anymore. Deleting it keeps your repository tidy.

Delete the branch on GitHub: After merging a PR, GitHub usually gives you an option to “Delete branch.” Click that.
Delete the branch locally: First, ensure you’re not on the branch you want to delete. Switch back to main:

git checkout main

Then, delete the local branch:

git branch -d feature/contact-page

We are all set to be a full stack developer!

Citation

BibTeX citation:

@online{rasheduzzaman2025,
  author = {Md Rasheduzzaman},
  title = {Git and {CLI}},
  date = {2025-09-09},
  langid = {en},
  abstract = {Git, GitHub and some basic shell commands}
}

For attribution, please cite this work as:

Md Rasheduzzaman. 2025. “Git and CLI.” September 9, 2025.

--- title: "Git and CLI" abstract: "Git, GitHub and some basic shell commands" format: html execute: echo: true eval: false # disables code execution globally --- ```{r} #| include: false source(here::here("src/helpersrc.R")) ``` # Lesson Summary **So, the summary goes first.** Once you finish reading, fall back here to remind you the important things and steps of working with `git`and `GitHub` and terminal. Regular practice will be easier in this way. - `git` and `GitHub` configuration is a bit tedious process (to make it secure for us though), but we are supposed to do it one time only. We don't need to do it again and again. - Another important aspect is we are learning "how to follow instructions". - Many personal things in programming are in generic terms. We have to replace them accordingly. For example, `your_name@gmail.com`, `your_user_name`, `your_password`, `path/to/your/file`,`your meaningful message` etc. - Learning to ask questions. - The standard workflow to work with a GitHub repository follows these few steps: 1. Go to your GitHub account → Find the `+` sign and click on it → Click on `New Repository`. 2. Clone it in your computer (inside your preferred folder) running `git clone git@github.com:yourusername/test1.git`. Don't forget to replace `git@github.com:yourusername/test1.git` with the SSH link you copied for your repo. 3. Make changes in your folder by adding or creating files/folders. You can optionally check status of your folder running `git status`. 4. Stage/prepare/add them all to git running `git add .`.\ 5. Commit/decorate it with a meaningful message running `git commit -m "your meaningful message"`. 6. Now push it to your remote (GitHub) repo running `git push origin main`. - We are recognizing code chunks in the document/page. Single line, multi-line code, and how to run them (run codes from the code chunks, even if I don't explicitly say **Run**). Did you catch that running a code means writing (or copy-pasting) and pressing "Enter"/"Return" key on keyboard? Also, run multi-line code line by line, meaning next line after finishing the previous one running. - Getting used to different vocabulary related to Computer and programming. - We learned navigating the file system from the bash/terminal. # Prelude Well, why `git`and `command line` at the very beginning? I want you to be able to interact with me for all the lessons, take part in the GitHub discussion and make you competent with basic git tasks (`push`and `pull`). You actually need 4-5 lines of code to push and pull. You will associate bash alternatives to Windows' Graphical User Interphase (GUI, which is mouse clicking). Just get used to these stuffs. You will get the sense of accomplishment everyday. You know what, people get demotivated just because they don't get the sense of accomplishment. Smaller task completion helps to pile up "done" things. I am here holding your hands. Don't afraid to tinker and ponder around. You can always delete the problematic folder(s). You can push the codes/scripts from the classes or your own practice codes. You will FEEL better and stronger after a bit of hustling! ***`GET ENGAGED!`*** # Intro GitHub is just like Google Drive, Dropbox or similar where you can `upload` (or `push`) files and folders of your project/package. What is special about the GitHub repositories then? Well, they are tracked for changes. How so? Well, `git` does that. `git` is the version control system (or tool) to track changes you make in a specific directory/repository (directory means folder as well). So you can have snapshot of your changes and fall back and forth if needed. **Imagine this situation:** You made a working version of whatever you are doing/making. But then you were trying to polish it more. And alas, your so-called polishing is messing you up! You don't know what is wrong! You closed the file many times and you can't just `undo` and `redo` things. What would you do now except cursing (or other similar behavior of frustration)? Here comes `git` in your rescue. It kept the snapshot of your previous working version(s) in GitHub (if pushed) and you can easily fall back and forth (`clone`/`download`/`pull` it in your machine again). Maybe, the terms "upload" and "download" make a bit more sense, rather than `push` and `pull`/`clone`! But you got the (equivalent) idea, right? # Set git and GitHub ## Install Git ### For Windows - **Download:** Download `Git` from <https://git-scm.com/download/win> - **Install:** Now install, accept the default settings while installing - **Open git bash:** After installation, open `Git Bash` (not cmd/PowerShell). Find it and open by double clicking. Just keep it open, nothing else. We will return to this a bit later. ### For MacOS It should already be there. Open your terminal/shell now (Press `"command"` + `"space"` buttons together and write "terminal". Choose the terminal). Then run: ```{bash, eval=FALSE} git --version ``` If Git isn’t installed, macOS will prompt you to install the Xcode Command Line Tools. Click "Install" and you are done. But find the recommended below. Just run these two commands to keep your directory/repo clean. ```{bash, eval=FALSE} echo .DS_Store >> ~/.gitignore_global git config --global core.excludesfile ~/.gitignore_global ``` MacOS makes `.DS_Store` which is not really needed for any projects (this is just an internal thingy for MacOS). But to make it work, we should have chosen the option for a gitignore file while opening the GitHub repository. We will know more about it later. Don't worry. We are adding it to gitignore and telling git to ignore it for file tracking. ### For Ubuntu/Debian Open your terminal (Press `Ctrl + Alt + T`.) and run these two commands one after another: ```{bash, eval=FALSE} sudo apt update sudo apt install git ``` Provide your password if prompted. You are all set! ## Create a GitHub Account - Now go to <https://github.com> → Sign up with your email - Choose a username and password. Make the username easy to remember (for example, with your names, maybe), password should be as difficult as possible. Hint, it can be different than your email password. Use combination of capital and small letters, numbers and special characters like "@", "!", "?", etc. - Verify email (with the OTP) and you are set. ## Set Up Git (for the first time only) ```{bash, eval=FALSE} git config --global user.name "Your Name" git config --global user.email "your_email@example.com" ``` ::: callout-note ## Info! It is a multi-line code chunk (2 lines). Run the first one first, then the second one. ::: ::: callout-warning ## Stop! Here, `Your Name` and `your_email@example.com` means your user name (the one you set up just a bit ago. You don't remember? Explore your GitHub account, you will see it there.) and the email address you used for GitHub. Use them correctly. Space, punctuation marks, capital or small letters should exactly match (Don't be a "Murad Takla"). ::: You can check your config: ```{bash, eval=FALSE} git config --global --list ``` Isn't it showing things correctly? It should! ## Generate SSH Key and Connect to GitHub **Recommended, need to do only once** ::: callout-warning ## Stop! This step is creating a private and public key for you to identify that it is really you who is interacting (pushing, pulling, cloning for example) with the GitHub account later. We only upload the public key to GitHub, but never the private key. That is exclusively for yourself. Never share it with anybody. ::: ```{bash, eval=FALSE} ssh-keygen -t ed25519 -C "you@example.com" ``` **Read and just press Enter for all the prompts** ::: callout-warning ## Stop! Did you replace `you@example.com` with yours? If not, do it again replacing it with correct email address for your GitHub account. ::: ::: callout-warning ## Stop! Did you press Enter or return key multiple times or just kept staring at the screen? Read the messages on your screen to understand, and keep pressing Enter. ::: ## Add SSH Key to GitHub Now, we are going to add the public key to GitHub. But do we know it? Get it this way: 1. Run: ```{bash, eval=FALSE} cat ~/.ssh/id_ed25519.pub ``` 2. Copy the output: Be careful here. Just copy the output. No extra space after your email address (i.e. till `.com`). ::: callout-warning ## Stop! Did you copied it correctly? Check again, maybe. ::: ::: {.callout-note collapse="true"} ## How is your key? It has 3 fields separated with 2 spaces. Did you notice that? ::: 3. Go to GitHub → Settings → SSH and GPG keys → New SSH Key **Title:** Whatever you want (but keep it simple, like `my ssh key`) **Paste the key** you copied and save it by clicking on `Add SSH key`. You are done. ::: callout-warning ## Stop! Did you copy-pasted it correctly and is the key visible if you check under `SSH and GPG keys` now? It shows only the second field of your key though. If not, it is not done correctly. Work around! ::: 4. Test it: ```{bash, eval=FALSE} ssh -T git@github.com ``` ::: callout-note ## How is it? Hi `Your_user_name`! You've successfully authenticated, but GitHub does not provide shell access. ::: It is totally fine, ignore the warning. Setting and configuration is done. Voila! # Basic Git Workflow (Local + GitHub) ### Create a New Repository on GitHub 1. Go to your GitHub account Find the `+` sign and click on it → Click on `New Repository`. Or there is another way. Find it. 2. Name it (e.g., test1). 3. Don’t initialize with README (we’ll do it ourselves). You can decide to add a `.gitignore` template from the drop-down as well. But don't do it now. 4. Keep it public (as the default setting). 5. Save it by clicking on `Create repository`. ### Clone It to Your Computer Now: So, the repository (basically a folder in GitHub) is in GitHub server. It is not in your machine. Let's copy it exactly how it is in our computer. - At first, go to correct location you want to be in. For example, let's say, you want to be inside the `Downloads` folder. Run this: ```{bash, eval=FALSE} cd Downloads ``` ::: callout-note ## Information It works because you are inside the home/root directory (denoted as `~`) when you just open the terminal or git bash. ::: Well, If you want to be inside the `Desktop` or `Documents` folder, you could run `cd Desktop` or `cd Documents` instead of the one for `Downloads`. You got the idea for the navigation, right? Just use the correct folder name. Now, go to your GitHub repo. Click on `<>Code` and select `SSH` (or find the SSH link of your repo). Copy the link from there. Use/replace the link in the code below: ```{bash, eval=FALSE} git clone git@github.com:yourusername/test1.git ``` ::: callout-warning ## Warning Did you replace the `git@github.com:yourusername/test1.git` with your copied ssh link? ::: So, you are copying/cloning your empty repository you just have created to your laptop/machine. Good job! Ignore the warning from `git`. The warning is ok, right? ### Add a new `README.md` file Let's add a new README.md file to our empty repo now. Poeple add basic information about the repo in this file. But it is something simple for us for now. Let's proceed! ```{bash, eval=FALSE} cd test1 echo "# Hello GitHub" > README.md ls ``` ::: callout-note ## Information So, it is a new file we created, right? It is on our computer, but not in our remote (GitHub) repository. So, let's proceed to upload/`push` it to our GitHub repo named `test1`. It won't go to other repo. Think about the logic. Why should it go to other repo/folder, right? ::: ::: callout-note ## Diversion `echo "# Hello GitHub"` actually prints `# Hello GitHub` on the terminal/git bash (you can check/run by copy-pasting only this part). The `>` operator is sending `# Hello GitHub` to the file named `README.md`. We did not need to create this file from before. See the power of `echo`, `>` together. ::: ### Track and Commit Changes We said `git` is a tracking tool (version control system). So, let's see how it tracked our `test1` folder. ```{bash, eval=FALSE} git status ``` Isn't it showing that our `README.md` file is untracked (in red color)? ::: {.callout-note collapse="true"} It shows the status of the files and folders. You see the untracked files here. Untracked files mean the ones those are different than your GitHub repo. If you add something more in any of your file in this folder -- even an extra space, it would be a change of the file and it would be stated as "untracked". ::: ```{bash, eval=FALSE} git add README.md ``` It stages/prepares the untracked files to be added. ```{bash, eval=FALSE} git commit -m "Add README" ``` You add a meaningful commit message for yourself to remind you what you did in this step (a decoration). Make it meaningful. But all these steps are still on your local machine. You have prepared (by using `git add`) and decorated (by using `git commit -m`) your file(s). You are just one step away to `push` it to your remote repo. Just run the command below, and feel like a soft-dev! ### Push to GitHub ```{bash, eval=FALSE} git push origin main ``` Go to your GitHub repo to see the changes. Refresh your browser, maybe. ::: callout-note `git status` is not a compulsory thing to do/run, but the other 3 downstream commands are. In summary, you should always run these 3 commands to push something: ::: ```{bash, eval=FALSE} git add README.md # Stage the specific file named README.md git commit -m "Add README" #you added a meaningful message for yourself git push origin main #push it now to main branch ``` ::: callout-note ## What are the things with `#` sign? Those are comments to tell you about the commands task (or anything). One just need to write a `#` sign to make it a comment in R. ::: Well, if you have added or created many files and folders inside this `test1` folder (in whatever way), you should run: ```{bash, eval=FALSE} git add . ``` The `.` means **"everything"** inside the current folder/directory. Well, you could run it all the time instead of mentioning specific file name (i.e. `README.md`) earlier. ::: callout-note ## Note You can add and push as many files as you want. Just create/modify them inside the correct folder/directory and instead of `git add README.md`, use `git add .` when you think you're done modifying. The dot here means all the files/folders. Then you could follow the next steps as usual. So, you could do: ::: ```{bash, eval=FALSE} git add . git commit -m "a meaningful message for you" git push origin main ``` ::: callout-important Did you replace `"a meaningful message for you"` to a real meaningful one for you? ::: Check your GitHub repo now! Refresh, maybe! *You are feeling like a PRO, no?* Let's practice some more Linux navigation. See a toy folder structure below: ``` text ~/ ├── Desktop/ │ ├── project_overview.pdf │ └── meeting_notes.txt ├── Documents/ │ ├── resume.docx │ ├── thesis/ │ │ ├── chapter1.md │ │ └── references.bib │ └── tax_2024.xlsx └── Downloads/ ├── folder1/ │ ├── file1.txt │ ├── file2.txt │ └── notes.md ├── folder2/ │ ├── data.csv │ ├── report.docx │ └── image.png └── folder3/ ├── script.sh ├── config.json └── README.md ``` ::: callout-important If you had your git bash opened from before, close it and reopen it. Notice that there is no folder names after `~` sign in your git bash. ::: In real life, you have many more things like `Pictures`, `Video`, `Music` and others under `~`, right? That's why this one is a toy example. So, `Downloads` is inside our `~` directory. We are inside our `~` directory when we open the git bash or terminal for the first time. ::: callout-important `HOME`or `root` directory is shown as `~` in your computer. Notice the things in different color in your terminal or git bash where you write commands. ::: Check your location (current working directory) by running: ```{bash, eval=FALSE} pwd ``` `pwd` means "print working directory". It means print one's current location in the file system. Then we should try to see which files are inside this folder, right? Run: ```{bash, eval=FALSE} ls ``` ::: callout-note `ls` means list everything at that location/folder. According to the picture, we can go to `Downloads` or `Documents` or `Desktop` folder from `~` (it is also called `root`. Isn't the folder structure looks like a upside-down tree? That's why it is the `root`). Let's say we are focusing on the `Downloads` folder now. Let's go inside `Downloads`. Wait a moment. How would you do that in Windows? You would see `Downloads` now and would double click on it, right (open your file explorer from Windows to see things while reading and running commands to associate better)? But there is no double click in a git bash or terminal. `cd` does it for us. Do you see what is equivalent to that double click? Do you see what is equivalent to seeing the file in Windows and folder structure in the git bash or terminal? It's not so difficult. Think...... Ok, follow me exactly now, run these commands: ::: ```{bash, eval=FALSE} cd Downloads mkdir -p folder1 folder2 folder3 ls ``` I assume you have many files and folders inside `Downloads`. But you should see `folder1`, `folder2`, `folder3` among others now. Don't worry. Just run it. We are using `-p` flag/parameter with `mkdir` command. It says `mkdir` to make the directories, but if the folder(s) exist, it won't make any changes there. So, your files and folders are safe. Let's navigate out of `Downloads` now and list everything inside `Downloads` in another way. ```{bash, eval=FALSE} cd .. ls Downloads ``` Did you notice that I used the folder name `Downloads` after `ls` command now? Well, where are we? Inside the root directory (`~`), right? Since we are at our root directory, if we run only `ls`, it will list everything inside the root (`~`) directory. Did we wanted that? So, we have to write the folder name/path and `Downloads` is just a step forward from `~`. That's why we used `ls Downloads` to list everything inside the `Downloads` folder. We could go inside `Downloads` folder first and then run `ls` only. We would achieve the same thing (try it if you want and come back to the `root` directory again). `Downloads` is just one-step ahead from our root, do you catch this logic? If you wanted to list everything inside the `folder3` folder, you could run `ls Downloads/folder3` from the `~` directory. Do you see its logic? If not, think about this: - How far is your father's generation from your grandfather's? - How far behind is your grandfather's generation compared to your father's? - How far is your generation from your grandfather's? - How far is your generation from your father's? - How far behind is your father's generation from yours? - How far behind is your grandfather's generation from yours? - Isn't the generation/level of your father, aunt(s) and uncle(s) the same? What about yours, your siblings or cousins? Think of a family tree, computer filesystem is having exactly the same logic. Try to associate (Maybe draw the toy example from above horizontally, it will help to see things which belong to the same level). In our toy example above, `folder1`, `folder2`, `folder3` are on the same level/generation (they are children of `Downloads`, and `Downloads` is their parent). Similarly, `Downloads`, `Documents` and `Desktop` are on the same level (children of `~`, so they are siblings). Makes sense? Do you see how powerful this simple navigation logic is? You can list (using `ls` command) way too far (folder inside folder inside folder inside folder .......\[or folder outside folder outside folder outside folder ......\]) from where you are. **Optional:** Maybe search for `absolute path` and `relative path`, and read a bit. Let's go inside `Downloads` now. ```{bash, eval=FALSE} cd Downloads ls ``` ::: {.callout-note collapse="true"} `ls` is equivalent of seeing things inside a folder in Windows. Did you catch that? ::: `ls` shows `folder1`, `folder2`, `folder3` among many other things, right? **Q.** How to go inside, let's say, `folder2` now, and make a file named `data.csv` file? Well, since you are already inside `Downloads`, you need to go one step forward to go inside of it and create the (empty) file. Run one after another: ```{bash, eval=FALSE} cd folder2 touch data.csv ``` **Do you see what `touch` is doing?** ::: {.callout-note collapse="true"} Well, `touch` is creating the file (named `data.csv`). Run `ls` to see who else is the resident there. As expected, no? ::: *Q.* How to come out of `folder2` to `Downloads` again? ::: {.callout-note collapse="true"} Think backward now, see the picture for the folder structure to get visual help. You need to go one step behind, right? So? How to go backwards? ::: Run this: ```{bash, eval=FALSE} cd .. ``` **Could you relate what `..` is meaning here?** ::: {.callout-note collapse="true"} Well, one step/folder backward, right? ::: ::: callout-note Ahha.... Wondering why do we have `/` after the folder names? Well, that is the way to denote a folder. We could use `ls Downloads/`, but we dropped the `/` since we are not denoting any more folder after `Downloads`. If you want to see things inside `folder3`, we should have use `ls Downloads/folder3` or `ls Downloads/folder3/` from the `~` directory, we could not do it like `ls Downloadsfolder3` or `ls Downloadsfolder3/`. Now it is looking for `Downloadsfolder3` folder which is not there in your computer. You will get error stating `cd: no such file or directory:`. **Another point:** Did you notice that `ls Downloads/folder3` is just listing everything inside `Downloads/folder3` on the fly, we are not really changing our physical location there, we are still in `~`. To go inside `folder3`, we should use `cd Downloads/folder3`. Caught this correctly? Ponder.... ::: # Homeworks 1. Go inside `folder1`, `folder2`, `folder3` folders one after another and create the empty files as you see in the picture (with exact names). If you can do it, you are almost a PRO in Linux/command line. 2. Now, remove all the folders running this command below: ```{bash, eval=FALSE} rm -r folder1 folder2 folder3 ``` Here, `rm` means "remove" and `-r` means "recursively". So, delete the 3 mentioned directories recursively. It needs to recurse since the folders are not empty (have files, although empty for us. But they can have contents as well). Deleting/just running the command is your task. Did it work? 3. Make all the folders and files as it is shown in the toy file structure again. Don't delete this time. Keep them. 4. Navigate to `Downloads` again. Stay there. Next task is coming. 5. Go to your GitHub account and make a repository named `hw_repo1`. **Clone** it inside your `Downloads` folder (navigate to this folder correctly after cloning). Add something (files, folder, whatever) in this folder (`hw_repo1`) and push following the standard workflow. Make as many changes and pushes you like. 6. Go to your GitHub account again and make a repository named `hw_repo2`. **Clone** it inside your `Downloads` folder (you know how to be inside `Downloads`, right?) again (go inside the `hw_repo2` folder correctly after cloning, you know how). Add something (files, folder, whatever) in this folder (`hw_repo2`) again and push following the standard workflow. Make as many changes and pushes you like. 7. You learned these bash commands today: - `pwd` - `ls` - `cat` - `echo` - `mkdir` - `cd` - `rm` - `touch`\ Can you relate them with Windows alternatives? I am giving a hint for `touch`. `touch` is the alternative of naming a new file while creating in Windows. Windows is doing it visually to help us (using different tools though, for example, Microsoft Words for `.docx` files. You can't name a file like `file_name.jpeg` using Microsoft Words, though. Right? You need some other tools for that image file naming (`.jpeg`). But bash or terminal has no apparent limit). Think of the other commands now. Can you make a mind map of which command comes before or after which one if you are navigating your folders and creating some empty CSV files and inserting content in those files? For example, **a shuffled list of the alphabets** becomes **A → B → C → D → E → ..... → Z** if we organize them, right? Or a map of **Father, Son, Grandson, Me, My_Siblings, Grandma** will be **Grandma → Father → Son → Me + My_Siblings → Grandson** if we think of generations, right? Try to make one for those commands and add it in a file inside one of your `hw_repo*`. `echo` it in a file, make a .doc, .ppt, .png/jpeg/jpg or .txt file or whatever. I don't mind, I just want to see that you got the idea. GitHub also doesn't care what you are pushing to it (it is just a storage with special functionality to track files -- well, some more though, we will know later). Let's see. If you need help, don't hesitate to reach out! There is no shame in asking for help while learning. 8. Optional: Navigate your other folders as well. Catch the logic of navigation. Also, can you make a list of words I used alternatively (back and forth) and maybe add them in one of your homework repo again? For example, folder, repo, and directory are basically the same thing; similarly, `HOME`, `root` and `~` are the same. 9. Share your repos with me (**email me by Friday 10PM BD Time**). I need time to check, right? Please, help me here.... # Final Thought You might not know how powerful you are getting! But trust me, you are too strong....... # Advance Tasks ## What if your cloned repo is out of date (new changes happened)? Run this to pull the up to date repo. ```{bash, eval=FALSE} git pull origin main ``` (Use `master` if that's your primary branch name.) Git will then download any new commits and files from GitHub and integrate them into your local branch. If there are no new changes, it will simply tell you "Already up to date." **Important:** It's a good habit to `git pull` before you start working on a project each day, or before you begin a new set of changes, to ensure you're always working with the most current version. This helps avoid potential merge conflicts later on. ## How to make changes directly on GitHub and then pull them **N.B. After this discussion, we'll get into the exciting world of branches and collaboration!** **Do these** 1. Navigate to your repository on `GitHub.com` 2. Edit the file 3. Commit the changes 4. Pull the changes to your local machine - Open your terminal or Git Bash. - Navigate to your local repository folder using `cd your-repo-name`. Run the git pull command: ```{bash, eval=FALSE} git pull origin main ``` (Again, use `master` if that's your primary branch name.) ## Collaborating with Others: Branches and Pull Requests Now for some really powerful stuff! So far, we've been working on a single line of development (the `main` or `master` branch). But what if you're working with a team, or you want to experiment with new features without breaking the main, working version of your project? This is where branches come in. ### 1. Understanding Branches Think of a branch as an independent line of development. When you create a branch, you're essentially making a copy of your project at a specific point in time. You can then make changes on this new branch without affecting the original (`main`) branch. - `main` (or `master`) branch: This is typically considered the stable, production-ready version of your project. - Feature branches: You create these for new features, bug fixes, or experiments. You work on them in isolation. Once you're done with your work on a feature branch and it's stable, you can merge it back into the `main` branch. **Why use branches?** - Isolation: Work on new features without impacting the stable code. - Collaboration: Multiple developers can work on different features simultaneously without stepping on each others toes. - Experimentation: Try out new ideas without fear of breaking the main project. ### 2. Creating and Switching Branches Locally Let's practice creating a new branch. **Scenario:** You want to add a new "Contact Us" page to your well set website (code), but you don't want to touch the live code until it's ready. Steps: 1. Ensure you're on the main branch and up to date: ```{bash, eval=FALSE} git checkout main git pull origin main ``` `git checkout main` ensures you're on the `main` branch. `git pull` ensures your `main` branch has all the latest changes from GitHub. 2. Create a new branch: ```{bash, eval=FALSE} git branch feature/contact-page ``` It's common to name branches descriptively, often starting with `feature/`, `bugfix/`, `hotfix/`, etc. Name them meaningfully as you need them for. This command creates the branch but doesn't switch you to it yet. 3. Switch to your new branch: ```{bash, eval=FALSE} git checkout feature/contact-page ``` You'll see a message like "Switched to branch 'feature/contact-page'". **Pro Tip:** You can combine steps 2 and 3 into one command: ```{bash, eval=FALSE} git checkout -b feature/contact-page ``` 4. Verify your current branch: ```{bash, eval=FALSE} git branch ``` The branch you're currently on will have an asterisk (*) next to its name. Now you are on your `feature/contact-page` branch. Any changes you make, commit, and push will be on this branch, completely separate from `main`. ```{bash, eval=FALSE} git status git add . git commit -m "created contatc.txt file in the feature branch" git push origin feature/contact-page ``` Once you've finished your work on a branch and thoroughly tested it, the next step is to merge it back into the `main` branch. ### 3. Merging a Branch (Bringing Your Changes Back) Merging is the process of integrating the changes from one branch (like your `feature/contact-page` branch) into another branch (typically `main`). **Scenario:** You've added your "Contact Us" page, it's working perfectly, and you're ready to make it part of the main website (main branch). Steps: 1. Ensure you're on the `main` branch and up to date: ```{bash, eval=FALSE} git checkout main git pull origin main ``` This is crucial! You want to merge your changes into the latest version of `main`. 2. Merge your feature branch into `main`: ```{bash, eval=FALSE} git merge feature/contact-page ``` This command tells Git to take all the changes from the `feature/contact-page` branch and apply them to the `main` branch. **Automatic Merging:** If Git can figure out how to combine the changes without any conflicts, it will do so automatically. You might see a message like "Successfully merged." **Merge Conflicts:** Sometimes, if both branches have changed the same lines in the same file, Git won't know how to proceed. This results in a merge conflict. We'll cover how to resolve these in a moment. 3. (If the merge was successful) Push the merged `main` branch to GitHub: ```{bash, eval=FALSE} git push origin main ``` This uploads the merged changes to the remote `main` branch on GitHub. ### 4. Deleting the Feature Branch (Optional but Recommended) Delete the branch locally: First, ensure you're **not** on the branch you want to delete. Switch back to `main`: ```{bash, eval=FALSE} git checkout main ``` Then, delete the local branch: ```{bash, eval=FALSE} git branch -d feature/contact-page ``` - The `-d` flag is for "delete." Git will prevent deletion if the branch has unmerged changes. - If you really want to delete a branch with unmerged changes, for whatever reason, (use with caution!), you can use the force delete flag: `git branch -D feature/contact-page` (capital D). Dealing with Merge Conflicts Merge conflicts happen when Git can't automatically reconcile changes between branches. It's not a disaster! It just means you need to manually tell Git how to combine the changes. **Scenario:** You and a collaborator both edited the same section of a file on different branches. What you'll see: - Git will add special markers to the conflicting file, showing the changes from both branches. It will look something like this: ```{bash, eval=FALSE} <<<<<<< HEAD // Your changes on the main branch ======= // Your collaborator's changes on the feature branch >>>>>>> feature/contact-page ``` - `<<<<<<< HEAD`: Marks the beginning of the changes on your current branch (main). - `=======`: Separates your changes from the changes on the other branch. - `>>>>>>> feature/contact-page`: Marks the end of the changes on the `feature/contact-page` branch. **How to resolve a conflict:** 1. Open the conflicting file in a text editor: You'll see the conflict markers. 2. Manually edit the file: Decide how you want to combine the changes. You might: - Keep only your changes. - Keep only the other branch's changes. - Combine parts of both. - Rewrite the section entirely. - Remove the conflict markers: Delete the `<<<<<<< HEAD`, `=======`, and `>>>>>>> feature/contact-page` lines. 3. Save the file. 4. Stage the resolved file: ```{bash, eval=FALSE} git add your-conflicting-file.txt ``` 5. Commit the merge: ```{bash, eval=FALSE} git commit -m "Resolve merge conflict in your-conflicting-file.txt" ``` 6. Push the merged branch: ```{bash, eval=FALSE} git push origin main ``` Now the conflict is resolved, and your changes are safely merged! ### 5. Pull Requests (PRs): The Heart of Collaboration While you can merge branches locally, in a collaborative environment, the most common way to integrate changes is through a Pull Request (PR) on GitHub. A Pull Request is essentially a formal proposal to merge your changes from a feature branch into another branch (usually `main`). **Why use Pull Requests?** - Code Review: It allows other team members to review your code, provide feedback, and suggest improvements before the changes are merged into the main codebase. This catches bugs and ensures code quality. - Discussion: PRs provide a dedicated space for discussion about the changes. - Automated Checks: GitHub can be configured to run automated tests or checks on PRs, ensuring the new code doesn't break existing functionality. - Record Keeping: PRs create a clear history of how and why changes were integrated. **Scenario:** You've completed your tasks for `feature/contact-page` and pushed it to GitHub. Now you want your team to review it and eventually merge it into main. Steps to create a Pull Request: 1. At first, pull the repo to your local machine and make changes: ```{bash, eval=FALSE} git clone git@github.com:yourusername/repoLink.git git checkout main git checkout -b feature/contact-page #you can name your branch with something else depending on your task #Now make changes (files) or do whatever you want to do with coding #Then push the changes git status git add . git commit -m "My contribution" git push origin feature/contact-page ``` Before you can create a PR, your branch needs to exist on GitHub. If you just created it locally and committed changes, you'll need to push it up. The first time you push a new branch, Git might give you a hint like: `git push --set-upstream origin feature/contact-page` Just copy and paste that command if you see it. 2. Go to your repository on `GitHub.com`: Once your branch is pushed, GitHub will often display a banner at the top of your repository page, suggesting you **"Compare & pull request"** for your newly pushed branch. If not, click on the **"Pull requests"** tab. 3. Click **"New pull request"**: If the banner isn't there, click the green **"New pull request"** button. 4.Select your branches: - Base branch: This is the branch you want to merge into (e.g., main). - Compare branch: This is your feature branch that contains the changes (e.g., `feature/contact-page`). GitHub will show you a comparison of the changes between the two branches. Review them to ensure they're what you expect. 5. Create the Pull Request: - Provide a clear and concise title for your PR (e.g., "Add Contact Us Page"). - Write a detailed description explaining what changes you made, why you made them, any potential issues, or how to test them. This is crucial for reviewers! - You can also: - Assign reviewers: Choose team members who need to review your code. - Link issues: Connect your PR to any relevant GitHub issues. - Add labels: Categorize your PR (e.g., feature, bug). Click the green **"Create pull request"** button. 6. Reviewing and Merging a Pull Request Once a Pull Request is created, the collaborative process begins! **As a Reviewer:** - Review Changes: Look at the "Files changed" tab to see the code modifications. - Leave Comments: You can click on specific lines of code to add comments, ask questions, or suggest alternative solutions. - Approve/Request Changes: Once you've reviewed, you can either **"Approve"** the PR, **"Request changes"** (if modifications are needed), or simply **"Comment"** without a formal decision. **As the Author (or team lead):** - Address Feedback: Respond to comments and make any necessary changes to your code. If you make new commits on your feature branch locally and `git push origin feature/contact-page`, those new commits will automatically appear in your open Pull Request on GitHub. - Merge the Pull Request: Once all feedback is addressed, required checks pass, and the PR is approved, anyone with merge permissions can click the **"Merge pull request"** button on GitHub. - GitHub offers different merge strategies: - **Merge commit:** Creates a new commit that records the merge. - **Squash and merge:** Combines all your feature branch commits into a single new commit on `main`. Great for keeping main's history clean. - **Rebase and merge:** Reapplies your feature branch commits on top of main, creating a linear history. 7. Deleting the Feature Branch (Optional but Recommended) After your feature branch has been successfully merged into `main` and pushed to GitHub, you typically don't need the feature branch anymore. Deleting it keeps your repository tidy. 1. Delete the branch on GitHub: After merging a PR, GitHub usually gives you an option to "Delete branch." Click that. 2. Delete the branch locally: First, ensure you're not on the branch you want to delete. Switch back to `main`: ```{bash, eval=FALSE} git checkout main ``` Then, delete the local branch: ```{bash, eval=FALSE} git branch -d feature/contact-page ``` We are all set to be a full stack developer!

Lesson Summary

Prelude

Intro

Set git and GitHub

Install Git

For Windows

For MacOS

For Ubuntu/Debian

Create a GitHub Account

Set Up Git (for the first time only)

Generate SSH Key and Connect to GitHub

Add SSH Key to GitHub

Basic Git Workflow (Local + GitHub)

Create a New Repository on GitHub

Clone It to Your Computer Now:

Add a new README.md file

Track and Commit Changes

Push to GitHub

Homeworks

Final Thought

Advance Tasks

What if your cloned repo is out of date (new changes happened)?

How to make changes directly on GitHub and then pull them

Collaborating with Others: Branches and Pull Requests

1. Understanding Branches

2. Creating and Switching Branches Locally

3. Merging a Branch (Bringing Your Changes Back)

4. Deleting the Feature Branch (Optional but Recommended)

5. Pull Requests (PRs): The Heart of Collaboration

Citation

Add a new `README.md` file