0% found this document useful (0 votes)
34 views

Git For Scribd

Git is a version control system that tracks changes to files over time. GitHub is a hosting service for Git repositories that allows for remote collaboration. The document discusses Git concepts like branches, commits, staging files, and basic Git commands. It explains how branching allows for parallel development where multiple features can be worked on simultaneously without interfering with each other.

Uploaded by

RonTheHuman
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
34 views

Git For Scribd

Git is a version control system that tracks changes to files over time. GitHub is a hosting service for Git repositories that allows for remote collaboration. The document discusses Git concepts like branches, commits, staging files, and basic Git commands. It explains how branching allows for parallel development where multiple features can be worked on simultaneously without interfering with each other.

Uploaded by

RonTheHuman
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 43

Git Good at GitHub

Me

(The dark souls of


cloud saves)
What We Will Cover
• Git as a version control system
• Git branching
• Remote repositories
• GitHub as a remote repository
• GitHub for large scale collaboration gitar
• Git GUIs
?What is GitHub
Let’s first talk about Git
Git is a software for tracking changes in a set of files (version control system – VCS),
usually used for coordinating work among programmers collaboratively developing a
project.
Git was developed by Linus Torvalds in 2005 to be the VSC used for Linux
development. Until 2005 they used a different software, but when its license stopped
being free they decided to develop one of their own.

~From Git Source Code, README.md


What for?
• Saving and accessing a whole history of a project, in the form of snapshots.
• Creating “branches” for a parallel workflow.
• Uploading and downloading project history online with a server.
Git is used for easily developing multiple things (features, bugs, designs) in a project without one
interfering with the other. This is useful for single developers, and even more so for teams with
many people working at the same time. Git also allows for backup and recovery of old versions of
files, if something turns out to be wrong in the current one.

When files are saved to history a new copy is


generated for every file that changed, but not for
unchanged files.
Setting up Git
Besides the endless “next” pop-ups, its quite
simple.

There are many environments for using Git, the base being a command
line. Its original command line is Bash, but if you download “Git for
Windows”, the same exact commands can be called through cmd. There
are also many Git GUIs, like GitGUI, GitHub Desktop, and GitKraken, which I
will cover later.

*Gui list:https://git-scm.com/downloads/guis
recommend
changing
“master” to
“main

‫זה פשוט ממשיך‬


Creating a repository
First, choose a folder to be your Git repository, navigate to it and type: git init. Any files in that folder or
files added to the folder will be part of the repository (but still untracked).
Working Directory
File States
Untracked
Index History

Modified Staged Committed

Files in git repositories can be in one of three places.


• The working directory – the repository folder, accessible by the user. Any changes, additions or deletions in
the working directory will not affect the project history on their own.
• The index folder – a folder where files to be added to the history are saved. Files in this state are called
staged files.
• The project history – all the staged files are added to a new snapshot, called a commit. Files in this state
are called committed.
To remove redundancy, files that haven’t changed cannot be staged, and an empty staging area cannot be
committed.

So, to add a new snapshot: make changes -> stage them (or some of them) -> commit staged.
Basic Commands
Untracked add

Modified Staged Committed


add commit

• Stage file: git add <filename>


• Stage all changes: git add .

• Commit all staged changes: git commit –m <message>


Each commit must have a message, that should describe what was changed in the commit
• Stage then commit all tracked files: git commit –a –m <message>
will not add untracked files, that needs to be done separately.

• Show states of files in the directory: git status (--short)


Git Config
Git has many options you can use with git config.

Setting username: git config user.name <name>


Setting email: git config user.email <email>
This info will be in every commit and needs to be entered at setup to do any commits. With it, everyone working on
a project can know who made each commit, and how to contact them if needed.

Aliases - custom commands built from existing ones.


Create alias: git config alias.<alias_name> <command>
Used for shortening – git config alias.co checkout or new commands – git config.unstage
“restore --staged”

Text editor - there are cases where git opens a text editor as a part of command. For example, when writing
commits without “-m <message>”, a text editor will open to write the commit message.
Set text editor: - git config core.editor <configuration-command>
For example, git config --global core.editor "code --wait“
list of text editor commands: https://git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Setup-and-Config

Every config can have --local (default, on repo) --global (on user) --system (on machine) added to it.
Git Status Examples
git status after adding new files git status after git add .

git commit command


More Git Status
git status after git add for_loops.py, then
does removing files automatically stage them? editing a different file, and adding a third file.

no, you still need to git add <file>

git status after commiting

git status --short


Git Branches
A Git project history is made out of commits - different snapshots of the repository. Branches are
pointers to specific commits, and for the user to choose a branch to interact with, Git uses a HEAD
pointer that moves to the commit of the picked branch.

A repository starts with a default branch, usually named master or main, pointing at the latest
commit. New branches can be added with
git branch <branch-name>
this image draws a repository with a master branch, and a testing branch that was added later.

Every commit also has a


pointer to the previous
commit
Switching Branches
Changing between branches is done with
git checkout <branch-name>
this will move HEAD to the branch, and load into the working directory the files in the commit the
branch is pointing to.

Changing to a new branch, committing a change, and coming back to the branch you were originally
on, will not show the committed changes in the files - because the files shown are from a different
commit.
Time Travel?
What happens if you commit a change on branch, then move to a second branch, and commit
another change? You have now created divergent history:

Which commands
were used to get
from one branch
to this state?

branch ->
checkout ->
commit ->
checkout ->
commit

(divergent history appreciation text)


Branch Commands
• Create Branch: git branch <branch-name>
• Rename branch: git branch –m <old-name> <new-name>
• Delete branch: git branch –d <name>
• List all branches (current branch in green): git branch

• Switch to a branch: git checkout (-b) <branch-name>


-b means the command will create a new branch, the switch to it
• Merge into current branch: git merge <branch-name>
• Stop conflicting merge: git merge --abort
Why Branch?
Parallel
Stability Development
Usually work in progress is not committed to the Multiple features can be worked on at the same time
main branch. Instead, it is done in another branch, (by either one or many people) without one breaking
and merged once the code is good and tested. another.
For example, branching from main, devs working on
This gives easy access to the most stable and up-to- a chat program can make separate feature branches
date version of the project. for working on the client, server and ui, as well as
branches for bugfixes.

Of course, features are connected, so a dev branch


can be created to be a middle-man between merging
features and merging a version to main (which is
supposed to be as stable as possible).
Git Merging
The most important feature of branching is merging. Being on a certain branch and typing
git merge <branch-name>
will create a new commit on the current branch, that has the changes made in branch-name added
to the last changes made on the current branch. In other words: merges one branch into the other.

Generally, if the merged changes are additions of files or lines of code, git merge will work cleanly.
However, changes or removals might cause merge conflicts.
Merge Conflicts
Two branches currently on the same commit,
with the python file containing:

On branch main, I commit this change:

And on branch merge_test I commit this:


Resolving Conflicts
The conflicted file now looks like
this in the working directory:

“<<<<<<< HEAD” shows the part of the file in the current branch, and “>>>>>>> merge_test”
shows the part git tried to merge but failed. To complete the merge, you need to resolve the conflict
manually and make a commit.

conflicting merges can be cancelled with


git merge --abort
Git Log
• Print log of project history: git log (--oneline) (--graph) (--all)
without all, prints only current branch history.

Default log Pretty log

log after adding a new branch

When history is long, the console will show the start,


show more by pressing enter, and stop by pressing q.
Basic Undoing
it gets way more complicated if you try to explain everything

Modified Staged Last Commit


restore --staged reset --soft HEAD~1

reset HEAD~1

• Unstage file: git restore --staged <filename>


• Unstage all files: git restore --staged .

• Reset to last commit: git reset (--soft | --hard) HEAD~1


By default, reset puts all changes from the current commit in the working directory. Soft reset puts them in
the staging area, and hard reset completely deletes them (dangerous!)
Commits have many names
• There are three ways to access a commit: by the hash of its content, by HEAD, or by branch name.
• By using <commit>~[n], you can go n commits back from <commit>. (more complicated with merging)
• The hash doesn’t have to be fully written, just enough for a unique match
• This is used by some commands (and is generally good to know if you want to keep studying git). With checkout
<commit> for example, you can load any commit, even if a branch isn’t there.

Where are: (1) HEAD~2, (2) dev, (3) 73102, (4) merge_test~1, (5) 7fd50~2 ?

)2(

)4(

)1(
)5( )3(
Reverting
In order to undo a change made in a commit, without changing the commit history like git reset, there is the command:
git revert <commit>
This creates a new commit on the branch, without the changes made in <commit>. Notice this can be any commit,
even one multiple commits ago.
For example: Then committed another:

Now to revert the name change:


Revert can have conflicts similarly to merge, and they are handled in the same way.
Remote Repositories
A remote repository in git is any other repository than the current one. Remote repositories are how you can collaborate
using Git.

Multiple people connect to the same centralized remote, downloading its history, making changes on their local repository,
then uploading them back to the remote. Everyone works together - committing, making branches, merging etc. It’s
important to update the remote any time you commit to the main branch, so other people can start working from the latest
stable version.

It’s possible to create a custom remote repository using a dedicated server, but people usually use services that provide
them, such as GitHub, GitLab or BitBucket.

Running your own server gives you a lot of control and allows you to run the server within your own firewall, but it requires
more time to set up and maintain. If you use a hosted server it’s easy to set up and maintain, but you have to keep your code
on someone else’s servers, and some organizations don’t allow that.
Remote Repo Commands
• Add a remote repository: git remote add <name> <link>
<name> is how the branch containing snapshots from the remote will be called on your local machine, unrelated to the
name of the remote. It is usually called “origin”.
• Change repository branch name: git remote rename <old-name> <new-name>
• Change repository link: git remote set-url <name> <link>
• list remotes: git remote -v

• Update remote with snapshots from current branch: git push (--all) <remote> (-u) <local-branch>
-u will make <remote> the default remote branch when fetching and pulling with the same branch, making it so you don’t
need to write the names every time.
• Update current branch with snapshots from remote branch: git fetch <remote> (<remote-branch>)
• Update current branch and merge: git pull <remote> (<remote-branch>)
not specifying a remote branch will get all branches.

• Copy a full remote repository to local machine: git clone <link>


Add and Push Examples

Push after using –u, no need to write full command


with -u (while in main)

after
pushing it’s just not the same without u

after making a
commit on local
Fetch, Pull and Clone
Fetch will add the branch changes to the new <remote>/<branch> “branch” but will not merge them with the local
one. To do that you need to manually type:
git merge <remote>/<branch>
from the local branch.

The command:
git pull (-u) <remote> <remote-branch>
on the other hand, will do both fetch and merge automatically.

If you want to download a remote repository you don’t have on your machine at all, use:
git clone <link>
and it will get the full repository history in a folder.
Fetch Example
If someone else pushed to the same remote branch
Then merge.

Now you can push.


log after fetching

pull would have done the fetch and the merge at the
same time
Now... What is GitHub?
GitHub
Github is an online platform for Git, that provides hosting for online remote repositories. Published in 2007
by Tom Preston-Werner, Chris Wanstrath, P. J. Hyett and Scott Chacon, and bought by Microsoft in 2012.

It has all the functionality of Git and remote repositories as described, as well as:
• Online backup
• Collaboration with anyone that wants to contribute, even people outside of the dev team. This is very
apparent in open-source projects.
Setting up GitHub
After creating an account and signing in, you will have the option to open a new repository.
HTTPS/SSH
The HTTPS/SSH button gives you a choice between two ways for GitHub to ensure the machine you
are working on is connected to this account. Only machines connected to an account can directly
push to its remote repositories.

For HTTPS: GitHub will do some automatic magic thing.

The manual steps, in case you want to switch accounts or if something breaks, are:
going to Profile -> Settings -> Developer settings -> Personal Access Tokens. Generate a new token and
save it, then search “Manage Windows Credentials” in windows, find this:

click on it and fill in the username and token.

For SSH: you will need to generate a private and public key (woah). First go to C:\Users\USER\.ssh to
check if you already have a key. If not, run ssh-keygen -t ed25519 -C <email>
which will generate the keys in a folder (.ssh folder by default). Now copy the public key and paste it
in Profile -> Settings -> SSH and GPG keys -> New SSH key.

Pick the corresponding button and use the link on the side as the <link> in git remote add.
HTTPS Example

paste
Sharing a GitHub Repository
Access to a GitHub repository can be given to other GitHub accounts by adding collaborators. They will be
able to push to the repo, but not change settings.

people that actually exist


Forks
How can someone not connected to the repository contribute to a project?

With forking!
When someone forks your GitHub repository, they get a complete copy of it, on their own account. From
here they can manipulate it as if it was their own. If the repository is public, anyone can fork your project.

From one account From another account


after forking
Pull Requests
After making changes to the fork project, the contributor can ask to merge their work on a
certain branch to the same branch on the original repository. This is done with a pull request,
which the owner receives and can manage from there. This is how big projects and open source
projects handle merging.
Collaborator: Owner:
Safe Merging
If a forked branch cannot be merged into the original branch without conflict, GitHub will not let the merge
happen. It will recommend to first merge the original onto the forked, then, after dealing with all the
conflicts, merging the forked into the original as planned.

This workflow is in general a good way to cleanly merge branches and keep main consistently stable.

Divergent history Deal with conflicts with (from feature) git merge main

Merge cleanly with (from main) git merge feature


GitGUI
Comes with the Git for Windows download. Commands in GUI, showing diff in text files.
Github Desktop
Download from GitHub website, similar with GitGui, has direct integration with GitHub. Shows changes in
image files. All changes are automatically staged. Simplistic, good for beginners.
GitKraken
All features of GitHub Desktop and GitGui + many more. Interactive history visualizer, undo and redo,
integration with many services, built in text editor etc.
Thanks for listening!
Bibliography: https://git-scm.com/book/en/v2
https://en.wikipedia.org/wiki/GitHub
https://en.wikipedia.org/wiki/Git

https://git-scm.com/book/en/v2/Git-on-the-Server-Generating-Your-
SSH-Public-Key
StackOverflow

i’m gonna git out of here

You might also like