MASTERCLASS - TASK ON GIT AND GITHUB

What’s the difference between Git & Github?

GitHub: GitHub is a web-based Git repository hosting service, which offers all of the distributed revision control and source code management (SCM) functionality of Git as well as adding its own features.

Git: Git is a distributed version control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows.

????????????????????????????????????

What is a repository?

The repository is like a data structure used by VCS to store metadata for a set of files and directories. It contains the collection of the files as well as the history of changes made to those files. Repository in Git is considered as your project folder. A repository has all the project-related data. Distinct projects have distinct repositories.

General workflow?

You clone the Git repository as a working copy.

• You modify the working copy by adding/editing files.
• If necessary, you also update the working copy by taking other developer's changes.
• You review the changes before commit.
• You commit changes. If everything is fine, then you push the changes to the repository.
• After committing, if you realize something is wrong, then you correct the last commit and push the changes to the repository.

Shown below is the pictorial representation of the work-flow.

?????????????????????????????

Basic Git Commands :

git init :

This command turns a directory into an empty Git repository. This is the first step in creating a repository. After running git init, adding and committing files/directories is possible.

---$ git init

git add :

Adds files in the to the staging area for Git. Before a file is available to commit to a repository, the file needs to be added to the Git index (staging area). There are a few different ways to use git add, by adding entire directories, specific files, or all unstaged files.

---$ git add <file or directory name>

git commit :

Record the changes made to the files to a local repository. For easy reference, each commit has a unique ID.

It’s best practice to include a message with each commit explaining the changes made in a commit. Adding a commit message helps to find a particular change or understanding the changes.

---$ git commit -m "Commit message in quotes"

git status :

This command returns the current state of the repository. Git status will return the current working branch. If a file is in the staging area, but not committed, it shows with git status. Or, if there are no changes it’ll return nothing to commit, working directory clean.

---$ git status

git config :

With Git, there are many configurations and settings possible. git config is how to assign these settings. Two important settings are user user.name and user.email. These values set what email address and name commits will be from on a local computer. With git config, a --global flag is used to write the settings to all repositories on a computer. Without a --global flag settings will only apply to the current repository that you are currently in.

---$ git config <setting> <command>

git branch :

To determine what branch the local repository is on, add a new branch, or delete a branch.

---$ git branch <branch_name>

---$ git branch -a

---$ git branch -d <branch_name>?

git merge

Integrate branches together. git merge combines the changes from one branch to another branch. For example, merge the changes made in a staging branch into the stable branch.

?---$ git merge <branch_name>

git pull

git pull is one of many commands that claim the responsibility of 'syncing' remote content.

????---$ git pull

git push

The git push command is used to upload content to a remote repository.

---$ git push

What is the difference between pushing and pulling?

????????????????????????????????????????????????????????????

Pull

A pull grabs any changes from the GitHub repository and merges them into your local repository.

It combines changes from upstream into your local repository, which is a regular activity in Git-based collaborations. Developers use this command if a teammate has made commits to a branch on a remote, and they would like to reflect those changes in their local environment.??

---$ git remote add origin <central repository's link>

This command is used to make a central repository the origin.

---$ git pull origin master

This command will copy all files from the remote repository’s master branch to your local repository.

---$ git pull origin <branch-name>

This command is used for pulling files from a different branch.

Push

Pushing sends the recent commit history from your local repository up to GitHub. If you're the only one working on a repository, pushing is fairly simple. If there are others accessing the repository, you may need to pull before you can push.

Git push is a command that pushes your local modifications to a central repository. When one has accumulated multiple local commits and is ready to share it with the rest of the team, use the following command to push them to the central repository:

---$ git push <remote>

Note: When using the pull command, this remote refers to the remote repository that was previously configured.

This syncs the changes from the local repository to the remote repository, including all commits and internal objects. In the target repository, this generates a local branch.

---$ git push origin master

This command is used to reflect the already committed files in the master branch of the central repository.

Git does not enable push when it results in a non-fast-forward merging in the destination repository to prevent overwriting.

---$ git push <remote> --force

Even if the push operation results in a non-fast-forward merging, the above instruction forces it.

How to initialize a new Git repository?

---$ git init

The above command initializes a brand new Git repository and begins tracking an existing directory. It adds a hidden subfolder within the existing directory that houses the internal data structure required for version control.

Common usages and options for git init

$ git init <directory>

Transforms a directory in the current path into a Git repository

$ git init --bare

Creates a new bare repository (a repository to be used as a remote repository only, that won’t contain active development)

git init vs git clone

It can be tricky to get started on a new project. It’s not always clear if one should use git init, git clone, or both.

git init: Creating a Local Repository by One Person

Although ones project may already exist locally, it does not currently have Git. git init is most likely the best option for one. Even if other participants share the project, this is only run once.

• To begin, set up the repository and commit at least one change.
• Create a remote repository somewhere like GitHub.com once one has setup the repository.
• Then use git remote add origin to add the remote URL to your local git repository. This saves the remote URL as origin, which is a more human-friendly term.
• By using git add to stage existing files and git commit to create the snapshot, you may turn your history into at least one commit.
• One can push to the remote and set up the tracking relationship for good using git push -u origin master once he/she has at least one commit.

git clone: The Remote Already Exists

---$ git clone

If there are commits and files in the remote repository but one would still like it to contain his/her project files, git clone that repository. Then, move the project’s files into that cloned repository. git add, git commit, and git push to create a history that makes sense for the beginning of their project. Then, the team can interact with the repository without git init again. One should use git clone instead of git init if the repository already exists on a remote.

One may need to do a few extra steps if one creates a remote repository first and then moves the project to it later. If the remote repository has no commits, one can use the git init command as described above.

git init: Existing Folder

The default behavior of git init is to turn the current directory into a Git repository. Navigate to the root directory of an existing project to make it a Git repository. After that, run git init.

Alternatively, one can create a new repository in his/her current path. Specify the directory to turn into a Git repository with git init <directory>.

git init: Gone Wrong

If one runs git init in the wrong location, one will end up with undesired repositories. When using Git, one may have encountered unusual error messages. One may think another parent directory is a Git repository as well.

To correct this, one must first determine which directory contains the unwanted repository. To see if Git is tracking the current directory, type git status. If that’s the case, one can use ls -al to search for an otherwise hidden .git directory.

If one don’t see it, use cd… to go one level up in the directory hierarchy. Use git status in conjunction with ls -al once again. Repeat until .git directory is located.

What is the use of git clone and how to use it?

The git clone command is used to duplicate a repository or a branch inside a repository.

Git is a version control system that is distributed. By cloning, you may reap the benefits of having a whole repository on your own workstation.

---git clone https://github.com/github/training-kit.git

When one clones a repository, unlike other centralized version control systems, one does not obtain a single file. When one clones a repository with Git, his/she gets the complete repository, including all files, branches, and commits.

Cloning a repository is usually done only once, at the start of a project’s interaction with him. One would clone a repository that already exists on a remote, such as GitHub so that one could interact with it locally. One would not need to clone a repository again to undertake normal development once he/she has cloned it.

All developers will be able to work more freely now that they have access to the complete repository. Working on a feature branch allows one to make changes without being constrained by the files one can work on.

• Using git push, one may share his/her branch with the remote repository.
• Create a pull request with ones colleagues to compare the changes.
• Test and deploy as needed from the branch.
• merge into the master branch.

Most common uses and options of git clone:

---$ git clone [url]

• Clone (download) an existing GitHub repository, including all of its files, branches, and commits.?

??????????---$ git clone --mirror

• Clone a repository but don’t have access to any of the files. This comprises the references, often known as branches. If one is trying to create a secondary copy of a repository on a different remote and want to match all of the branches, this is the method to utilize. This can happen when setting up a new remote for your Git hosting or while running automated tests with Git.

?????????---$ git clone --single-branch

• Clone only a single branch

?????????---$ git clone --sparse

• Instead of recursively populating the working directory with all of the files in the current commit, only populate the root directory with files. When cloning big repositories with many directories and sub-directories, could aid with performance.

---$ git clone --recurse-submodules[=<pathspec]

• Initialize and clone submodules within the clone depending on the specified pathspec after it has been built. This is a nice choice if one is cloning a repository with submodules that one will be using as dependents in his/her local development.

How to ignore some files/folders from pushing?

There are a few common solutions if one is trying to git push but is having trouble.

Examine your branch:

With git status, one can see which branch one is on right now. One might not be able to push commits directly to the remote if he/she is working on a protected branch like master. It’s okay if this happens to one! There are a few options for resolving this.

There was no work on any branch at the time:

• Create a new branch from your current commit and checkout to it:

---$ git checkout -b [branchname]

• Then, up to the remote, push the new branch:

---$ git push -u origin [branchname]

Committed to the incorrect branch by accident:

• To commit to a branch, checkout:

---$ git checkout [branchname]

• Merge the commits from the branch to which you made an error:

---$ git merge [master]

• Push the changes to the remote:

---$ git push

• Fix the other branch by checking out to that branch, determining which commit it should be pointed to, then correcting the branch pointer with the following command:

---$ git reset --hard

What do you mean by Branch?

Working on multiple versions of a repository at the same time is known as branching.

Few common branch names used are:

• Master: The code which is live/finalized.
• Develop: Not yet live/finalized, but working code. Many developers work on it actively.
• Feature: To work in an isolated environment while making new changes.
• Release: Branch used only to push code to live servers.

A repository contains one main branch by default, which is considered the definitive branch. Branches are used to test and make changes before committing them to the main branch.

When one builds a branch of the main branch, he/she is essentially producing a replica of the main as it was at the moment. One could pull in updates from the main branch if they were made while one was working on his/her branch.

Let’s imagine you want to add a new feature (which is still in development), but you’re unsure whether or not to make changes to your primary project. Branches allow one to switch back and forth between different project states/versions. In the example, one may establish a new branch and test the new feature without affecting the master branch. When finished, merge the changes from the new branch into the main branch. The master branch is the main branch in this case, which is present by default in your repository.

● Which branch should be used to keep deployment-ready code?

There is a master/production branch with a fresh branch for testing that is used to keep the deployment-ready code, as shown in the above figure. Two sets of changes are made under thi s branch, and once they are finished, they are merged back into the main branch.

● Create a new branch called development from the main branch.

We can use the git branch command to create, list branches on the command line.

---$ git checkout <branch name>

---$ git branch developement

To create a new branch using the Git command line and to switch to the newly created branch, issue the command:

---$ git checkout <branch name>

---$ git checkout developement

?Check out one more branch deployment from the previous branch.

---$ git checkout -b deployement developement

?Push different data into both branches.

---$ git push origin developement

---$ git push origin deployement

Merge data from both branches to the main branch.

---$ git checkout developement

---$ git merge main

?

?

?

?

?

?

?

?

?

?

?

?

?

?

$ git add <file or directory name>

?

?

?

?

?

?