MASTERCLASS #TASK ON GIT & GITHUB

MASTERCLASS #TASK ON GIT & GITHUB

What’s the difference between Git & Github?

GitHub is a central repository and cloud-based service that allows developers to store and manage their code in the cloud, as well as track and control modifications.

Git is a free, open-source distributed version control tool that may be used for both small and big projects. Git was created to make it easier for programmers and developers to collaborate.

No alt text provided for this image


What is a repository?

A repository, often known as a Git project, contains a project’s entire collection of files and folders, as well as each file’s revision history. The file history is represented by commits, which are temporal snapshots that have a linked-list relationship and can be arranged into various development lines called branches. One can keep code files, text files, image files, etc, inside a repository.


Basic Git Commands


$ git init

initialize an existing directory as a Git repository.

$ git clone

creates a local copy of a project that already exists remotely. The clone includes all the project’s files, history, and branches.

$ git add

stages a change. Git tracks changes to a developer’s codebase, but it’s necessary to stage and take a snapshot of the changes to include them in the project’s history. This command performs staging, the first part of that two-step process. Any changes that are staged will become a part of the next snapshot and a part of the project’s history. Staging and committing separately gives developers complete control over the history of their projects without changing how they code and work.

$ git commit

saves the snapshot to the project history and completes the change-tracking process. In short, a commit functions like taking a photo. Anything that’s been staged with git add will become a part of the snapshot with git commit.

$ git status

shows the status of changes as untracked, modified, or staged.

$ git branch

shows the branches being worked on locally.

$ git merge

merges lines of development together. This command is typically used to combine changes made on two distinct branches. For example, a developer would merge when they want to combine changes from a feature branch into the main branch for deployment.

$ git pull

updates the local line of development with updates from its remote counterpart.

$ git push

updates the remote repository with any commits made locally to a branch.

What is the difference between pushing and pulling?


Pull

The git pull command downloads changes from a remote repository and saves them to a 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

This command syncs commits between your local and remote repositories. Pull operation is the polar opposite of push operation. Pushing commits to distant repositories, whereas pulling imports commits to local repositories.

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 this 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 branch <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



#regexsoftware #regexsoftwareservices #GIT #GITHUB #workshop


要查看或添加评论,请登录

Subhajit Mondal的更多文章

社区洞察

其他会员也浏览了