Week 3: Git and AWS Lab Guide

• Set up your AWS Academy account by responding to your email invitation and clicking Get Started. The email invitation will come from AWS Academy <notifications@instructure.com>. If you do not see the email, check your junk, spam, or promotional mail folder. Here is a sample invitation email:

• Go to https://www.awsacademy.com/LMS_Login to login.

  • Press Student Login.

  • Use the email address that received the email invitation for the email field.

• In the AWS Academy Dashboard, click on the Learner Lab you wish to use. Students invited to more than one course/learner lab will see multiple tiles on the dashboard.

• Select Modules.

• Select the Learner Lab item.

• The instructions for using the lab environment are to the right of the console window. You can return to the instructions by pressing the Readme button. The instructions include important details about how to access and use your AWS account, the AWS Services available to you, and the restrictions placed on some AWS Services.

• Start the lab by selecting Start Lab.

• When the dot next to AWS turns yellow , your lab environment is still being prepared to use. So wait for it!

• When the dot next to AWS turns green , your lab environment is ready to use . Click AWS to launch the AWS Console in a new tab.

• A new tab will open the AWS Management Console when you click on AWS. The system logged you into a temporary AWS account and the lab session will automatically end when the session timer expires. The system will save your work when you end the session or the session timer expires.

  • Note: The system will suspend your EC2 instances at the end of a session and they will restart when you start the lab again. Press Start if you need to start up a new lab session.

• Alternatively, you can use the terminal window to the left of the instructions to use the AWS Command-Line Interface (CLI) to interact with your account.

• Return to the AWS Academy LMS tab to view the lab instructions or to control your lab session.

• To monitor spending, see the area at the top of the lab instructions. Note: This information is provided by the AWS Budgets service and might be delayed by up to 8 hours. This is an approximate view of spending.

  • Note: If you spend the entire budget, you will lose all of your work, and the system will deactivate your temporary AWS account. Your $50 budget is sufficient for most academic projects, as long as you take care to stay within the budget guidelines.

• You can monitor your remaining session time at the top of the lab. Note: If you are actively working and you need more time, you can reset your session timer by pressing Start Lab again.

• To delete all resources that you have configured in a lab and start with a fresh AWS account, choose Reset . Important: All work will be lost and cannot be recovered.

  • This option will not reset your budget. Any spending that you have incurred will continue to be tracked.

• When you are finished with the session, choose End Lab .

  • Any running Amazon Elastic Compute Cloud (Amazon EC2) instances will be stopped. If you return and restart the lab, any stopped EC2 instances will restart and any other resources that you configured will still be available.

  • Important : If you created and started other AWS resources such as a NAT gateway or Amazon Relational Database Service (Amazon RDS) database, those resources will continue to run in the background and incur charges, even outside of your lab session time.

[Important Note] Due to an AWS Learner Lab policy, our AWS lab environment is restricted to only us-east-1 and us-west-2 regions. Therefore, please make sure to select either one of these regions when you start your lab exercises.

• First, let's open the AWS console:

• Here are the settings of our new EC2 Linux instance:

• Choosing the default AMI of AWS (Amazon Linux 2023) is the best to run on EC2 instances. Indeed, this AMI of AWS is based on a version of RHEL (Red Hat Enterprise Linux) - Fedora . Amazon has customised it to suit AWS environments, optimising it for cloud use with packages, settings, and configurations tailored to improve performance, security, and compatibility with AWS services

• Since the purpose of our project is learning, so let's stick with the small and sufficient instance type (hardware):

  • The t3.micro is a low-cost Amazon EC2 instance with 2 vCPU and 1 GB RAM, ideal for lightweight workloads. It offers burstable performance using a CPU credit system, making it suitable for small web servers, testing, and development.

• Create a new key pair to securely SSH to your EC2 instance:

• Now the browser should download a devops_project_key.pem to your computer. Please keep this file safe (as we will try to use only one key for all of our EC2 instances in this course):

• Now, our EC2 instance will use that new SSH key “devops_project_key" as a way for us to pass authentication and login to the EC2 instance using the key.

• We need to create a security group (firewall rules) to secure and protect our VMs:

• The default 8 GB for storage is plenty enough for our EC2 server:

  • gp3 is a type of Amazon EBS (Elastic Block Store) SSD storage used with EC2 instances. It offers faster performance and lower cost than the older gp2. With gp3, you get 3,000 IOPS by default, and you can increase speed without changing the storage size. It’s great for things like boot volumes, apps, and small databases.

• After that, review the configuration settings and launch the instance:

• AWS will announce that it has started to create a new EC2 instance based on your configuration:

• In the EC2 dashboard you should see the git-devops EC2 running:

• You can check out all related information about your EC2 instance here. The most important information is the Public IP address of your EC2 instance which will allow us to connect SSH to the server to control it:

• Now we will use the SSH key to SSH to the EC2 instance, there are different instructions for different operating systems of your laptop (Windows 10, 11, MacOS or Linux):

  • [For Windows 10 or 11 users], you can try to SSH using Powershell or Command Prompt (cmd). These instructions are for Windows 10 or 11 users only:

    • Open PowerShell as Administrator

• You can check whether OpenSSH Client is already installed:

ssh -V

• If SSH is not yet installed, then install it if need:

  • Windows 10: Settings → Apps → Optional Features

    • Windows 11: Settings → System → Optional features

      • Search for OpenSSH Client

      • Select it and click Install

• Reopen PowerShell to check if SSH is already installed:

• Next, please change the current directory into where you store that ssh pem file key. (you can use “cd”). Try to copy the example SSH command from AWS EC2:

  • ssh -i path_to_ssh_key username@ip-or-domain-name-of-host

    • Here is example:

ssh -i "devops_project_key.pem" ec2-user@ec2-18-212-255-237.compute-1.amazonaws.com

• SSH is working now, you've just hit the "permissions too open" error, which is the expected next step. The key file needs its permissions locked down so only your user can read it.

• Run these two commands in PowerShell as the Administrator :

  • /reset clears the custom entries back to inherited defaults.

    • /inheritance:r then removes all inherited permissions (this is what strips out Authenticated Users, Users, Administrators, and SYSTEM).

      • /grant:r adds back read access for just your account.

icacls "devops_key.pem" /reset
icacls "devops_key.pem" /inheritance:r
icacls "devops_key.pem" /grant:r "$($env:USERNAME):(R)"

• To verify only your user is listed afterward:

  • That's exactly what you want below, only your_username:(R) and nothing else. The key is now properly locked down.

icacls "devops_key.pem"

• Try to SSH to EC2 again:

• [For older Windows users (Windows 8, 7 or XP)], you can try to SSH using Putty or Mobaxterm. These instructions are for older Windows users only:

  • You will use PuTTY to SSH to Amazon EC2 instances. If you do not have PuTTY installed on your computer, download it here.

    • Open putty.exe

    • Configure PuTTY to not timeout:

      • Choose Connection

      • Set Seconds between keepalives to 30

    • This allows you to keep the PuTTY session open for a longer period of time.

    • Configure your PuTTY session:

      • Choose Session

      • Host Name (or IP address): Copy and paste the IPv4 Public IP address for the instance.

    • Back in PuTTy, in the Connection list, expand SSH

      • Choose Auth (don't expand it)

      • Choose Browse

      • Browse to and select the .pem file that you downloaded

      • Choose Open to select it

      • Choose Open

    • Choose Yes, to trust the host and connect to it.

    • When prompted login as, enter: ec2-user

    • This will connect you to the EC2 instance.

  • [For MacOS and Linux (like Ubuntu) users], we just need to use Terminals:

    • Open a terminal window, and change directory cd to the directory where the .pem file was downloaded. For example, run this command, if it was saved to your Downloads directory:

cd ~/Downloads

• Change the permissions on the key to be read only, by running this command:

chmod 400 devops_project_key.pem

• To keep it easy, we gonna ask AWS to show us the command to SSH to the instance, and copy that command:

• Run that command in the terminal:

ssh -i "devops_project_key.pem" ec2-user@ec2-18-212-255-237.compute-1.amazonaws.com

• Note: make sure you copy that command from AWS since the Public DNS will be different for each EC2 instances.

  • The first time you connect to your EC2 instance, you need to type “yes” to add that new SSH connection to known hosts:

• After that, you should SSH successfully to the remote EC2 Server like below:

• Now you can treat this as the usual Fedora VM or CentOS VM, we have been dealing with so far in week 1 and 2. However, the difference is that this VM is actually a cloud server running on a remote Amazon data centre.

• You can play around with CLI commands you learn so far, for example:

Suggestion : you should move your SSH key to a more secure folder like ~/.ssh/keys so you remember where your SSH key is for the next time you want to SSH to the EC2 instance!

Playground

This exercise will help you learn the basics and some advanced features of Git and GitHub. You'll use the interactive platform LearnGitBranching for hands-on practice.

1. Getting Started:

   • Go to LearnGitBranching and click "Start Learning" or "Sandbox".

   • Choose your language if asked.

2. Complete Main Module Exercises:

   • Start with the Introduction Sequence in the Main module to learn fundamental Git commands.

   • Continue with the Ramping Up section to explore more about branches and how to reorganize them with rebase.

3. Move to Remote Module Exercises:

   • After finishing the Main module, go to the Remote module.

   • Complete the exercises in Push & Pull -- Git Remotes! to learn how to connect and work with remote repositories.

4. Tips for Using LearnGitBranching:

   • Follow the instructions for each exercise.

   • Use the visuals to see how your actions affect the Git tree.

   • If stuck, use the "Hint" button for tips.

5. Learning Goals:

   • Get comfortable with basic Git operations.

   • Understand how to manage branches and handle merges.

   • Learn how to push to and pull from remote repositories effectively.

Ideally, try your best to finish these recommended exercises:

Finish all the exercises to improve your understanding of Git and GitHub. Feel free to share your experiences or questions with others. This knowledge is essential for working on software development projects.

• Go to https://github.com/

• In the upper-right corner of any page, use the drop-down menu, and select New.

• Type a short, memorable name for your repository. For example, "my_new_project".

• Optionally, add a description of your repository. For example, "Learning DevOps at RMIT"

• Choose public visibility (Anyone can see, and checkout your github repository).

• Untick to initialise this repository without a README file to keep things simple when we push it! However, later on, it is important to add a README file which is important if you want other people to understand what and how to use your project.

• For a licence: Since we are learning so we can skip this and choose None! However, later on if you are doing a serious project then it’s better to add a licence so other people on the internet will know how much you are willing for them to reuse parts of your code! The default good one is “MIT License” which is meant to be extremely straightforward and open. It permits users to do anything with a given project as long as they credit the developer and don't hold him or her liable for the project's use.

• Click Create repository.

• Note: You can find the HTTPs URL of your Github repo here:

• Here are two ways for you to get started with a Github repo:

  • Option 1 (Recommended in this lab): Push an existing repository from the command line

git remote add origin https://github.com/your_github_name/your_git_repo_name.git
git push -u origin main

• Option 2 (Recommended in other cases): Create a new repository on the command line

git clone https://github.com/your_github_name/your_git_repo_name.git

Choose option 2 if you want to create a fresh new local repo (offline) which connects to your remote repo (online). This is an easier option if you want to start fresh!

In our case, you've already created a local repo on your AWS EC2 instance so you can choose option 1 to connect your remote repository (online) to your local repository (offline)!

• Let’s switch back to the main branch:

git checkout main

• origin is a local name used to refer to the remote repository. It could be called anything, but origin is a convention that is often used by default in git and GitHub, so it’s helpful to stick with this unless there’s a reason not to.

git remote add origin https://github.com/your_github_name/your_git_repo_name.git

• We can check if our command has worked by list all remotes:

git remote -v

• Now we will push the changes from our local repository to the repository on GitHub:

git push -u origin main

• Unfortunately, Github is no longer to support authenticate with username and password:

• We need to generate personal access token of Github to authenticate ourselves to push all existing commits on the local repository to the remote repository on Github:

• Select these permissions of the access code to be able to have full control of your private repositories, full controls of your team projects and also able to delete repositories:

  • repo = Full control of private repositories

  • admin:org = Full control of orgs and teams, read and write org projects

  • delete_repo = Delete repositories

• Remember to copy this personal access token somewhere safe!

• Now you can use this personal access token to authenticate to push to your remote repository on Github:

This Github authentication using an access token is easy to setup but it is a bit painful to re-enter the 🙁 access token every time you want to push to remote repository on Github !

• Now, you should see all the commits we have done so far in the Challenge 0 has been pushed to the remote repository on Github:

• You can see that the list of our commits in the local repository has been pushed to the remote repository on Github:

Question: Did you notice your new_feature branch is missing on the Github remote repository? Can you figure out how to push the new_feature branch from the local repository also to the remote repository?

Hint : just switch to that brand and try to git push and see what happens then follow the instructions of Git.

After you follow the step 2, your local git should be connected with your remote git and you did your first push to the remote git repo.

git branch -a

Question : Do you notice anything different in your branches ? What is the "remotes/origin/main" branch?

• Let's switch back to the main branch

git checkout main

• Let's pull any new update of content from the remote git

git pull

Because there is no new content on your remote git so the result is "Already up to date."

• Check your git log

git log

• Okie, it's time to add some file to the local git, add, commit and push it to the remote git

touch my_greeting.txt
echo Hello From Local Computer >> my_greeting.txt
git add .

git commit -m "add my_greeting.txt on my local"

These steps so far happen on the local git or on your laptop.

• Let's push the new commit to the remote git

  • You might need to enter the Github access token again for authentication before you can push to the Github repository.

git push

That's it! Now your new changes are pushed to the remote git! That's how you can work on local git and remote git!

Remember to do git pull first before you do git push!

How to setup SSH key-pair for Github authentication

Note: There is a much better but more advanced way to authenticate for Github is to create a SSH key-pair (public and private key). The idea is that the EC2 instance got the private key and the Github got the public key and that’s how they authenticate each other! You can try to follow this setup here (Read the section 7.3).

Or you can follow these steps to setup Github authentication using SSH private and public key:

• On your EC2 instance, generate a new SSH key pair:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

• When prompted, press Enter to save the key to the default location. You can skip the passphrase by just pressing Enter to have an empty passphrase.

• Add Your SSH Key to the ssh-agent

  • Start the ssh-agent in the background:

eval "$(ssh-agent -s)"

• Add your SSH private key to the ssh-agent:

ssh-add ~/.ssh/id_rsa

• Copy the SSH Public Key

  • You need to copy the content of your public key file. You can display and copy it using:

cat ~/.ssh/id_rsa.pub

• Add the SSH Key to Your GitHub Account

  • Go to your GitHub account settings.

  • Navigate to the “SSH and GPG keys” section.

  • Click on “New SSH Key,” give it a descriptive title, and paste the copied public key.

  • Save the key.

• Test Your SSH Connection

  • Go back to your EC2 instance, to ensure that everything is set up correctly, try to connect to GitHub via SSH:

    • If successful, you should receive a welcome message from GitHub.

ssh -T git@github.com

• However, there is one more thing we need to do! The local repository is set up to use HTTPS instead of SSH for the remote URL. We need to switch the remote URL from HTTPS to SSH!

• Check Current Remote URL: First, check what the current remote URL is set to:

  • This will show you the URLs for your remote. If it starts with https://, then it's set to use HTTPS.

git remote -v

• Switch to SSH : To switch to SSH, you'll need the SSH URL of your GitHub repository. This typically looks like git@github.com:username/repository.git, which you can find here!

• You can change the remote URL with the following command:

  • Replace username and repository.git with your actual GitHub username and repository name.

git remote set-url origin git@github.com:username/repository.git

• Verify the Change: Run git remote -v again to make sure the remote URL has been updated to the SSH format.

git remote -v

• That’s it! Now you can do all remote git commands without a need to enter your username and password ever again like git clone or git push. You can make some changes, git add then git commit, finally git push to see if you can push without being asked for username and password of Github again!

• By switching to an SSH URL for your remote, you leverage the SSH keys method you've already set up for authentication, thus avoiding the need to enter your username and password for operations like git push!!!

How to handle Merge Conflicts

Let's learn how to resolve merge conflicts.

• Create a New Branch:

  • Create a branch named feature-login

git checkout -b feature-login

• Confirm if you are already on the feature-login branch

git branch -a

• Add a New File:

  • In the feature-login branch, create a file named login.txt and some text related to login features:

echo "console.log('some login features')" > login.txt

• Stage, Commit, and Push Changes:

  • Add the login.txt file to staging:

git add login.txt

• Commit the changes:

git commit -m "Add login feature"

• Push the branch to GitHub:

git push -u origin feature-login

• Merge the Branch:

  • Switch back to the main branch:

git checkout main

• On the main branch, let's merge the login-feature branch into main branch so that it got the login.txt file as well

git merge feature-login

• Push the merged changes to GitHub:

git push origin main

• Confirm the new change has been pushed to the main branch on Github:

• Create Conflicting Changes:

  • On the main branch, modify login.txt by adding "Here are some text Version 1" at the bottom. Alternative, you can use VSC for this:

nano login.txt

• Commit and push these changes to GitHub.

git add .
git commit -m "add Version 1 to login.txt"
git push

• Confirm the change on the main branch:

• Switch to feature-login and also modify login.txt by adding "Here are some text to cause a conflict Version 2" at the bottom. Alternative, you can use VSC for this:

git checkout feature-login
nano login.txt

• Try to push these changes.

git add .
git commit -m "add Version 2 to login.txt"
git push

• Confirm the change on the feature-login branch:

• Resolve the Conflict:

  • When you encounter a merge conflict after trying to push, pull the changes from main:

    • git pull origin main

• The issue arises because your feature-login branch and the main branch have diverged—they both have unique commits that the other doesn't have. When you try to pull changes from main into feature-login, Git doesn't know whether to merge or rebase the changes.

  • To resolve this conflict, you need to specify how Git should handle the divergent branches. Here are the steps:

  • Choose your reconciliation strategy :

    • Option 1 - Merge : Combines the histories of the two branches, creating a new merge commit.

    • Option 2 - Rebase : Reapplies your commits on top of the main branch, creating a linear history.

    • Both options have pros and cons:

• Since our goal is to keep both sets of changes without altering commit history too much, I’d recommend the merge option (--no-rebase).

  • Execute the chosen command:

    • For Option - merge:

git pull origin main --no-rebase

• You're encountering a merge conflict in login.txt during the merge. Let's resolve this step by step as below!

  • Verify the status of your repository, you should see that login.txt has conflicts:

git status

• Open login.txt with nano to see the conflict markers:

nano login.txt

• Decide how you want to merge the changes:

  • Option 1: Keep both versions.

    • Option 2: Choose one version over the other.

      • Option 3: Manually combine the changes.

    • Ensure all conflict markers (<<<<<<<, =======, >>>>>>>) are removed after resolving.

    • For example, in my case, I will clean up the conflict markers and create a new text to show I have resolved the conflict:

      • For example, in my case, I will clean up the conflict markers and create a new text to show I have resolved the conflict:

• Mark the conflict as resolved by adding the file:

git add login.txt
git commit -m "Resolve conflict between main and feature-login"

• Finally, let’s push the merge commit to our Github repo:

git push

• Optionally, you can check the log to verify the commits:

git log --oneline --graph --all

• Check the result on Github:

These exercises cover basic Git commands and scenarios involving creating and managing branches, handling merge conflicts, and collaborating using GitHub. They are a great way for you to get hands-on practice with Git.

GitHub will send an invitation to the email address linked to your GitHub account.

• Open the invitation email and accept the invitation within seven days.

• The invitation will expire after seven days if it is not accepted.

• Check your spam, junk, or promotional folder if you cannot find the email.

• Make sure that you are signed in to the correct GitHub account before accepting the invitation.

• After accepting the invitation, visit:

  • https://github.com/rmit-vietnam-computing-technologies/

• Check that you can see and access your assigned private repository.

• Your repository name should follow this format:

<year>-<course>-<assignment>-<campus>-<your-github-username>-<your-student-id>

• For example:

2026b-cosc2767-testing-sg-theodore-huynh-s123456

Use only the private repository assigned to you. Do not create another repository in the organization, rename the assigned repository.

Because this is a private repository, GitHub must authenticate you before allowing you to fetch, pull, or push repository content.

For this challenge, use SSH key-pair authentication. With SSH authentication, your computer or EC2 instance stores the private key, while your GitHub account stores the matching public key.

If you have done the SSH Key Pair setup in Challenge 1, then you can skip this step. If not, then follow the steps in challenge 1 to set up the SSH Key Pair in your EC2.

Repeat the main activities from Challenge 0 by creating a local repository with some local commits.

At this point, your local git repo was initialized and therefore have different commits in the git log history.

Below screenshot is exactly our local git repo commit history at the end of challenge 0 (before challenge 1)!

Open your assigned repository on GitHub and copy its SSH URL. The URL should look similar to:

git@github.com:rmit-vietnam-computing-technologies/2026b-cosc2767-testing-sg-yourusername-s123456.git

Add the assigned repository as the origin remote:

git remote add origin
git@github.com:rmit-vietnam-computing-technologies/<your-assigned-repository-name>.git

Check the remote configuration:

git remote -v

Both the fetch and push URLs should use the SSH format beginning with (“ git@github.com: ”):

origin git@github.com:rmit-vietnam-computing-technologies/2026b-cosc2767-testing-sg-theodore-huynh-s123456.git ( fetch )
origin git@github.com:rmit-vietnam-computing-technologies/2026b-cosc2767-testing-sg-theodore-huynh-s123456.git ( push )

[Only follow these steps below if you receive the following error “error: remote origin already exists”. Otherwise, skip to step 5] when running the command “ git remote -v ” or “git remote add origin” :

• This means that your local git repo has assigned a origin remote Github repo before so you cannot just add a new origin remote as you need to update it instead!

• Update the existing remote instead (to replace the previous origin remote):

git remote set-url origin
git@github.com:rmit-vietnam-computing-technologies/<your-assigned-repository-name>.g
it

• Then check it again:

git remote -v

Unlike the empty public repository used in Challenge 1, your assigned private repository already contains files such as README.md and .gitignore.

Do not immediately push your local commits as the remote Github repo has an existing commit with some files (README and .gitignore) so you will not be able to push without pulling and merging first.

So if you try to push it, you will see this error:

First, download information about the existing remote branches and commits:

git fetch origin

The git fetch command downloads the remote branch information and commits but does not modify the files in your current working directory.

List all local and remote branches:

git branch -a

You should see your local main branch and a remote-tracking branch similar to “ remotes/origin/main ”:

Inspect both the local and remote commit histories:

git log --oneline --graph --decorate --all

You may notice that the local main branch and origin/main have separate starting commits. This happens because the local repository and the GitHub repository were initialized independently.

Connect your local main branch to the remote origin/main branch:

git branch --set-upstream-to=origin/main main

Check the branch relationship:

git branch -vv

The output should show that your local main branch is tracking origin/main .

An upstream branch tells Git which remote branch should normally be used when you run commands such as “ git pull” or “git push ” without writing the remote and branch names every time.

Before pushing, pull the existing files and commits from the assigned repository:

git pull --no-rebase --allow-unrelated-histories --no-edit

The options have the following purposes:

• --no-rebase tells Git to combine the histories using a merge rather than rewriting your local commits.

• --allow-unrelated-histories allows Git to merge repositories that were initialized separately.

• --no-edit accepts Git’s default merge commit message.

The --allow-unrelated-histories option should normally only be required for the first merge between these two independently created repositories.

If the local and remote repositories contain different filenames, Git may merge them automatically. After the pull, check the result:

git status
git log --oneline --graph --decorate --all
ls -la

You should now have both:

• The files that you created locally.

• The existing files from the private GitHub repository, such as README.md and .gitignore.

[Only follow these steps if you have a conflict to resolve a merge conflict if one occurs] ( maybe happens because you got existing .gitignore or README on your local main already before the merge happens so it conflicts because it cannot merge either .gitignore or README between local main and origin/main) . [Otherwise, please skip to step 8!]

A conflict may occur if both repositories contain different versions of the same file.

Check the conflicting files:

git status

Open each conflicting file and look for conflict markers similar to:

<<<<<<< HEAD
Your local content
=======
Content from the remote repository
>>>>>>> origin/main

Edit the file so that it contains the correct final content, and remove all conflict markers.

Stage the resolved file:

• For example: git add README.md

git add <filename>

Complete the merge:

git commit -m "Merge assigned repository with local practice history"

Check that there are no unresolved conflicts:

git status

After successfully fetching and merging the remote content, push the combined history to your assigned private repository:

git push

Because the upstream branch has already been configured , Git knows that the local main branch should be pushed to origin/main .

Optional that if you want to, you can also explicitly write the remote and branch instead of just “git push”:

git push origin main

Return to your repository on the GitHub website and refresh the page. Confirm that you can see:

• Your local practice file.

• The original README.md and .gitignore files.

• Your local commits.

• The merge commit that combined the local and remote histories.

Your tasks (if you want more practice):

• Practise the Normal Pull–Commit–Push Workflow:

  • Make another local change.

  • Stage and commit the change.

  • Before pushing, pull and merge any new remote updates.

  • Then push your commit.

  • For example, the normal workflow is:

git status
git pull --no-rebase
git add .
git commit -m "Describe the change"
git push

• Make sure that your current work is committed or safely stored before pulling remote changes.

• Practise with a New Branch:

  • Create a new local branch.

  • Create and commit a file.

  • Push the new branch and configure its upstream branch. (for example, “ git push -u origin practice-feature” )

  • List the local and remote branches.

  • Switch back to main.

  • Pull the latest remote changes (for example “ git pull --no-rebase ”)

  • Merge the practice branch.

  • Push the updated main branch.

  • Check the repository and branch list on GitHub to confirm that both branches were pushed successfully.