WORKSHOP STRUCTURE

● WHAT IS GIT AND GITHUB

● INSTALLATION AND SETUP
● INITIALIZING GIT
● BRANCHING AND MERGING
● MORE ABOUT GITHUB
● MERGE CONFLICTS
● GITHUB DESKTOP
● GITHUB ACTIONS

INTRODUCTION
 Git is a Version Control System. Now, what's a VCS?
It is a system that tracks changes made in any set of files, usually
used for coordinating work among programmers.

Git shows what changes were made, when and by whom to a project.

INTRODUCTION
GitHub is an online software development
assistance and version control service.

It is a cloud-based hosting service that lets

you manage Git repositories.

INTRODUCTION
GITHUB
MORE ABOUT GITHUB
1. GITHUB is not GIT. Both are different
Things.

1. Git is a VCS or Version Control System

which tracks of code changes over a period
of time.

1. While, Github is a hosting platform service

layered over GIT (i.e., uses GIT) for tracking
the code changes but on cloud.

Git and GitHub are not the Same !!

Creating GitHub account
 What Is a repository?

A repository contains all of your project's files and

each file's revision history. You can discuss and
manage your project's work within the repository.

Features Of GitHuB…
1. Creating your first repository.

1. Type a short, memorable name for

your repository. For example,
"hello-world".

CREATING A GITHUB REPO…

 3. Optionally, add a description
of your repository. For example,
"My first repository on GitHub."

4. Choose a repository visibility.

CREATING A GITHUB REPO…

5. Select Initialize this repository
with a README.

6. Click Create repository.

CREATING A GITHUB REPO…

● The main idea about remote repo is that you can collaborate
to other users, more backup safety, etc.

● As a starting point you can create a Github Account.

● Get yourself familiarise by exploring

some of its features.

WORKING WITH REMOTE REPOSITORIES

 ● Go to your project folder(where you have git initialised)
● Add your github repo link as remote for pushing files to
github repo
● By convention the name of the remote normally should be
“origin” (Although you can name it anything)
● Type the command: “git remote add origin <your github url>”
● Now to push all your commits to the repo type:
“git push -u origin <your branch name>”

ADDING FILES TO REMOTE REPO

● The most important part of a git repository is a README.md
file
● This file summarises about the project and helps other user to
understand about your code
● .md refers to Markdown File
● Some basics of Markdown:
# Text -> Main Heading Level
## Text -> 2nd Heading Level
Google for detail cheatsheet

README
 Starring and Following:
a. You can star the repositories you find interesting; so you may come
back to them later for contributing or just using them in
your own projects.
a. Follow the people whose progress and activity you want to follow on
GitHub. You will see the repos they starred, people they followed and
you get to learn a lot.

GITHUB IS THE SOCIAL NETWORK FOR CODERS!

MORE ABOUT GITHUB

 GitHub Profile README:
a. It is a special README file that shows whenever someone opens your
GitHub profile.
b. An awesome place to tell people about yourself, your interests,
projects and just basically leave an impression onto the visitor.
c. Can include a variety of stuff like Badges, Stats, various cards like
your latest blogs, the songs you listen to, your email-id and other cool
things to show-off!

MORE ABOUT GITHUB

 How to create Profile README?
a. Create a repository with the exact same name as your GitHub
Username. Eg: grgkaran03
b. Then create a README.md file inside that repo and start editing it
in GitHub itself.
c. https://rahuldkjain.github.io/gh-profile-readme-generator/ to create
beautiful README’s very quickly. Then edit as per your likings.
THE README IS YOUR CANVAS!!

MORE ABOUT GITHUB

 Cool things to add to Profile README!
a. Add your Medium blogs:
https://github.com/bxcodec/github-readme-medium-recent-article/

b. Show your music taste: https://github.com/kittinan/spotify-github-profile

c. Flex your GitHub stats (my favourite part about Profile README ;)
): https://github.com/anuraghazra/github-readme-stats

d. Many more cool stuff to add (emojis, GIFs, skill badges, social media
handles):
https://towardsdatascience.com/build-a-stunning-readme-for-your-github-profile-9b80434fe5d7/

MORE ABOUT GITHUB

Contribution guidelines

● Don’t commit code as an unrecognized author.

● Define code owners for faster code reviews.

● Keep branches up to date.

● Enable security alerts.

MORE ABOUT GITHUB

Licensing
● APACHE
Permissions-commercial use,modification,distribution,patent use,private use
Limitations-trademark use,liability,warranty

● MIT
Permissions-Commercial use,Modification,Distribution, Private use
Limitations-liability,warranty

● GNU
Permissions-commercial use,modification,distribution,patent use,private use
Limitations-liability,warranty

MORE ABOUT GITHUB

 Collaborating with GitHub

To collaborate with multiple people working on the same project, there are two
major options:

1. Add COLLABORATORS (If you are the owner of the repo)

1. Fork + Pull Request (If you want to someone else’s repo)

MORE ABOUT GITHUB

 1. As the owner of a repo you:

- add people as collaborators

- each collaborator can read/write files in the repo

- each collaborator is adding files and other content → making

branches → and either directly merging changes in or via pull
requests

YOU ADD COLLABORATORS IF THEY ARE A CORE PART OF THE

TEAM!

MORE ABOUT GITHUB

MORE ABOUT GITHUB
MORE ABOUT GITHUB
2. If you don’t own a repo/ not an official contributor:
a. You will FORK a repo.
b. Work and make changes on the forked copy of the repo.
c. Make a PULL REQUEST in order to make your changes accepted into
the original repo.
d. The owner of the original repo will check if your changes are helpful -
and MERGE them in!

YAY YOU NOW HAVE SOME COOL INTERNET FRIENDS!

MORE ABOUT GITHUB

To fork and clone a repository
a. Open a repository.
b. Click on Fork button.
c. Click on Create Fork.
d. Open the forked repo, click on Code and copy the url.
e. Open git bash and type: git clone <your-remote-git-repo-url>
f. Type: cd <filename>
g. Type: git remote add upstream <your-remote-git-repo-url>

FORKING AND CLONING

Difference between Fork and Clone
To create a pull request
a. Open the source repository.
b. Click on Contribute.
c. Click on Open Pull Request.
d. Type a comment and then click Pull Request.

CREATE A PULL REQUEST

Git Merge Conflicts
And how to resolve them
A merge conflict is an event that occurs when Git cannot automatically
resolve the differences between two commit.

What are merge conflicts?

Conflicts generally arise when

● Two people have changed the same line in the

same file.
● If a person deleted the file whilst other person
was modifying it
● There are changes in either the working directory
or staging area.

In these cases, Git cannot automatically determine

which of the changes to keep and which to discard.

When do they occur…

➔ Git fails to start the merge (Changes in working directory)

A merge will fail to start when Git sees there When this happens, it is not because of
are changes in either the working directory or conflicts with other developers’, but conflicts
staging area of the current project. with pending local changes.

Git fails to start the merge because these To solve this type of conflict, the changes
pending changes could be written over by the made need to be either committed or
commits that are being merged in. discarded, which can be done using git
stash, git checkout, git commit or
git reset.

Types of merge conflicts

➔ Git fails during the merge (Changes in staging area)

A failure DURING a merge indicates a conflict Git will do its best to merge the files but will
between the current local branch and the leave things for you to resolve manually in
branch being merged. the conflicted files

This indicates a conflict with another Let us see how it happens and resolve it
developers code.

Types of merge conflicts

● We will start this module by downloading Git Bash, from the official website
(https://git-scm.com/), and follow along for installation.
● Launch the Git Bash setup. The very first page contains the important info regarding
the licenses and term & conditions. After reading it click on the next button.
● The next page consists of the components that needs to be installed. Please confirm
that the check box regarding Additional icons has been marked for it to create a
Desktop shortcut.
● The next page contain the info about the Default editor (eg. VS Code, Sublime
Text, Vim etc.)that we want to set for Git and in which you are comfortable.
● The next page consist of the info about adjusting the name of the initial branch
in new repository. Let it to be the default option i.e “let git decide”. Click on next.

INSTALLATION
.
● After that it contains the info about the adjustment of Path environment. Keep
this to be the recommended option (i.e Git from the command line and also from
3rd-party software). Click on next.
● In the next page choose the Use the OpenSSL Library option(default option)
and click on next.
● In the next page choose the option (Checkout Windows-style, commit Unix-style
line endings) and click on next.
● Again click on next after checking Use MinTTY option. For all further pages stick
with the default options, hence click on next till you reach Installation option. Get
it installed and click on Finish.

--- We have Successfully Installed GIT BASH---

INSTALLATION
● Go to Git official site and head over to downloads section for macOS
● Either use the homebrew method or the package installer →
1. HomeBrew method -
❏ Go to homebrew official site and copy the bash command and paste it in
your terminal and enter to install brew for mac
❏ Now run the command ‘brew install git’ to install git for your mac

2. Package Installer Method

❏ Download the package installer for mac from the Git official site
❏ Run it like a usual application installer on MacOS

Now , you’re all set to push/pull, commit,fork etc with the terminal on mac

Git Installation on MacOS

 Installing CLI tools for Xcode and Homebrew
xcode-select --install

/bin/bash -c "$(curl -fsSL

https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Git Installation on MacOS

 Setting homebrew path and Installing git
○ cd /opt/homebrew/bin/
○ ls
○ PATH=$PATH:/opt/homebrew/bin
○ cd
○ touch .zshrc
○ echo export PATH=$PATH:/opt/homebrew/bin -> .zshrc
○ brew doctor
○ brew install git

Git Installation on MacOS

● Launch the installed Git Bash application and type git config and we will get all
the functions related to git configuration will appear. We can read through them.
● Now type git config --global user.name “Your UserName” and then press enter.
This would configure your Username.
● Now type git config --global user.email “Your email-id” and then press enter.
Now this would configure your email-id.
● Now if we want to check whether our name and email-id has been configured
successfully or not, we can simply type git config user.name and git config
user.email to check our configured name and email respectively.
● If we want to see all the details, type git config --list and all the details would be
available on the screen. After that if we want to get out of that simply press
q-button and that’s all.

----- We are now ready to move ahead with other functions -----

CONFIGURATION
● cd command: Allows you to traverse to other directories.
● pwd: displays present working directory
● mkdir/rmdir command: Allows you to make directory.
● touch command: Allows you to make file.
● Ls command: lists items in a directory
● Mv command: moves one file to another
● Rm command: removes a file

Further Commands will be told in the tutorial ahead.

BASIC BASH COMMANDS AND TOOLS

● Inside your Project Folder type: “git init” to initialize git repository.
● It will make a .git folder inside your Projects folder.
● .git folder is where, all your tracking data goes.
● To check the current status of git repo type: “git status”

Initializing git repo

● The Staging Area is when git starts tracking and saving changes that
occur in files.
● You tell git that I want to track these specific files, then git says okay
and moves them from you Working Tree to the Staging Area and says
“Cool, I know about this file in its entirety.”
● Type: “git add <filename>” (For adding a single file to staging area)
● Type: “git add .” (For adding all the files which you
changed)
(Here . means the current directory)

STAGING AREA
 ● Now, in order to insure if the correct file(s) has been
staged, we use the command:
“git status”
● This command shows you which files are being tracked,
which have been modified but are not being tracked and
which are not being tracked.

CHECKING STATUS
 ● “git show” is a command line utility that is used to view
expanded details on Git objects such as blobs, trees, tags,
and commits
● For example:

git show
 ● There are two ways of viewing history logs:
● “git log” : displays all of the commits in the repository’s
history.
● “git reflog” : displays the record when the tips of branches
and other references were updated.

Viewing Log
● Now comes the committing part.
● If all things are good you may want to
commit changes to release the
new version of your project.
● To do this we will use:
“git commit” command
● Type: “git commit -m <message>”
● Here take care of the message part as it should be concise,
clear and short.

COMMIT CHANGES
● Let’s suppose you want to revert back to last version of the file as
the current version is buggy or you made some serious mistake.
● So first type: “git diff HEAD” (allows you to compare the file
version in your working directory with the file version last
committed in your remote repository)
● To move back to last version ,first check the commit id using the
command:
“git reflog”

REVERTING BACK TO PREVIOUS VERSION

 ● If you want to move back to any other commit made
before simply type
“Git checkout <commit id>”
And you’ll be directed to that
● And now to move back to last version type:
“git revert <commit id>”
And the file will revert back to the last version.

REVERTING BACK TO PREVIOUS VERSION

● Let’s suppose you are developing a webapp which employs various
APIs. For accessing those APIs you will surely be using some Private
Access Keys.
● Let’s say you kept all these API Keys in a file. You surely will not
want git to track that file. Here’s where .gitignore comes into play.
● .gitignore tells git about the files which it should not track.
● Then add the files name (with extension) which you don’t want to
get tracked. And git will not track those files.
● https://github.com/github/.gitignore (because some secrets shall
remain secrets :))

KEEPING YOUR SECRETS PRIVATE (.gitignore)

 Why Branching? Let’s see an example!
Developing a Project through branching:-
Suppose you are working on a project for a client
After this you decide to develop a feature and create a
New branch feature and start working.

Since you had some time left you decided to work on

one more feature names “xyz”. You now show it to client
And he disproves the “feature” but allows the “xyz” .
Now as you used branching you just need to remove the
“feature” branch and merge the “xyz” branch into master.

BRANCHING
Branches give you the freedom to independently work on different modules
(not necessarily though) and merge the modules when you finish developing
them. It might sound a cumbersome process, but git branches are swift to be
created and destroyed. Just a simple command can perform these processes,
and they are very cheap, considering the size they take. Branches in Git help the
team, which are in different parts of the world, work independently on
independent features that would ultimately combine to produce a great project.
Moreover, the branches are very flexible. Using branches does not mean you are
using them for different features.

BRANCHING
Operations in Git Branches
● The git branch Command
○ To list all branch name in the repository
○ Create a branch
■ git branch <branchname>
● The git checkout Command
○ To switch between different branches
■ git checkout <branchname>
● Delete a branch
○ git branch -d <branchname> (will show error if you are on that branch)
○ git branch -D <branchname> (force deletes the branch)

BRANCHING
 Some more Operations in Git Branches
● To clone a specific branch
○ git clone -b <branchname> <repo_url>
● The create + checkout Command
○ git checkout -b <branchname>
● Push to a specific branch
○ git push -u origin <branchname>
● Merging two branches (Note : you should be on the branch in which you
want to merge a specific branch)
○ git merge <branchname> (here branchname is the branch you want to
merge)

BRANCHING
 Why Branching? Let’s see an example!
Imagine you're developing a video game. The main game is what you've been
working on, and it's your core project. You want it to be fun and bug-free.

● Branches: Now, think of branches like creating alternate versions or levels of the
game. Each branch is like a separate version of your game where you can try out
new features or fix specific problems.

● Making Changes on a Branch: Let's say you want to add a new character or a cool
weapon to your game. You wouldn't want to mess up the main game while you're
working on this, right? So, you create a branch, like a copy of your game. On this
branch, you can experiment, make changes, and add new stuff without affecting the
main game.

BRANCHING
 ● Testing and Tweaking: Once you've made the changes on your branch, you can play
and test your game to make sure everything works perfectly. If you're happy with it,
you can then merge, which means you take the changes you made on your branch
and add them to the main game. It's like bringing the new character or weapon you
created into the main game.
● Keeping Things Organized: Branches help you keep your project organized. You can
have one branch for adding new characters, another for fixing bugs, and so on. If
something doesn't work out on a branch, you can delete it without affecting the main
game.
● Collaboration: If you're working with a team on your game, branches also allow each
team member to work on their part independently. They can create their branches,
make changes, and then merge them into the main game when they're ready.

BRANCHING
Creating a Branch
Creating a Branch in Git

● To create a branch in Git, you can follow these steps:

○ Open your terminal or command prompt.
○ Use the command git branch to list all the branches
○ Use the command git branch new_branch
○ Or use the command git checkout -b branch-name to simultaneously create and switch to the new
branch.
○

Branch Naming Best Practices

● Keep these branch naming best practices in mind:

○ For feature branches: feature/feature-name
○ For bug fix branches: bugfix/bug-description
○ Avoid using generic names like "branch1" or "temp."

BRANCHING
Switching between branches
Creating a Branch in Git

● Switching in Git:
○ To switch between branches in Git, it's as simple as changing channels on your TV.
○ Just use git checkout <branch-name> to switch to the branch you want.

● Safety First:
○ Remember to save your work before switching, just like saving your game progress.
○ This helps avoid conflicts and keeps everything smooth.

BRANCHING
Making changes
Making Changes in Git

● In Git, making changes is a structured process:

○ Utilize the git add . command to stage your changes, preparing them for commit.
○ Finally, commit your changes using git commit -m “some message” to securely record
them in the repository's history.

BRANCHING
Merging changes
Making Changes in Git

● You can merge your changes into other branches (main) using the git merge main
command followed by the branch name.

BRANCHING
Deleting branches
● git branch -d <branch>:
○ Use this command to delete the specified branch.
○ It's a safe operation because Git prevents you from deleting the branch if it has unmerged changes (changes that
haven't been incorporated into other branches yet).
○ Ideal for cleaning up branches that have already been merged into the main branch.

● git branch -D <branch>:

○ This command forcefully deletes the specified branch, regardless of whether it has unmerged changes or not.
○ It's the command to use when you want to permanently discard all the commits associated with a particular line of
development.
○ Be cautious with this command, as it can result in data loss if you have unmerged changes. Use it only when you are
sure you no longer need the branch.

BRANCHING
Best practices
1. Use Descriptive Branch Names:
2. Branch from a Stable Base:
3. Frequent Commits:
4. Testing:
5. Branch Cleanup:
6. Documentation:
7. Communication:
8. Use Version Tags:

BRANCHING
Key Takeaways
● Use git branch to list all branches.
● Create and switch to a new branch with git checkout -b <branch name>.
● Switch between branches using git checkout <branch-name> (or git switch
<branch-name>).
● In Git, make edits to files in the working directory, stage changes with git add ., and commit with
git commit.
● Merge changes from another branch into the current branch with git merge <other branch>.
● The final step in integrating changes into the main codebase is to merge pull requests using git
merge main.
● git branch -m <branch> Rename the current branch to ＜branch＞.
● git branch -a List all remote branches.

BRANCHING
 ● So, branching is like creating different versions of your game to experiment
with new features or fixes while keeping your main game safe and
improving it step by step. It's a smart way to develop and collaborate on
bigger projects!

BRANCHING
Pushing
Pushing

Pushing changes to GitHub is like showing your latest drawings to your friends. Here's how it works:

● First, double-check that you're in the right place (the right branch). You wouldn't want to show your math homework to your art
class!
● Then, use the git push command. It's like pressing a button that sends your drawings to a special folder on the internet
where your friends can see them, just like putting your artwork in a gallery for everyone to enjoy.

BRANCHING
Pull Request
Creating a Pull Request on GitHub

● To create a pull request on GitHub, it's like sending an invitation:

○ Go to your repository.
○ Click "Pull Requests."
○ Then, hit "New Pull Request."
○ Select the branches you want to compare, and you're good to go!

Pull Request Details

● When making a pull request, remember to add some important info:

○ Write a clear title and description, like sending a clear message.
○ Choose who will check your changes (reviewers).
○ If needed, use labels or milestones for better organization.

BRANCHING
Merging Pull Request
Merging Pull Requests

● Once your pull request gets the green light:

○ It can be added to the main project.
○ You have options, like keeping your changes separate or mixing them in. It's like choosing how you want to add
ingredients to a recipe!

Merging a Pull Request on GitHub

● To merge a pull request on GitHub:

○ Navigate to the pull request.
○ Ensure that all checks pass, and the pull request has been reviewed and approved.
○ Click the "Merge" button and select your preferred merging method.

BRANCHING
 Some more Operations in Git Branches
● To clone a specific branch
○ git clone -b <branchname> <repo_url>
● The create + checkout Command
○ git checkout -b <branchname>
● Push to a specific branch
○ git push -u origin <branchname>
● Merging two branches (Note : you should be on the branch in which you
want to merge a specific branch)
○ git merge <branchname> (here branchname is the branch you want to
merge)

BRANCHING
 $ mkdir git_live
$ cd git_live
$ git init
$ nano
Type the following basic html code
<body style="background-color:red" ></body
Ctrl+x Y file_name.html
$ git add .
$ git commit -m “initial commit”

Branching
$ git checkout -b blueBG
$ git checkout -b greenBG
$ git branch
$ nano file_name.html
<body style="background-color:green" ></body
Ctrl+x Y file_name.html

BRANCHING
 Branching
$ git checkout -b blueBG
$ git checkout -b greenBG
$ git branch
$ nano file_name.html
<body style="background-color:green" ></body
Ctrl+x Y file_name.html
RELOAD
$ git add .
$ git commit -m “greenbg added”

$ git checkout blueBG

$ nano file_name.html
<body style="background-color:blue" ></body
Ctrl+x Y file_name.html
RELOAD
$ git add .
$ git commit -m “bluebg added”

BRANCHING
 DELETING A BRANCH
$ git branch
$ git branch -d greenBG
$ git branch

MERGING
$ git checkout master
$ git merge blueBG
RELOAD
$ git branch -d blueBG
$ git branch

BRANCHING
 What is a Git merge conflict?
● A merge conflict is an event that occurs when Git is unable to automatically
resolve differences in code between two commits.

● When all the changes in the code occur on different lines or in different files,
Git will successfully merge commits without your help.

● However, when there are conflicting changes on the same lines, a “merge
conflict” occurs because Git doesn’t know which code to keep and which to
discard.

MERGE CONFLICT
 Conflict Markers
<<<<<<< HEAD

//conflict in current branch

=======

//conflict in merging branch

>>>>>>> “Branch Name”

What do we have here…

Resolving through command line is done on local repository, and then pushed
to remote repository.

● You can either save the changes from both the files by just removing the
conflict markers i.e “<<<<<<< HEAD”, “=======” and “>>>>>>> “Branch
Name””
● Or save either of the change by just keeping the content within the either
pair of conflict markers i.e. “<<<<<<< HEAD” and “=======” or
“=======” and “>>>>>>> “Branch Name””

Resolve using command line

 You can resolve simple merge conflicts
that involve competing line changes on
GitHub, using the conflict editor.

For more complex conflicts, you’ll have to

resolve them locally and then push to
remote

Resolving on GitHub
So, How do we exactly
do this on GitHub?
 ● Frequently Pull/Push code to the mainline branch, which makes it less
likely to have conflicts and they’ll be smaller when they happen
● Make devs work on independent parts of the code.
● Frequent Communication with your fellow team mates

Some tips to avoid/minimize merge conflicts

 Portfolio website using GitHub Pages:
a. You get your own domain to host your personal website with your
GitHub account. All for free!
b. Very easy to deploy and it supports everything from basic HTML,
CSS based websites to full-fledged React Apps.
c. You have your own personal website that re-deploys whenever you
make any changes in the code and push it to the repo. No hassles!

MORE ABOUT GITHUB

Create personal website on GitHub Pages:
a. Create a repository with the name: [Your Git User Name].github.io. For ex:
grgkaran03.github.io
b. Download a template for your website and make changes to it or push your
own files to the above repository. (The entire process of cloning, committing and
pushing to remote origin has been shown earlier in the workshop!).
c. As soon as you push, you will be able to see the deployment in a few minutes.
Also you can deploy your own projects as well, for ex:
https://grgkaran03.github.io/. Just push your React repository to GitHub and then go to
settings and deploy it at your preferred domain-name. Make sure to make a production build
of the app and push it to the repo on GitHub. More on this:
https://github.com/gitname/react-gh-pages/

MORE ABOUT GITHUB

 ● Provides 100+ apps and softwares and various developer tools for
free.

● Learning tools and courses can be availed for free.

● Bundles to conduct your own events like hackathons, codefests.

● Discover Virtual Events and Online Talks.

GitHub Student Developer Pack…

GitHub Student Developer Pack…
Features of GitHub Desktop
1. Repository Management:
○ Create new Git repositories.
○ Clone existing repositories from GitHub or other Git hosting services.
2. Branching and Merging:
○ Create and manage branches for different features or bug fixes.
○ Easily switch between branches.
○ Visual merge and conflict resolution tools.
3. Commit and History:
○ Make commits with clear commit messages.
○ Visual commit history graph.
4. Synchronization:
○ Push changes from your local repository to the remote repository on GitHub.
○ Pull changes from the remote repository to your local copy.
5. Pull Requests:
○ Create and manage pull requests for code review and collaboration.
○ Comment on pull requests.
○ Merge pull requests directly from the app.
Installation
1. Download GitHub Desktop:
○ Go to the official GitHub Desktop website: https://desktop.github.com/
2. Choose Your Operating System:
○ GitHub Desktop is available for both Windows and macOS. Click on the appropriate download button for your
operating system.
3. Download and Run the Installer:
○ For Windows: After downloading the installer, run the .exe file and follow the installation wizard's instructions.
○ For macOS: After downloading the installer, open the .dmg file, drag the GitHub Desktop icon to your Applications
folder, and then launch the application from your Applications folder.
4. Log in to Your GitHub Account:
○ When you first launch GitHub Desktop, you'll be prompted to log in to your GitHub account. If you don't have a
GitHub account, you can sign up for one.
5. Configure Git:
○ If Git is not already installed on your system, GitHub Desktop will guide you through the installation process. Follow
the prompts to set up Git on your computer.
6. Choose Default Text Editor:
○ GitHub Desktop will ask you to choose a default text editor for working with code files. You can select your preferred
text editor from the list or choose to set it up later.
7. Repository Setup:
○ After completing the initial setup, you can either clone an existing repository from GitHub or create a new one using
GitHub Desktop.
8. Start Using GitHub Desktop:
○ Once everything is set up, you can start using GitHub Desktop to manage your Git repositories, create branches, make
commits, push changes to GitHub, and more.
Cloning a repository through URL and
Desktop
1. Access the "File" Menu:
○ In the top menu bar (Windows) or the menu bar at the top of the screen (macOS), click on the "File" menu.
2. Choose "Clone Repository":
○ From the "File" menu, select "Clone Repository." This action will open the "Clone a Repository" dialog.
3. Select a Repository to Clone:
○ In the "Clone a Repository" dialog, you have a few options:
■ URL: You can enter the URL of the GitHub repository you want to clone.
■ GitHub.com: You can select a repository from your GitHub account by clicking on "GitHub.com" and browsing your repositories.
■ GitHub Enterprise: If your organization uses GitHub Enterprise, you can select it and enter the URL of your enterprise's GitHub
instance.
4. Choose the Local Path:
○ Specify the local directory where you want to clone the repository. This is the folder on your computer where the repository will be stored.
5. Optional: Choose Branch or Commit:
○ You can choose the branch or commit you want to clone. By default, GitHub Desktop will clone the default branch (usually "main" or
"master").
6. Click "Clone":
○ Once you've selected the repository and specified the local path, click the "Clone" button. GitHub Desktop will initiate the cloning
process.
7. Wait for Cloning to Complete:
○ GitHub Desktop will download the repository and set it up on your local machine. Depending on the size of the repository and your
internet connection, this may take some time. You'll see a progress bar indicating the cloning progress.
8. Open the Repository:
○ Once the cloning is complete, you can choose to open the repository immediately by checking the "Open this repository" option
Pushing Changes in Github desktop
1. Select the Repository:
○ In the left sidebar of GitHub Desktop, select the repository for which you want to push changes. Click on the repository name to make it active.
2. View Uncommitted Changes:
○ In the main area of GitHub Desktop, you will see a list of uncommitted changes. These are the changes you've made to the files in your local repository.
3. Commit Your Changes:
○ Before you can push your changes, you need to commit them. To do this, enter a commit message in the "Summary" field. This message should briefly
describe the changes you made in this commit. You can also provide a more detailed description if needed in the "Description" field.
4. Optional: Review Changes:
○ You can review the changes you're about to commit by clicking on the "Changes" tab. This will show you a side-by-side comparison of the changes in your
files.
5. Click "Commit to main" or "Commit to [Branch Name]":
○ Below the commit message fields, you'll see a button that says "Commit to main" or "Commit to [Branch Name]." Click this button to commit your changes.
The branch name may vary depending on the active branch.
6. Push Your Changes:
○ After committing your changes, you'll see a button labeled "Push origin." Click this button to push your commits to the remote repository on GitHub.
7. Authentication:
○ If you're not already authenticated with GitHub, GitHub Desktop will prompt you to log in or provide your credentials at this point. This is necessary to
ensure you have permission to push changes to the repository.
8. Wait for the Push to Complete:
○ GitHub Desktop will initiate the push to the remote repository. The progress will be displayed, and you may need to wait for it to complete.
9. Confirmation:
○ Once the push is successful, you'll receive a confirmation message indicating that the changes have been pushed to GitHub.
 Introduction
GitHub Actions allows you to automated your build, test, and deployment
pipeline. You can create workflows that build and test every pull
request to your repository, or deploy merged pull requests to production.

GitHub Actions
Workflows
A workflow is a configurable automated process that will run one or more jobs.
Eg: You can have a workflow that adds a label every time someone opens a new issue
A repository can have multiple workflows, each of which can perform a different set of tasks.

- Triggering a workflow
Workflow triggers are events that cause a workflow to run. These events can be:
● Events that occur in your workflow’s repository
● Events that occur outside of GitHub and trigger a repository_dispatch event on
GitHub
● Scheduled times
● Manual

GitHub Actions
Your workflow contains one or more jobs which can run in sequential order or in parallel.

Each job will run inside its own virtual machine runner, or inside a container, and has one
or more steps that either run a script that you define or run an action.

GitHub Actions
Components of GitHub actions
● Events
A specific activity in a repository that triggers a workflow run.
Eg: Activity can originate from GitHub when someone creates a pull request, opens an issue
or pushes a commit to a repository.

● Jobs
A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell
script that will be executed, or an action that will be run. Steps are executed in order and are
dependent on each other.

● Actions
An action is a custom application for the GitHub Actions platform that performs a complex but
frequently repeated task.

GitHub Actions
 Life Cycle of an Application !

At
 Can we do something to automate
???????
🤔🤔

At
 Introduction to CI/CD
a. What is CI ( Continuous Integration )
b. What is CD ( Continuous Deployment / Continuous Delivery )

At MORE ABOUT GITHUB

At CI/CD
At CI/CD
At HacktoberFest