Week 3: Working with Git

Git and GitHub: Mastering the Art of Version Control

Welcome to the wonderful world of version control! Ever wondered how developers seamlessly update apps, collaborate on complex projects, and maintain code history? Look no further! This tutorial will guide you through Git and GitHub, the dynamic duo of version control.

Part 1: Git – Your Time Machine for Code:

Imagine a magic button that lets you rewind and replay changes to your work. That’s essentially what Git does! It tracks every modification you make to your code, creating a detailed history you can navigate freely.

Why Git?

• Collaboration Magic: Work with others seamlessly, knowing each change is documented and accessible.
• Fearless Experimentation: Try new ideas without worry. If something breaks, simply revert to a previous version.
• Clean Code History: Understand the evolution of your project, identify bugs easily, and track individual contributions.

Part 2: Unveiling the Git Workflow:

1. Initialize: Create a Git repository to start tracking changes.
2. Stage: Mark specific changes you want to include in the next snapshot.
3. Commit: Capture the staged changes, creating a new version with a descriptive message.
4. Branch: Explore new ideas without affecting the main project. Merge changes back when ready.
5. Remote: Push your local repository to a remote server like GitHub for collaboration and backup.

Part 3: GitHub – Your Social Hub for Code:

Think of GitHub as a vibrant community for developers. It stores your Git repositories online, enabling:

• Collaboration: Share your code, invite others to contribute, and work together on projects.
• Version Control: Manage your Git repositories through a user-friendly interface.
• Code Visibility: Make your projects public or private, showcasing your skills and connecting with others.

Part 4: Let’s Get Practical!

Ready to dive in? Here are some resources to get you started:

• Interactive Git Tutorial: https://learngitbranching.js.org/
• GitHub Guides: https://docs.github.com/en/get-started/quickstart/git-and-github-learning-resources
• Online Courses: Platforms like Coursera and edX offer beginner-friendly Git and GitHub courses.

Remember:

• Version control is a valuable skill for developers of all levels.
• Start with the basics and gradually expand your knowledge.
• Practice makes perfect! Experiment with Git and GitHub to unlock their full potential.

By mastering Git and GitHub, you’ll become a more confident and collaborative developer, ready to tackle any project with ease. So, grab your virtual pickaxe and let’s explore the exciting world of version control!

Are you familiar with version control or
version control systems? Here’s a quick example
of where they’re useful. Have you ever opened an
app on your phone and received a prompt to
update to a new version? These prompts most likely
direct you towards an app store where you then
download the latest version. As you download the new version, you might notice a new layout, button, or piece
of functionality. In software and web development, developers use version control to track the differences
between versions. A popular method of
tracking versions is the use of version
control technologies, like Git and GitHub. In this video, you’ll discover the answer
to the question, what is Git and GitHub? You will learn about
the differences between Git and GitHub, and how web developers
make use of them, and explore the benefits and
advantages of both services. Let’s start off with Git. Git is a version control
system designed to help users keep track of changes to files within their projects. Git was designed to fix the
problem that it’s created, Linus Torvalds was
having with managing the huge challenge of keeping track of all changes
to the kernel, the operating system for Linux. Linux has thousands
of contributors who commit changes
and updates daily. Git was designed to
help with the challenge of tracking all these
changes and updates. As well as helping to
keep track of changes, Git was also designed
to tackle some of the shortcomings of other
version control systems. The benefits that Git offers over similar systems include, better speed and
performance, reliability, free and open source axis, and an accessible syntax. It’s also important
to note that Git is used predominantly
via the command line. Developers tend to find Git syntax and commands
easy to learn. The other service
commonly used by web developers is GitHub. GitHub is a Cloud-based
hosting service that lets you manage Git repositories
from a user interface. A Git repository
is used to track all changes to files
in a specific folder, and keep a history of
all those changes. It incorporates Git version
control features and extends these by providing
its own features on top. Some of the most common of these features include
access control, pull requests, and automation. You will learn more about
these later in this course. The features are split out into different pricing models to suit different sized teams
and organizations. It’s also important
to point out that GitHub is very popular
among web developers. It’s like a social network. For example, projects can
be private or public. Users on GitHub have their own profile which
other users can follow. Public projects can accept code contributions from
anyone across the globe. It also includes
multiple features outside of its core development
tools like documentation, ticketing, and project features. You’re now familiar
with Git and GitHub version control
systems along with the benefits and advantages
that they offer. This is just the beginning of your version control journey with Git and GitHub. Great work.

GitHub provides you with many options for cloning a repository. With which of the following options do you need to set up SSH keys and assign them to the user accounts?

SSH

That’s correct. GitHub allows you to connect using the Secure Shell Protocol (SSH). This provides you with a secure channel over an unsecured network.

I have just logged in
to the GitHub website. Once there, I click on the green button with the
text Create Repository. When I click on the button, I am redirected to the create a new repository
screen where I’ll be prompted for
who the owner is. I choose my account as the
owner option for this example. Next, I need to input
a repository name. I type a name called
my-first-repo. Notice that the input field has a green tick icon beside it. This is just GitHub
letting me know that this name is available to
create the repository. If it’s not, I will see an X icon and be
prompted to rename it. Now I need to type a value
for the description input. For this, I type practice
account for learning Git. The next option I want
you to know about is if you want the repository
to be public or private. Public just means that anyone on the Internet can
see the repository. I still have control over
who can make changes to it. It’s just available on the viewable aspect of
it on the Internet. The next option is private, meaning it’s not available
for anyone to see. I can only allow access by granting people access
to the repository. The next few options are
about initialization. I can initialize a repository
with a README file, a gitignore file, and a
license if one is required. For now, I’m just
going to choose the README file option and then click the “Create
repository” button. A repo has now been set up
and I can see that I have one single file in the
repository called README.md. Md is just short for markdown, a popular method for creating
documentation because it’s shorthand for
creating HTML pages. This allows me to do things like creating titles and texts. I can insert images and various
other webpage elements. Notice that the main branch has also been created and
it’s important to know that every repository you create will have a single
main branch at the start. This is also known
as the main line. Next, I’m presented with
additional button options. The first is labeled Go to file, then there is Add file, which you can use to add
a new file from the UI. Finally, a green
button labeled code. Clicking this button
provides me with a GitHub UI options for
cloning down the repository. First is the option for HTTPS, which contains the HTTPS URL of the repository and I can use this to pull it down by
using the git clone command. Next, there is an option
for SSH but to use that, I have to set up my SSH keys and assign
them to the user accounts. Finally, I have the
GitHub CLI option. Underneath, notice
that there are additional options
for GitHub Desktop if I would like to use that. Finally, I can also download a compressed zip file containing all the files and
folder structures. For this demo, I will show
you how to use HTTPS. To begin, select the
HTTPS option and click on the “Copy” button to copy
the HTTPS URL for cloning. Now I go to my command
line that I will be using to run the commands
to clone the repository. I’m currently in
my home directory. What I usually like to do
is create a directory for all repositories that I’m
working on at the moment. First, I create a directory
using the command, mkdir, then I type the name
of the directory I want to create,
which is projects. Next, I can cd into that, and now I can run
the commands to clone the project
from the GitHub UI. To do this, I type the
command git clone and paste the HTTPS URL
I copied earlier. Finally, I press
“Enter” on my keyboard. Notice that I receive a
message stating that git is cloning into the
my first repo folder. It then displays messages about all the objects that
have been received. It also displays a
100-percent status message, and then finally, a statement
that simply says done. Now I can list the directory by running the ls-la command, which means list
all directories. Notice that I have
my repository, which I named my first repo. This is the name
of the repository that we set up on GitHub. Finally, if I enter inside that folder
using the cd command, I can see a single file,
the README.md file. If I use the ls-la command, another file is listed, which is just named.git. You will learn more about
this later when you explore how to use this
for source control.

As you now know,
GitHub is a cloud based hosting service, that lets you manage Git
repositories from a user interface. It’s like a social network. You can follow users or accept code
contributions from anywhere in the world. In a previous video, you created and
cloned a repository to your local device. I am now going to explain to you how to
pull the repository to your local device. I will be demonstrating commands that
you can use in GitBash shell for Windows users, and terminal for Mac users. This refers to the application
where the commands are typed in. Let’s move to the directory
I want by typing cd, and the name of the directory my-first-repo. Once inside the directory,
run the list all command by typing ls- la. -la is short for list all. There are four items in this directory. I will focus on two of them,
the git item, and the README.md item. Let’s start with the README.md file. This item was added when I
created the repository on GitHub. The other item, is a folder called .git, which is a hidden
folder used to track all the changes. In Linux, any folder starting
with a dot is a hidden folder. This folder is automatically created
when you create a repository. And you will learn more about
it later in this course. In the command I ran I
ended the switch -la. So we would list all files and
folders including the hidden ones. The .git folder is initialized
by running the git INT command. As the repository was created on GitHub,
it was not required for us to run it. GitHub handled all of this as
part of its create new repo flow. Now, let’s focus on Git Workflow. Git uses workflows which can be
broken into three states namely, modified, staged, and committed. Now, I will go over each state and then
provide an example of adding a new file to my gift repository to show it in action. Let’s start with the first state,
adding removing and updating any file inside the repository
is considered a modified state. Git knows the file has changed,
but does not track it. This is where the staging state comes in. Let’s turn to it now. In order for Git to track a file,
it needs to be put in the staged area. Once added, any modifications are tracked. Which offers a security blanket
prior to committing the changes. Then, the last state is
the committed state. Committing a file in Git is
like a save point in many ways. Git will save the file, and
have a snapshot of the current changes. Let me introduce you to an example
that summarizes the workflow clearly. Suppose you have a workflow that contains
the three stages just mentioned, as well as the remote repository, a file is added from the working
directory to the staging area. From there the file is committed, and
then pushed to the remote repository. From the remote repository,
the file can now be fetched and checked out, or
merged to a working directory. You will learn more about this later. Well done, you’ve covered some
of the Git fundamentals and now know what is inside a Git folder and
understand the Git Workflow.

You are working on a project and have to share some code with a colleague.  What is the correct order the code will flow in Git workflow?

Working directory, staging area, committed files, remote repository

That’s correct! The correct workflow is from the working directory to the staging area, then to committed files, remote repository and lastly to your colleague.

So I’ve opened up my terminal window. I’ll have a look at what directory
I’m currently located in. I can do this by running the pwd
command which is short for print working directory. Notice that I’m in
the directory my-first-repo. Now I can check inside that directory
by running the ls- la command. I can see that I have two items,
a README.md file and a hidden folder called .git. Before I add any files or
make any changes, it’s always good practice to check if any
changes or commits are currently there. I can do this by using
the git status command. Git status also displays
what branch I’m on. In this instance, I’m prompted that
I’m on the branch called main and that my branch is up to
date with the origin main. This means that all the latest files on
my local machine are exactly the same as what is displayed on the GitHub UI, which represents the server
that everyone commits to. Git status also tells me that
I have nothing to commit and that my working tree is clean. Now, let me show you how
to add a simple text file. I’ll add a file called test.txt by
using the command touch test.txt. Then I’ll run the command
gitt status again. Now git is telling me that I have
an untracked file which is the test.txt file that I just added. It’s also telling me that I have
nothing added to the commit but that untracked files are present and
that I should use git add to track them. The purpose of the git add command is
that I’m essentially prompting git and letting it know that I want
to track this file, and that it will be included
as part of my commit. The first phase of this process is just
to run the command git add test.txt. Now I’m going to run git status again to
check that file is now being tracked. Notice again, that I’m notified
that my branches are up to date. But it’s also telling me now that there
are staged changes to be committed, which is this new file called test.txt. It prompts me asking if I
want to revert those changes. For this, I can use the git restore
command with the flag– stage and the file name test.txt. Running the command will unstage
the file from the commit. I then run git status one more time to see
the file is back to an untracked status. So once again I’ll add the file
using git add test.txt. Run git status, and now notice that
the file is back in a tracked state. Okay, let me clear my
screen before moving on. To do this, I use the clear command. Now any changes that I make from
here on will be tracked and then at the end I will use
the git commit command. The staged area is really important
because you’re essentially preparing to get all of the files and changes that you want as part of
whatever feature you’re working on. Basically, you are getting all of
that content ready for commit. You also have to remember that this
is only on your local machine. The distributed manner of git
means it will only push to the server using the actual
push command itself. But any change you make here is only
specific to you and your local machine. Anyone else who pulls down the project
from GitHub will only get what’s available on the remote server. Okay, now I want to explain to you
how to run the git commit command. First, type in git commit, you can
pass in a flag of -m which stands for message, allowing you to type in a message
which will be attached to the commit. In this example, the message is
adding a new file for testing. Next, press Return on the keyboard and
now notice that the response states 11 file change 0 insertions,
0 deletions. There is also a create mode statement
with the name of the file test.txt. Finally, if I run the git status command, the response says that there is nothing
to commit and the working tree is clean. However, I want to be aware of
the message at the top of my screen. This message tells me to use git
pushed to publish my local commits and this ties back in with
what I mentioned earlier. All of these changes
are on my local machine, and they will only be uploaded to the
remote server when I run the push command. You’ll learn more about the push and
pull commands in a future lesson.

You've learned that Git works on the principles of the edit, stage, and commit pattern. But when you edit a file in your Git working directory it will not be tracked until it's added. You can do this by using the Git commit command.

False

That’s correct! You use the Git add command to tell Git that the file is staged to be committed and that any further changes to the file will be tracked going forward.

Tutorial: Branching Workflow for Collaboration with Git

This tutorial guides you through the essential steps of using Git’s branching workflow for effective collaboration on software development projects.

Prerequisites:

• Basic understanding of Git commands
• Familiarity with GitHub or a similar Git hosting platform

Scenario:

Imagine you’re working on a new feature for a shared project. You want to develop and test it without affecting the main codebase. Branching allows you to achieve this safely and efficiently.

Steps:

1. Start with a clean slate:
   • Ensure you’re on the latest version of the main branch using git pull.
   • Check your current branch with git branch.
2. Create a new branch:
   • Choose a descriptive name for your feature (e.g., feature/add-login or fix/memory-leak).
   • Use either git checkout -b <branch_name> or git branch <branch_name> to create the branch.
   • This creates a new branch based on the current state of the main branch.
3. Develop your feature:
   • Make your changes within the new branch.
   • Add, commit, and push your changes as usual using git add, git commit, and git push.
4. Collaborate and review:
   • Create a pull request on your Git hosting platform (e.g., GitHub).
   • This submits your changes for review by other team members.
   • Discuss and address any feedback received.
5. Merge your branch:
   • Once approved, merge your branch into the main branch.
   • This integrates your changes into the main codebase.
   • Use the platform’s interface or git checkout main and git merge <branch_name> in your terminal.
6. (Optional) Delete your branch:
   • After merging, consider deleting your branch using git branch -d <branch_name>.
   • This keeps your repository clean and organized.

Tips:

• Use clear and descriptive branch names that reflect the change you’re making.
• Regularly synchronize your local branch with the remote repository using git pull.
• Adhere to your team’s specific branching and merging policies.
• Consider using tools like merge commits to provide context when merging complex changes.

Benefits of Branching:

• Isolates development: Features and bug fixes remain separate from the main codebase, preventing accidental modifications.
• Enables collaboration: Pull requests facilitate code review and discussions, improving code quality.
• Simplifies merging: Merging specific changes from branches is cleaner than merging entire histories.
• Improves organization: Branching helps manage complex projects with multiple features under development.

Conclusion:

By mastering the branching workflow, you can collaborate effectively with other developers, maintain a clean codebase, and deliver high-quality software. Remember, continuous practice and exploration of advanced Git features will solidify your understanding and contribute to even more efficient development workflows.

True or False

The purpose of a pull request is to obtain a peer review of changes made to the branch. In other words, to validate that the changes are correct.

True

That’s correct! When you create a pull request you are asking the other developers to review your work and approve it to be merged with the repository.

I’ve opened my command line. I should check to
ensure that I’m in the correct directory
using the PWD command. I can see that I’m in the
my-first- repo directory. Now it’s good
practice to perform a git status command to make sure that I have no
commits outstanding. If there are no commits
and the shell is clear, then my branch will
show as up-to-date with origin main outside of
the main branch itself. My next step would be
to create a new branch. To create this new branch, I use the git checkout command by typing git checkout dash b. I then call this new branch feature
forward slash lesson, which I’ll refer to as feature lesson for the
purpose of this video. But this is just one
way to create a branch. I could also use git branch
and pass in the name as well. These methods are the same and can both be used to
create a branch. The key difference
between them is that git branch just
creates a branch. But git checkout dash B moves me from the main branch into
the branch that I created. I can verify that I’ve
been moved between branches by running the
git branch command. This will then tell me
if I have switched from the main branch to one of
the feature lesson branches, any changes that I make will now only occur in this new branch. It’s important to remember that the main branch has no
indication or knowledge of any of these
changes even when I push code to the
main repository, this is because that branch
exists in isolation. The new branch needs
to be merged back into the main branch to recognize changes in the feature
lesson branch. This is where it’ll come
in with a pull request. The purpose of a
pull request is to obtain a peer review of
changes made to the branch. In other words, to validate that the changes are
correct when coding, many teams will have
conditions around the unit tests and
integration tests. These conditions will usually
include validating that the standards have been met for merging back into the main line, a team will also check for any issues that might
have been missed. The next step is to add a
file to the new branch. I can create a simple
text file called test2.txt using the
command touch test2.txt. Then I add it using
the git add command. I then commit it using
the git commit command. Once I’ve committed
the new file, I need to push my changes up to the remote repository
with git push. I type git push- u
origin feature lesson. It’s good practice
to specify dash U. This means that
I’m only going to get updates from the upstream, which in this case will
be the main branch. The result of this is that the origin won’t be my
main branch anymore. Instead, it’s feature lesson. I press the enter
key and this pushes the new branch up to
the remote repository. As I am using https, I will be prompted for
my login information. Once this action
has been completed, GitHub will recognize that a
new branch has been added. It will then prompt
me to create a poll requests that can be compared
against another branch, in this case, the main branch. My next step is to
open the GitHub UI. GitHub will show my new
branch with a prompt. Click on the compare and
pull request button. A pull request lets the team know that I’ve made new
changes that I want them to review and that I
also want to approve or request changes to the
actual poll request itself. Another thing to note on the GitHub UI is that I’m comparing this with
the main branch. I’ve essentially
cut a branch from the main called feature lesson. I’ve then added a new
file called test2.txt. It’s this file which is the main difference
between the two branches. Next, I check the pull request. I can see that there
has been one commit. In other words, just one
file has been changed and it’s been added
as test2.txt. I then click create
pull request. The team will then
review the changes and either approve
or decline them. Once approved, you can then merge your changes
to the main branch. This is much cleaner than everyone working off
the main branch. It’s particularly
useful if you have features that are
closely tied together. For example, you could be working with a feature
that crosses over with some code or requires
changes that most likely will be
altered by someone else. The approach of keeping
everything at branch level is much easier than having everyone working
from the main line. In fact, everyone working off the same branch is more
likely to cause issues. Having independent
branches makes the project easier to manage. Also, there’s no limit to how
many branches you can have. The team decide on the naming
conventions that they use. In a lot of cases when
adding a new feature, you can add the keyword feature then followed by
the branch name, like a URL path, such as feature forward slash
lesson in this example. For bug fixing, fix
forward slash can be used. Because we have no reviewers
in my current project, I’m just going to
merge the branch. Then I’ll confirm the merge. Once confirmed, I’m presented with the option to
delete the branch. On your own projects, it’s up to you
whether you want to keep the branches
or delete them. For now, I’m going
to keep the branch. Then I can return to
my code where the test2.txt file has merged
into the main branch. I can then confirm that by
going back to my command line. Next, I look at git status again to check if there
is something to commit. At this point, there’s
nothing outstanding. I’m still in the
feature lesson branch. I can check out
my main branch by typing git checkout main. Then I run the git pull command. I’ll then receive the latest
changes that were merged in from the feature branch
that I just created. Notice that the test2.txt
file is now available. I can also verify that by doing a simple check within the directory by
using the ls command. This returns a read-me file
test.txt and the test2.txt, which is from my branch. You have now learned
the branching workflow, which will use regularly when collaborating with
other developers.

Tutorial: Understanding Local vs. Remote Repositories in Git

Welcome to this tutorial on understanding the difference between local and remote repositories in Git, a popular version control system used for software development.

The Local Playground:

Imagine you have a project folder on your computer. This serves as your local repository. It contains all the files and directories related to your project, allowing you to work on them independently. It’s your personal workspace where you can make changes, experiment, and track revisions.

The Central Hub:

Now, imagine a shared storage space accessible to your team or other collaborators. This is called a remote repository. Often hosted on platforms like GitHub, Bitbucket, or GitLab, it serves as the central location for your project’s codebase. Everyone with access can view, download, and contribute changes to the project.

Bridging the Gap:

So, how do you connect your local playground to the central hub? This is where Git commands like clone, pull, and push come in:

• Clone: When you first want to work on a project hosted remotely, you use git clone to create a local copy (repository) on your machine. This is like downloading the project blueprint.
• Pull: After working on your local copy, you can use git pull to fetch the latest changes from the remote repository. This keeps you in sync with the central codebase and incorporates contributions from others.
• Push: Once you’ve made your own changes and want to share them with the team, you use git push to upload your local modifications to the remote repository. This is like contributing your updated blueprint back to the central hub.

Benefits of Teamwork:

Using local and remote repositories in conjunction offers several advantages:

• Collaboration: Multiple developers can work on the same project simultaneously, each in their own local environment.
• Version Control: Both local and remote repositories track changes over time, enabling you to revert to previous versions if needed.
• Offline Accessibility: You can work on your project even without an internet connection, pushing your changes later when you’re online.
• Shared Progress: Team members can easily see and integrate each other’s contributions through the remote repository.

Putting it into Practice:

Imagine you’re working on a website design project with your team. Each team member has a local copy of the website files (local repository) where they can edit and design specific pages. After making progress, you can all push your changes to the remote repository on GitHub, making them accessible to everyone. Collaborators can then pull the latest updates, review your work, and suggest further improvements.

Remember:

• Local repositories are your personal workspaces, while remote repositories are the central hubs for shared projects.
• Clone, pull, and push are essential commands for connecting your local and remote environments.
• This workflow enables efficient collaboration, version control, and transparency in software development.

By understanding these concepts and practicing with Git commands, you’ll be equipped to contribute effectively to collaborative projects and maintain a well-organized codebase.

Feel free to explore further resources and practice the commands mentioned to solidify your understanding of local and remote Git repositories!

You have created a new local repository called “test-repo”. Which command would you use to set the remote repository in git?

Git remote

That’s correct! You would use the Git remote command to set the remote repository.

In the pre-internet era, saving project
files to different machines for backup and transfer was a tedious process. It required manually copying files
between machines, one at a time. Making things slow for teams. Nowadays the cloud has enabled
a more efficient way to do this. And in this video I’ll explain
the differences between remote and local on Git hub. You have previously learned about
the flows modified, staged and committed in a Git workflow. Now you will learn about
pushing your changes from your local to a remote repository. Remote refers to any other
remote repository to which developers can push changes. This can be a centralized repository,
such as one provided by Git hub or repositories on other developer devices. In this lesson, you will be hearing
some new terms such as clone, push, pull and repo. Don’t worry. These will all be explained soon. The remote code is accessed
through a URI which is unique and only accessible to those
who have permission local. On the other hand refers to your machine
which can be a laptop, desktop or even a mobile device and is only accessible to you to
demonstrate both of these in action. Let’s say we have a project called
coding project one which is located on Git hub with a unique URL. In other words,
this project is stored on a remote server. When a user wants to copy this project to
their local device, they need to either perform a clone if it’s the first time or
pull it to get the latest changes. To clone a project a user must first
choose a folder on their local machine. Coding project one is then cloned from the
server and copied into the chosen folder. The user can then make
changes to the project and push those changes back to the server. Other users working on the code base won’t
see those changes on their local machines unless they pull the latest
changes from the server. One of the advantages of it is
that you can work offline and then commit your changes
when you are ready. Now let’s go through an example of how
exactly you would do this and Git hub. In this video I’m going to explain what
local and remote mean in Git hub and help you to understand
the differences between the two. First off, I’m going to create a new local
repository using the Git in IT command. I’ll start by inputting M K D I R
to create A new directory and then I’ll set the name as my second repo. Next I’ll use the change directory
command which is CD followed by the name that I just said. Finally, I’ll perform the Git in IT
command to create my new repository. This will return a line
telling me that an empty repository has been initialized
under route projects my second repo. If I execute another command called
git remote, it comes back as blank. The reason for that is that I’ve only
initialized a local repository which has no connection to a central repository that
sits either on Git hub or another server. Right now it’s only available
locally on my machine. Now I’ll step back out
from this directory and go into my first repo with a CD command. Again, this is a repository
that I created earlier and does have a connection to Git hub. Using the remote URI I’ll then check it
by using the get remote minus V command. Git tells me that it’s set to git
tutorials 101 my first repo.Git. Next I’m going to set this
against her second repository. I’ll step into the new directory
once more using the CD command. In this case we’re going to add this
URL to the remote settings by using the command. Git remote add specifying a name and
then passing in URI, the name that is typically
used here is origin. So I’ll stick with that. So again the full command with the URL
should read Git remote at origin. Git at Github.com: Git tutorials 101/ My first repo.Git. This time when I execute
the Git remote minus V command. I have this set up against the get
tutorials 101 which sits up on Git hub. What I’m going to do next is use the Git
pull command which will connect with the GIT hub server, and pull down
all the changes from the repository. So on my local I now have all the changes,
but when I check the directory it’s blank. The reason for this is that I haven’t
set up a branch that matches with what I have on the server repository. Fortunately I can change that
by performing the command. Git check out main. Which will set up a branch main on my
local that tracks the branch main from the remote. And now when I check my
folder using the LS command, it confirms that I have the read me test
and test two files available on my local. In this video, you learned about
the differences between local and remote and Git hub. This will help set you up to exchange
data more efficiently within your development team. See you next time.

Tutorial: Pushing and Pulling Changes with Git

Welcome to this tutorial on mastering the essential Git commands for managing your project versions: git push and git pull.

Before we begin:

Ensure you understand the concepts of local repositories, remote repositories (like GitHub), and staging changes with git add and git commit.

Pushing Changes:

1. Check your branch: Use git branch to confirm you’re on the correct branch where you made your changes.
2. Craft the git push command:
   • Specify the remote repository (usually origin for GitHub).
   • Specify the branch you want to push changes to (often main).
   • Example: git push origin main pushes changes from your local main branch to the main branch on the remote repository.
3. Enter login credentials: When using HTTPS, Git will prompt for your username and password.
4. Monitor the push: Observe the command output and any potential conflicts.
5. Verify on your platform: Check your chosen platform (e.g., GitHub) to see if your changes are reflected.

Pulling Changes:

1. Prepare for merging: Ensure your local branch is up-to-date with local commits using git pull without specifying a remote.
2. Initiate the pull: Use git pull <remote> <branch>. Example: git pull origin main pulls changes from the main branch of the origin remote and attempts to merge them into your local main branch.
3. Resolve conflicts (if needed): If Git encounters conflicts (overlapping changes), manually edit the conflicting files and resolve the issues.
4. Enjoy the merge: Once conflicts are resolved or no conflicts exist, Git merges the remote changes into your local branch.
5. Confirm your changes: Use git status to see the merged changes and ensure everything looks correct.

Remember:

• Pushing shares your local changes with collaborators on the remote repository.
• Pulling fetches the latest changes from the remote repository and merges them into your local branch.
• Regular pulling keeps your local repository in sync with the project’s development.
• Clear and descriptive branch names enhance collaboration and organization.

Benefits:

• Efficient collaboration on projects with multiple contributors.
• Maintain a clear history of changes and versions.
• Work offline and synchronize your changes later.
• Identify and resolve potential conflicts before they impact others.

By mastering git push and git pull, you’ll become a valuable contributor to collaborative projects and ensure your code stays organized and up-to-date.

Feel free to experiment and practice these commands to solidify your understanding and become a Git pro!

When you perform a Git Push command, it copies content from your local repository and then uses it to merge all of the content in the remote repository.

False

That’s correct! When you use Git Push, Git compares a snapshot of your local repository with the remote one and only replaces the files that have been changed.

By now, you should know
how to use git add, and git commit to add new changes to your
local repository. Put them into the staging area, and get them ready for a commit. Now, let me guide you through
the next step in uploading these changes to the remote
repository using git push. I’ll also demonstrate how
to retrieve changes from the remote servers
and apply them to your local repository
with git pull. Before we begin, let’s go over the command line and perform
the command git status. Git tells me that I’m
on the branch, main, but also the my branch is ahead of the origin main
branch by one commit. What this means is that
all the changes that I have on my local
repository are currently ahead of what is stored in the remote repository on
GitHub that ties into Git’s distributed
workflow in which you can work in an offline state
and then only ever communicate with a remote
repository when you use the commands of
git push or git pull. Now I’ll guide you on pushing your changes to the
remote repository, and then I’ll
demonstrate how to use the pull command to get
the latest changes. It’s always good practice to check which branch
you’re currently on. You can use git status or
git branch to do this. This is important
because if you do make changes in a
different branch, you need to specify where
you’re pushing up to. Let’s push up the changes
using the git push command. I’ll specify the origin
branch to be the main branch. As in, I’m pushing my changes to the origin as the
remote repository, and then I want to push it
to this branch as the main. I’ll be prompted for
my login information as I am pushing using HTTPS. Once I enter my
login information, you’ll notice that
the commit is pushed from the local main
to the remote main, on the remote repository. Let’s refresh the page
on the GitHub website. You can see that my test.txt
file now appears there. That’s taken the commit
snapshots that I have in my local repository and pushed it up to the remote repository. Git has then compared
those files with what’s on the remote repository to find
any conflicts or problems. If none are found, it’ll just merge them
straight through, which is classed
as an auto merge. If there are any conflicts, my push will fail. Before doing a push, it’s also good practice to perform a git pull
in order to get the latest changes from the remote repository and reduce the odds of encountering
a conflict. Because I only
have a single file and this will be
a new repository, I’m not going to run into
any conflict or any issues. Now let’s move on and I will guide you through how
you can use git pull. Normally when you’re
working on a project, you could have several
developers all submitting with
different branches, different code, and
different features. In order for you to
get those changes, you need to use the
git pull command. To demonstrate this, I will add a single line to
the test.txt file, using the GitHub UI and then
add the climate change, updated the test.txt file. I’ll then commit it directly
to the main branch, by clicking on Commit Changes. The changes now
appear on the UI. But because I haven’t
used the git pull command on my local machine yet, I should have no content
of the test.txt file. Let’s verify by using the
cut command on test.txt. Sure enough, the file is empty, which is what you’d expect. As I mentioned before, I need to run the
command git pull. This will get the latest changes from the remote repository. If any new changes were added, it’ll be reflected
in the shell output. I run the command, and in this case, Git tells me that one file has changed with one insertion. If I run the cut command
on test.txt once more, it shows that the
line “this is my change” is now available
in my local directory. With git pull, you’re taking all that data
from the remote server. Git then merges the
snapshot from the remote with the snapshot
that’s on your local. It will auto merge them
if there is no conflicts. Once that’s complete, I’ll have the latest changes
on my local machine. You have now learned
how to push to and pull from your
GitHub repository.

Tutorial: Mastering the Flow – Demystifying Workflows in Software Development

Welcome, fellow developers! Today we embark on a journey to understand the hidden magic behind efficient software development: workflows. These aren’t just fancy words, but a well-defined series of steps that guide your team to create high-quality code, collaborate effectively, and avoid chaos. By the end of this tutorial, you’ll be equipped to:

• Define workflows: Understand their purpose and benefits.
• Navigate feature branching: Master a popular workflow strategy.
• Choose the right flow: Select the workflow that fits your team and project.

Step 1: Why Workflows?

Imagine a construction site without blueprints. It’s messy, inefficient, and prone to errors. Similarly, software development without a workflow is an accident waiting to happen. Workflows provide structure, ensuring everyone knows what to do, when, and how. This leads to:

• Clarity and organization: Each step is defined, preventing confusion and duplication of effort.
• Efficient development: Streamlined processes minimize delays and optimize time usage.
• Improved code quality: Clear standards and reviews ensure code maintainability and fewer bugs.
• Effective collaboration: Teamwork becomes seamless with shared understanding and communication.

Step 2: Feature Branching Flow

One popular workflow is feature branching. Think of it like building separate rooms in a house:

1. Start fresh: Pull the latest code from the main repository to ensure everyone’s on the same page.
2. Branch out: Create a new branch dedicated to your specific feature. This isolates your changes and protects the main codebase.
3. Build and test: Work on your feature within the branch, adding code, testing functionality, and maintaining quality standards.
4. Commit and share: Once happy, commit your changes with clear messages describing what you did. Push them to your branch on the remote repository.
5. Seek feedback: Create a pull request, essentially asking your team to review your work. This collaborative review ensures code quality and adherence to standards.
6. Merge and celebrate: Upon approval, merge your feature branch back into the main codebase, effectively integrating your work into the bigger picture.

Step 3: Beyond Feature Branching

While feature branching is popular, it’s not the only option. Different workflows cater to various team sizes, project types, and preferences. Explore other options like:

• Gitflow: Similar to feature branching, but with dedicated branches for releases and hotfixes.
• Continuous integration/continuous delivery (CI/CD): Automates testing and deployment, promoting frequent updates.
• Kanban: Focuses on visualizing work and optimizing workflow based on real-time needs.

Step 4: Choosing Your Flow

There’s no “one size fits all” answer. Consider these factors when choosing your workflow:

• Team size: Smaller teams might prefer simpler workflows, while larger teams need more structured approaches.
• Project type: Rapidly evolving projects might benefit from CI/CD, while stable projects might do well with feature branching.
• Company culture: Consider your team’s preferences and existing practices.

Remember: The best workflow is the one that empowers your team to deliver high-quality software efficiently and collaboratively. Experiment, adapt, and continuously improve your process to achieve optimal flow!

Bonus Tip: Utilize tools like Git, GitHub, and project management platforms to automate and streamline your chosen workflow.

By mastering workflows, you unlock the true potential of your development team, transforming software creation into a smooth, collaborative, and rewarding experience. Now go forth, embrace the flow, and build amazing things!

As part of a development team tasked to change an existing app, you have created a feature branch. Is it possible for your team members to see the changes you are currently working on?

Yes

That’s right. The branch you created, is only visible to you. You have to commit your changes and push the accepted changes to the main server before your team members can see them.

Have you ever applied for a job? You know the process,
prepare your resume, look for jobs, submit an application,
prepare for interviews. That is an example of a workflow, in computer programming
workflows are really important. By the end of this video, you will be
able to describe what a workflow is, and you will also be able to identify
different workflows available. Now, let’s start with an example to
illustrate why workflows are important. As a developer working on a project, you
first need to pull the project down from a remote repository to your local machine. This is commonly called checking
out a project or pulling a project. Once on your local machine, you can build
and run the project and make changes. When you’re done,
you have to push the changes you made back to the remote repository so
other developers can see them. From this example, you can understand that
the purpose of a workflow is to guide you and other members of your team. It should not disrupt or cause blockers
for deployment or testing or for any other developer who
contributes to the project itself. Choosing a workflow needs
careful consideration. It can depend on the size of the team,
the culture of your workplace and also the type of product you
intend to build or update. With that in mind,
let me explain feature branching, a common workflow used by many developers. Feature branching means you create
a new branch from the main line and work on this dedicated branch
until the task is completed. Rules and
conditions need to be made in order for this branch of code to
be kept in a good state. Every code base has a main repository
which is essentially the source of truth for the application. All changes such as add,
edit or delete are submitted directly to the feature branch,
the main branch stays as is. When you are ready and
happy with the code you have added, you have to commit the changes and
then push to the server repository. To commit, you push the changes and
as it’s a feature branch, a pull request follows. The pull request is compared
to the main branch, so developers who peer reviewed the code
can see exactly what was changed. Once it’s reviewed and approved,
it can then be merged into the mainline. Now let me guide you through how
this works using Git and Git hub. Before creating a new branch,
always ensure you have the latest code. You can do this by running
the git pull command to pull the latest code from
the remote repository. Next you need to create your new branch. You can do this by passing the -b
flag with the check out action. Next, let’s add new
content to this branch. Let’s create a README.md file,
to do this type git add. or git add README.md and press Enter. Next, we need to commit the new file and
provide a meaningful message so other developers can see what you added. To do that Run the git commit
command with a -m option to include a message with a short description
of the changes being committed. The file has now been
added to the local branch, this means that the file is
only visible locally to you. To allow other developers
to see the changes, you need to push the file
to the remote repository. You can do that by running the git push
command and referencing the new file. The changes are now pushed to
the remote repository on git hub. Your next action is to get a review
as part of a pull request, but more about that later. And that brings us to
the end of this video. Now, you know what a workflow is and
how a feature workflow works, well done.

Whenever a change occurs for a commit, the single hashed ID will update to be the latest commit for that working directory.

True

That’s correct.  Whenever a change occurs for a commit, the single hashed ID will update to be the latest commit for that working directory. 

Previously you learned about
the hidden folder called dot git. That is located in each project. You know that this folder
is responsible for keeping track of all
changes across the project. How does it know what
branch you’re currently on? Let me explain. It keeps a special pointer called head
which is one of the files inside the dot git folder. This file refers to the current
committee you are viewing. You will now learn how to identify
the current committee you are working on. First, open the dot git folder on your
terminal type cd.git and press enter. Next type cat HEAD and press enter. In kit we only work on
a single branch at a time. This file also exists inside
the dot Git folder under the refs forward slash heads path. Let me show you,
type cd.git and press enter, next type cat forward
slash refs forward slash heads forward slash main press enter. After you entered this command,
a single hashed ID appears, the single hashed ID is a reference for
the current commit. Let’s switch branches to see how the head
is moved to point to a new branch. Typed git checkout testing and press enter next type get branch and
press enter again. This moves the head to point
to the testing branch. Let me explain how this
happens by using a diagram. We have two branches,
the main and testing branch. When you run the check out command, it
moves the head to now point to the testing branch, to check the contents of
the head file inside the dot git folder. You have to enter the last command, type
less dot git slash head and press enter. You can now verify that the head
has changed from main to testing. Now I will demonstrate how git
head works with a simple example. So I am here in the terminal,
to see what branch I am in. I am running get branch when
pressing the enter key, I can see I’m on the main branch to
confirm that I run the cat dot git forward slash head command and
press enter. That brings me back to the reference
to where it actually points to, namely; ref ,refs forward slash
heads forward slash main. In this case you can see the references
pointing to the heads main. If I change my branch to feature
testing branches above I use the git checkout command. Get checkout feature forward
slash testing branches. I then go to my head file inside
the git folder by typing cat dot get forward slash head. The ref is now pointing to the feature
testing branches namely: wraps forward slash head forward slash
feature forward slash testing branches. Notice that my branch is up to date
with origin forward slash feature forward slash testing branches. I’ll go back into my main branch by
typing git checkout main and then check the reference file inside the main
directory using the cat command again. Cat dot git forward slash refs forward
slash heads forward slash main. When I press enter I get
a hash ID this is a reference to the latest commits of
that working directory. I can show you that if you make a change
to any files within this directory that this ID. Will then change after
a commit has happened. So let’s do a simple update
to the read me file. You can do this with any
editor such as VS code or I can also do this by
executing the Vim command. Type Vim read me dot MD and press enter,
went inside the read me file and some text in this case add minor update
to your my first repo line and save it. Then check the ID again. Just to verify type cat
dot git forward slash refs forward slash heads forward slash main and
enter. If you would like to
learn more about them. There is a link to an additional
reading at the end of this lesson. The ID should be the same because
we haven’t committed anything. We’ve just made a change
to run the cat command. Therefore the ID is exactly
the same as before. If I do a get status, it is telling me
that I have modified the read me file, on the screen the words modified
read me dot MD displays in red. I’ll now add that file. The shorthand to add a single
file is get add space dot type the command and press the enter key. I am then going to do a commit
type git commit dash M for message by adding minor update to
the command line and press enter. The data confirms that one file changed. There was one insertion and one deletion. I am using the cat command to verify
what is in the reference file by typing cat dot git forward slash refs forward
slash heads forward slash main. Press the enter key to confirm
that the idea has changed. Originally the ID started
with an eight B55 and now it starts with 9 C90. Whenever a change occurs for
a commit this ID will then update to be the latest commit for
that working directory. And that’s get head. You now know what the purpose of head is. You can also change the head to
point to a different branch.

You have returned to development of your hotel booking app after some time away, and want to see the last changes you made. At which levels can you compare the differences between versions using Git diff?

Choose all that apply:

Branches, Commits, Individual files

That’s correct! Individual files, branches, and commits can all be compared with Git diff.

Great novels are rarely
written in one go and usually endure several drafts before the author is satisfied
with the outcome. Of course, there’s always
the possibility that an idea from an earlier draft will sound good again later. But without a system
of organization, it can be difficult to find
where this idea is located. Programming is no different and sometimes you need
to revisit old code. In this video, I’ll guide you through how to use git diff to compare changes across your
files branches and commits. You probably know that
the git status command tells you which of your
files have been changed. The git diff command
it goes a step further and tells you what
exactly these changes are. When used together, you can think of them as a file system. Git status tells
you the file names, but to open the file
and see the contents, you’ll need to use git diff. To demonstrate
let’s say you have a text file named CITIES.txt, which contains the names
of cities you visited. You’ve been updating the list during a tour of South America, but upon returning home, you’ve lost track of what you’ve recorded. What can you do? Well, this is a situation where git diff makes itself useful. Git diff will compare
the previous version of the file with your current
one to find any differences. It will then tell you specifically
what content has been removed as well as what content has been
added to the file. In your CITIES.txt file, git diff would tell you that you removed one city that was in version A and then added a new one that
appears in version B. Now that you’ve had
a basic explanation, Let’s go into a more
detailed example. In this video, I’ll show you
how you can use git diff. Diff is used to make comparisons against files on your
local repository. It can also be used against
commits and against branches. I’ll start with a
simple example. When I go into my
local repository, I’ll find a file called READ ME that I’d like to
update slightly. You can do this with any
editor such as VS code. I can also do this by executing the Vim command to enter
the file for editing, remove a few words, and then save it. If you would like to
learn more about Vim, there is a link to an
additional reading at the end of this lesson. Next, I’m going to use the git diff tool to compare the updated file
against the head. Because we haven’t yet
completed a commit. It’s not available
for a comparison against another commit. I’ll input git diff passing
the head as the first option, and then finally the file name. This then returns
an output showing the changes that
occurred in each file. Here, the line starting with a minus symbol represents
what it originally was. While the line with a plus
symbol shows what it is now. My example tells
me that the words minor update have been removed. In addition to individual files, you can also make comparisons
against previous commits. I’ll start by using the git log command to display
my history of commits. I’ll also use the
pretty flag here so that each one is
shown in one line. The pretty flag is used by developers to make the
output more readable. Each commit has its own ID code. So I’ll perform a git
diff command on the codes from the most recent commit
and from the very first one. Git hub will go
through all the files, note all the changes
that have occurred, and return the differentiation
between the two. Finally, one more way of
using git diff that I’ll show you is how to use it for making comparisons
against branches. If I perform the
command git branch, it will display all the branches that are available
in the repository. I can then use the
git diff command to pass in my main branch, followed by my feature
branch as the second option. Once again, this will display all the changes that have
occurred between the two. This shows that
my feature branch has the previous update, while the main branch
has the most recent one. These are a few examples of
how you can use git diff. In this video, you’ve
learned how to use git diff command to keep track of changes across your files, branches
and commits. This tool can help
you to stay on top of updates and avoid
mistakes or overlap. See you next time.

Git Blame: Tracking Changes in Your Code

Ever wondered who made a specific change to your code and when? Or maybe you’re curious about the history of a particular file? Look no further than git blame, a powerful Git command that helps you track changes in your codebase.

What is Git Blame?

Git blame allows you to examine individual lines of code within a file and see:

• Who: The author who made the change.
• When: The date and time the change was committed.
• What: The specific code that was added, modified, or removed.

This information is invaluable for:

• Identifying the person responsible for a specific change. This can be helpful when debugging issues, understanding code ownership, or attributing contributions.
• Gaining insights into the evolution of your codebase. By examining the history of changes, you can see how the code has been modified over time and understand the reasoning behind those changes.

Using Git Blame:

1. Navigate to your Git repository.
2. Open a terminal window.
3. Run the following command, replacing filename with the actual file you want to examine:

git blame filename

This will display a detailed log for each line of code in the specified file. Here’s how to interpret the output:

• Commit Hash: A unique identifier for the commit that introduced the change.
• Author: The name of the developer who made the change.
• Date/Time: When the change was committed.
• Line Number: The specific line of code that was modified.
• Code: The actual change made to the code (added, modified, or removed).

Additional Tips:

• Limit the output to specific lines: Use the -n flag followed by the line number to focus on a specific line. For example, git blame -n 10 filename will show the blame information only for line 10.
• Specify a line range: Use the -L flag followed by starting and ending line numbers to examine a specific range. For example, git blame -L 5,15 filename will show the blame information for lines 5 to 15.
• View detailed commit information: Copy the commit hash from the blame output and run git log -p <commit_hash> to see the entire commit message and changes introduced in that specific commit.

Remember:

• Git blame shows who last modified each line, not who originally wrote it.
• For larger files, the blame output can be overwhelming. Utilize filtering options or scroll through the information selectively.

By mastering git blame, you’ll gain a deeper understanding of your codebase, improve collaboration with other developers, and effectively navigate the history and evolution of your project.

You are a team leader at a software development company. You run the git blame command to see the changes on all the files for the week. What is the order in which the change information will display in each line?

<ID><Author><Date><Time><Line number><Content>

That’s correct! The order in which the change information will display in each line as follows: < ID><Author><Date><Time><Line number><Content>

One day you might be overseeing
a big team of developers. Can you imagine how
complex it gets to keep track of everyone to changes
and updates to files? Fortunately, git has a
very helpful command for keeping track of
who did what and when. It’s called git blame. In this video, you will
learn about git blame and I will demonstrate how it is
used with a few examples. One of the core functions of git is its ability to track and record the full
history of changes for every file in
the repository. In order to view and
verify those changes, git provides a set of
tools to allow users to step through the
history and view the edits made to each file. The git blame command
is used to look at changes of a specific
file and show the dates, times, and users who
made the changes. By now, you should
know how to use commands like git log to
see the changes made. I will now use the feature.js file to demonstrate
how git blame works. Let’s get started with
the git blame command. To run the git blame command, type git blame and
the name of the file. In this case, feature.js. After pressing Enter, git returns a list of
all changes on the file. To understand what is happening, let’s break down
the blame messages and go through it line by line. Firstly, let me guide you through the format of each line. Every line will start with
the ID and then the author, the date and time when
the change was made, and the exact line number
where the change occurred. Then the actual change or
content is also returned. The ID is a reference
ID of the commit. The same ID might appear
in several lines. This happens when
a single commit has been made by
the same developer. The author is the person
who created the commit. The timestamp is the date and time when the
changes were committed. Line number represents
the location in the file or the exact line
where the changes were made. The content is the code
that was added to the file. Now that you know the meaning of each line in the blame output, let’s explore a real example. In this example, you will
check who made changes, when the changes were made, and also what
changes were added. For the purposes
of demonstration, I will be using a public
repository called MK docs. MK docs has various
different contributions from many different developers, so it’s a good way
to see a log file from all the changes
of specific files. To begin, I will check inside the directory by using
the ls command and passing in -l to get a list of all the available files
and I’ll just pick one. The file I will use
is called setup.py, which is a Python file. In order to examine the
different changes to that file, I create a command called git blame and then pass
in the name of the file, setup.py and press Enter. The output will list all the changes made by all
the different developers. It will also indicate the
timestamps and line numbers, as well as the actual
changes that were made. Now, I will talk you
through the output. Starting from the
left of the list is what’s called a hash dash ID. It just represents the commit
of when a change occurred, then the name of the developer who worked on the
file is listed, and then you have the timestamp
when the change went in. Next is the line number
in sequential order. Finally, the actual change
that was implemented. I can scroll through the list of changes all the way to
the end of the file, depending on the
size of the file or whatever number
of lines it has. If I want to exit
out, I click on Q. This will clear the
screen to make it easier. Take note that git
blame on its own and bypassing the filename
will list the entire file. In a lot of cases, you will work with very large
files and then you need a way to abbreviate the output
or chop it down based on, say, line numbers. Fortunately, git blame
offers a flag for that. To do this, I type git
blame and pass in the flag of -l and specify the starting line number
and the end line number. I will type 5, 15. Then pass in the
file name again, setup.py, and press Enter. This time, a smaller
subset is returned that only starts at line 5
and ends on line 15. The output indicates
that there are four different changes made by five different developers
across these lines. Let me give you a few more
tips around git blame now. Firstly, you can change the format of how the
list is displayed. This is similar to
what you can do with the ls command on
the Unix commands. You can also pass in a -l flag for changing
the output itself. Again, let’s run git blame -l, followed by the filename,
and press Enter. This time, there are a few
changes to the output. For instance, the hash dash ID is in its full length form. It’s not in the
shortened version. The output is now a
bit more detailed. You can also control
if you want to show email addresses or
change the date format. These are the examples of the various things
that you can do. Secondly, another aspect of using git blame
is that you can see detail changes or the
actual commit changes of a specific hash dash ID. To do that, I will run a git
blame command on that file again in order to copy a hash
dash ID from the output. Now, I will use that with a git log -p and pass in the hash dash ID
and press Enter. This gives you the actual
change that occurred. Just to clarify, git blame will display to you the
point where it was changed, git log will give you the
detail of the change. I always use the two
in conjunction to get more details about
what changes occurred.

You’ve reached the final video in this
lesson on creating a repository with forking and the end of the Git module. Let’s take a few moments to
recap on what you’ve learned. You now know how to explain
the principles of get and utilize a GitHub repository including
branching and merging code, perform a local install of GIT
on a Windows operating system, create a new repository in GitHub and
clone it to a local machine. Explain the fundamentals of Git and
outline the Git workflow and identify the differences between remote
and local repositories in GitHub. Explain what they get add and
commit commands do and describe how they work push content to
remote repositories with Git push and retrieve content from remote
servers using Git pull. Keep lines in your workflow, clear and
stable with the use of branches. And explain how head is used in Git to
identify the current branch you’re working on, compare changes across files, commits
and branches using diff commands, examine changes to files and identify their
author with the use of blame commands. And create a repository
with the use of forking. You’re now familiar with GitHub and
creating repositories with forking. Great work.