Understanding Github and Version Control System.pptx

WHAT IS GITHUB?
• Git is a distributed version control system, so each
developer has a copy of the repository on their
local machine.
• A remote repository is a copy of the repository
that is hosted on a server. Developers can
synchronize their local repositories with the
remote repository. GitHub is a popular web-based
Git repository hosting service.
• GitHub offers free public and private repositories.

TO USE GITHUB
To use GitHub, you need to create an account
and create or contribute to repositories.
You can create a remote repository on GitHub by
signing up for a free account and clicking
"Create a repository".

TO USE GITHUB
You can then clone the remote repository to your
local machine using git clone.
This will create a directory on your local
machine that contains a copy of the remote
repository.

TO USE GITHUB
You can make changes to the ﬁles in the local
repository and then stage and commit those
changes.
You can push your changes to the remote repository
using git push.

TO USE GITHUB
There are a few ways to avoid having to enter your
password every time you push or pull changes.
One way is to create an SSH key pair and store the
public key in your GitHub proﬁle.
Another way is to use a credential helper, which
caches your credentials for a time window.
There is a built-in credential helper in Git that can be
enabled using git conﬁg -- global credential.helper
cache.

TO USE GITHUB
git clone https://github.com/username/repo-name.git
Cd repo-name/ ls -l
code README.md
# The code above opens
README.md file on
VsCode # That is for
those using VsCode
editor

TO USE GITHUB
If the repo you clone is private, you likely going to be
required to put username and password everytime you
and pushing or pulling.
To avoid this, the code below would help. It is only going
to ask you just once after running the code.
git config --global credential.helper cache
git pull

WHAT IS A REMOTE?
Remote repositories allow developers to collaborate on a
project from their own machines.
There are several Git hosting services like GitHub,
BitBucket, and GitLab. You can also set up your own
Git server.
When working with remote repositories, developers push
their local commits to a central repository and pull
changes from that repository.

WHAT IS A REMOTE?
Git can automatically merge changes or prompt you to ﬁx
merge conﬂicts.
There are different protocols for connecting to remote
repositories, such as HTTP, HTTPS, and SSH.
HTTP allows read-only access, while HTTPS and SSH
allow for access control. Web services like GitHub
offer mechanisms to control access to repositories.

WORKING WITH REMOTES
By default, Git sets up a remote repository with the name
origin.
You can view information about the remote repository
using git remote -v. This command shows the fetch
and push URLs for the remote.
You can view more information about a remote
repository using git remote show < remote_name>.

cd health-checks/ #change directory to the new repo ypu just cloned
git remote -v
# Code output:
origin https://github.com/redquinoa/health-checks.git
(fetch) origin https://github.com/redquinoa/health-
checks.git (push)
git remote show origin
git branch -r
# Code output:
origin/HEAD -> origin/master
origin/master
Fetching New Changes
The git remote show origin command shows information about the remote
repository.
You can use git fetch to download commits from the remote repository
without merging them into your local branch.
git log origin/master shows the commits in the remote branch.
In [ ]:
In [ ]:
In [ ]:

$ git remote show < name> shows some information about a single remote
repo.
git remote update
$ git remote update fetches updates for remotes or remote groups.
git fetch
$ git fetch can download objects and refs from a single repo, a single URL, or
from several repositories at once.
git branch -r
$ git branch -r lists remote branches and can be combined with other branch
arguments to manage remote branches.
The Pull-Merge-Push Workflow
When you try to push your changes to a remote repository that has been
updated since you pulled, Git may reject your push because your local branch is
not up-to-date.
You can use git pull to fetch the latest changes from the remote repository
and attempt to merge them into your local branch.
If there are conflicts between your local changes and the remote changes, Git
will stop the merge process and you will need to resolve the conflicts manually.

This allows you to isolate your work and make it easier to merge
changes.
To create a new branch and check it out, you can use the git checkout -b
< branch_name> command.
Once you have made changes to your branch, you can commit them using
the
git commit command.
When you are ready to share your branch with your collaborators, you can push
it to the remote repository using the git push -u origin < branch_name>
command.
The -u ﬂ ag tells Git to set the upstream branch for your local branch.
This will allow you to easily pull and push changes from the remote branch.
You can merge branches using either git merge or git rebase.
Rebasing rewrites branch history by replaying your commits on top of a new
base branch.
This can be useful for keeping your commit history linear, but it can also
be dangerous if the branch has already been shared with others.
Rebasing only works if there are no conﬂicts between the branches.
The video shows how to rebase a feature branch onto the master branch and
then merge it in.

The ﬁrst time you push a branch to a remote repository, you need to use the -
u ﬂag to set the upstream branch.
Here are the steps on how to create a git branch for a refactor and push it to the
remote repository:
Create a new branch using git checkout -b < branch_name>.
Make your changes and commit them.
Push the branch to the remote repository using git push -u origin <
branch_name>.
A Simple Pull Request on GitHub
Forking creates a copy of a repository that you can make changes to.
A pull request is a way to suggest changes to a repository.
The pull request can be reviewed by the owner of the repository before being
merged.
Here are the steps on how to create a pull request on GitHub:
1. Fork the repository that you want to make changes to.
2. Make your changes to the code.
3. Create a pull request from your forked repository.
4. Add a description of your changes to the pull request.
5. Submit the pull request.

Create a remote branch that corresponds to your local branch.
Push your changes to the remote branch.
GitHub will tell you if your change can be automatically merged.
Add a description of your changes to the pull request.
Review the diff to make sure it is correct.
Submit the pull request.
The owner of the repository can then review your changes and decide whether or
not to merge them into their repository.
Updating an Existing Pull Request
Here are the steps on how to address comments on a pull request:
Go to the pull request that you want to update.
Read the comments from the project maintainers.
Make the changes that are requested in the comments.
Commit your changes to your local branch.
The new commits will be automatically added to the
pull request.

changes to the remote branch.
Note: Squashing commits rewrites history, so only do this on a branch that
has not been shared with others.
Study guide: Git forks and pull requests
Git forks and pull requests
GitHub is an open-source platform for collaboration and knowledge sharing,
allowing users to explore code created by others. This study guide will provide
you with pointers on effectively using the platform to make pull requests in the
Git environment.
Pull requests
Pull requests allow you to inform fellow contributors about changes that have
been made to a branch in Git. When pulling requests, you can discuss and
evaluate proposed changes before implementing changes to the primary
branch.
You can eventually merge changes back into the main repository (or repo) by
creating a pull request. However, it is important to note that before any
changes are made to the original code, GitHub creates a fork (or a copy of the
project), which allows changes to be committed to the fork copy even if
changes cannot be pushed to the other repo. Anyone can suggest changes
through the inline
comment in pull requests, but the owner only has rights to review and approve
changes before merging them.

Pull request merges
You can merge pull requests by retaining the commits. Below is a list of pull
request merge options that you can use when merging pull requests.
Merge commits. All commits from the feature branch are added to the base
branch in a merge commit using the -- no–ff option.
Squash and merge commits. Multiple commits of a pull request are squashed,
or combined into a single commit, using the fast-forward option. It is
recommended that when merging two branches, pull requests are squashed and
merged to prevent the likelihood of conﬂicts due to redundancy.

skills and contribute to a project.
Code Review
What are code reviews?
Code reviews are a way to improve the quality of code by having other people
review it.
Code reviews can help to catch bugs, improve code style, and make sure that
code is easy to understand.
Code reviews are not about ﬁnding fault with the person who wrote the code, but
about making the code better.
Code reviews can be done in person or using a code review tool.
Some projects require code reviews for all changes, while others only require
them for changes from people who do not have commit access.
Getting feedback from code reviews can help you to improve your coding
skills.
The Code Review Workﬂow
Here are the steps on how a typical code review is done using a code
review tool:

Here are the steps on how to address comments on a pull request:
Go to the pull request that you want to update.
Read the comments from the project maintainers.
Make the changes that are requested in the
comments.
Commit your changes to your local branch.
The new commits will be automatically
added to the pull request.
Some projects may have contribution guidelines that specify how pull requests
should be formatted. You can ﬁnd a link to the contribution guidelines whenever
you create a new pull request or issue in a project. It is important to read these
guidelines and make sure that your pull requests match them.
Managing Collaboration
It is important to keep your colleagues informed about large refactors.
It is important to write clear code with good comments and documentation.
Project maintainers should reply promptly to pull requests.
Project maintainers should understand any changes they accept.
It is a good idea to have a style guide for your project.
Issue trackers are a useful tool for coordinating who does what
and when.

the issue once the code is merged. This can be done by including a string like
"closes:#" in the commit message or pull request description.
Continuous Integration
A CI system will automatically build and test your code every time there's a
change.
This can help to catch errors early in the development process.
CD is the practice of deploying new code to production frequently.
This can help to ensure that new features and bug ﬁxes are available to users as
soon as possible.
There are a number of tools available for setting up CI and CD, such as Jenkins
and Travis.
When setting up CI and CD, it is important to be careful about how you manage
secrets, such as passwords and API tokens.
Terms and deﬁnitions
CI/CD: The name for the entire continuous integration and continuous
deployment system
Code reviews: The deliberate and methodical gathering of other programmers
to examine each other's code for errors to increase the code quality and

Merge commits: All commits from the feature branch are added to the base
branch
Pipelines: The speciﬁc steps that need to run to obtain the desired result
Pull request: A procedure where new code is examined before it is merged to
create a branch or master branch
Squash commits: The decision add commit messages together and an editor
opens to make any necessary changes
This notebook was converted to PDF with
convert.ploomber.io

Understanding Github and Version Control System.pptx

Recommended

More Related Content

Similar to Understanding Github and Version Control System.pptx (20)

Recently uploaded (20)

Understanding Github and Version Control System.pptx