An introduction to Git merge and rebase: what they are, and how to use them

As a Developer, many of us have to choose between Merge and Rebase. With all the references we get from the internet, everyone believes “Don’t use Rebase, it could cause serious problems.” Here I will explain what merge and rebase are, why you should (and shouldn’t) use them, and how to do so.

As a Developer, many of us have to choose between Merge and Rebase. With all the references we get from the internet, everyone believes “Don’t use Rebase, it could cause serious problems.” Here I will explain what merge and rebase are, why you should (and shouldn’t) use them, and how to do so.

Git Merge and Git Rebase serve the same purpose. They are designed to integrate changes from multiple branches into one. Although the final goal is the same, those two methods achieve it in different ways, and it's helpful to know the difference as you become a better software developer.

This question has split the Git community. Some believe you should always rebase and others that you should always merge. Each side has some convincing benefits.

Git Merge

Merging is a common practice for developers using version control systems. Whether branches are created for testing, bug fixes, or other reasons, merging commits changes to another location. To be more specific, merging takes the contents of a source branch and integrates them with a target branch. In this process, only the target branch is changed. The source branch history remains the same.

Merge Master -> Feature branch

Pros

  • Simple and familiar
  • Preserves complete history and chronological order
  • Maintains the context of the branch

Cons

  • Commit history can become polluted by lots of merge commits
  • Debugging using git bisect can become harder

How to do it

Merge the master branch into the feature branch using the checkout and merge commands.


$ git checkout feature
$ git merge master
(or)
$ git merge master feature


This will create a new “Merge commit” in the feature branch that holds the history of both branches.

Git Rebase

Rebase is another way to integrate changes from one branch to another. Rebase compresses all the changes into a single “patch.” Then it integrates the patch onto the target branch.

Unlike merging, rebasing flattens the history because it transfers the completed work from one branch to another. In the process, unwanted history is eliminated.

Rebases are how changes should pass from the top of the hierarchy downwards, and merges are how they flow back upwards

Rebase feature branch into master

Pros

  • Streamlines a potentially complex history
  • Manipulating a single commit is easy (e.g. reverting them)
  • Avoids merge commit “noise” in busy repos with busy branches
  • Cleans intermediate commits by making them a single commit, which can be helpful for DevOps teams

Cons

  • Squashing the feature down to a handful of commits can hide the context
  • Rebasing public repositories can be dangerous when working as a team
  • It’s more work: Using rebase to keep your feature branch updated always
  • Rebasing with remote branches requires you to force push. The biggest problem people face is they force push but haven’t set git push default. This results in updates to all branches having the same name, both locally and remotely, and that is dreadful to deal with.
If you rebase incorrectly and unintentionally rewrite the history, it can lead to serious issues, so make sure you know what you are doing!

How to do it

Rebase the feature branch onto the master branch using the following commands.


$ git checkout feature
$ git rebase master

This moves the entire feature branch on top of the master branch. It does this by re-writing the project history by creating brand new commits for each commit in the original (feature) branch.

Interactive Rebasing

This allows altering the commits as they are moved to the new branch. This is more powerful than automated rebase, as it offers complete control over the branch’s commit history. Typically this is used to clean up a messy history before merging a feature branch into master.

$ git checkout feature
$ git rebase -i master

This will open the editor by listing all the commits that are about to be moved.

pick 22d6d7c Commit message#1
pick 44e8a9b Commit message#2
pick 79f1d2h Commit message#3

This defines exactly what the branch will look like after the rebase is performed. By re-ordering the entities, you can make the history look like whatever you want. For example, you can use commands like fixup, squash, edit etc, in place of pick.

Which one to use

So what’s best? What do the experts recommend?


It’s hard to generalize and decide on one or the other, since every team is different. But we have to start somewhere.

Teams need to consider several questions when setting their Git rebase vs. merge policies. Because as it turns out, one workflow strategy is not better than the other. It is dependent on your team.

Consider the level of rebasing and Git competence across your organization. Determine the degree to which you value the simplicity of rebasing as compared to the traceability and history of merging.

Finally, decisions on merging and rebasing should be considered in the context of a clear branching strategy (Refer this article to understand more about branching strategy). A successful branching strategy is designed around the organization of your teams.

What do I recommend?

As the team grows, it will become hard to manage or trace development changes with an always merge policy. To have a clean and understandable commit history, using Rebase is reasonable and effective.

By considering the following circumstances and guidelines, you can get best out of Rebase:

  • You’re developing locally: If you have not shared your work with anyone else. At this point, you should prefer rebasing over merging to keep your history tidy. If you’ve got your personal fork of the repository and that is not shared with other developers, you’re safe to rebase even after you’ve pushed to your branch.
  • Your code is ready for review: You created a pull request. Others are reviewing your work and are potentially fetching it into their fork for local review. At this point, you should not rebase your work. You should create ‘rework’ commits and update your feature branch. This helps with traceability in the pull request and prevents the accidental history breakage.
  • The review is done and ready to be integrated into the target branch.Congratulations! You’re about to delete your feature branch. Given that other developers won’t be fetch-merging in these changes from this point on, this is your chance to sanitize your history. At this point, you can rewrite history and fold the original commits and those pesky ‘pr rework’ and ‘merge’ commits into a small set of focused commits. Creating an explicit merge for these commits is optional, but has value. It records when the feature graduated to master.

Conclusion

I hope this explanation has given some insights on Git merge and Git rebase.Merge vs rebase strategy is always debatable. But perhaps this article will help dispel your doubts and allow you to adopt an approach that works for your team.

I’m looking forward to writing on Git workflows and concepts of Git. Do comment on the topics that you want me to write about next. Cheers!

code = coffee + developer

Here is another useful reference

A

Git and Github: A Beginner's Guide

Git and Github: A Beginner's Guide

I'm an undergraduate in Information Systems. I love coding. I love to write things that I love. The beginner's guide to Git & GitHub

What is Git?

Git is a free, open-source version control software. It was created by Linus Torvalds in 2005. This tool is a version control system that was initially developed to work with several developers on the Linux kernel.

This basically means that Git is a content tracker. So Git can be used to store content — and it is mostly used to store code because of the other features it provides.

Real life projects generally have multiple developers working in parallel. So they need a version control system like Git to make sure that there are no code conflicts between them.

Also, the requirements in such projects change often. So a version control system allows developers to revert and go back to an older version of their code.

The branch system in Git allows developers to work individually on a task (For example: One branch -> One task OR One branch -> One developer). Basically think of Git as a small software application that controls your code base, if you’re a developer.

Shows how Git works

Git Repositories

If we want to start using Git, we need to know where to host our repositories.

A repository (or “Repo” for short) is a project that contains multiple files. In our case a repository will contain code-based files.

There are two ways you can host your repositories. One is online (on the cloud) and the second is offline (self-installed on your server).

There are three popular Git hosting services: GitHub (owned by Microsoft), GitLab (owned by GitLab) and BitBucket. We’ll use GitHub as our hosting service.

Before using Git we should know why we need it

Git makes it easy to contribute to open source projects

Nearly every open-source project uses GitHub to manage their projects. Using GitHub is free if your project is open source, and it includes a wiki and issue tracker that makes it easy to include more in-depth documentation and get feedback about your project.

If you want to contribute, you just fork (get a copy of) a project, make your changes, and then send the project a pull request using GitHub's web interface. This pull request is your way of telling the project you're ready for them to review your changes.

Documentation

By using GitHub, you make it easier to get excellent documentation. Their help section and guides have articles for nearly any topic related to Git that you can think of.

Integration options

GitHub can integrate with common platforms such as Amazon and Google Cloud, with services such as Code Climate to track your feedback, and can highlight syntax in over 200 different programming languages.

Track changes in your code across versions

When multiple people collaborate on a project, it’s hard to keep track of revisions — who changed what, when, and where those files are stored.

GitHub takes care of this problem by keeping track of all the changes that have been pushed to the repository.

Much like using Microsoft Word or Google Drive, you can have a version history of your code so that previous versions are not lost with every iteration. It’s easy to come back to the previous version and contribute your work.

Showcase your work

Are you a developer who wishes to attract recruiters? GitHub is the best tool you can rely on for this.

Today, when searching for new recruits for their projects, most companies look at GitHub profiles. If your profile is available, you will have a higher chance of being recruited even if you are not from a great university or college.

Now we’ll learn how to use Git & GitHub

GitHub account creation

To create your account, you need to go to GitHub's website and fill out the registration form.

GitHub official web page

Git installation

Now we need to install Git's tools on our computer. We’ll use CLI to communicate with GitHub.

For Ubuntu:

  1. First, update your packages.
sudo apt update

2. Next, install Git and GitHub with apt-get

sudo apt-get install git

3. Finally, verify that Git is installed correctly

git --version

4. Run the following commands with your information to set a default username and email when you’re going to save your work.

git config --global user.name "MV Thanoshan"
git config --global user.email "[email protected]"

Working with GitHub projects

We’ll work with GitHub projects in two ways.

Type 1: Create the repository, clone it to your PC, and work on it.(Recommended)

Type 1 involves creating a totally fresh repository on GitHub, cloning it to our computer, working on our project, and pushing it back.

Create a new repository by clicking the “new repository” button on the GitHub web page.

Pick a name for your first repository, add a small description, check the ‘Initialize this repository with a README’ box, and click on the “Create repository” button.

Well done! Your first GitHub repository is created.

Your first mission is to get a copy of the repository on your computer. To do that, you need to “clone” the repository on your computer.

To clone a repository means that you're taking a repository that’s on the server and cloning it to your computer – just like downloading it. On the repository page, you need to get the “HTTPS” address.

Once you have the address of the repository, you need to use your terminal. Use the following command on your terminal. When you’re ready you can enter this:

git clone [HTTPS ADDRESS]

This command will make a local copy of the repository hosted at the given address.

Output message of “git clone” command

Now, your repository is on your computer. You need to move in it with the following command.

cd [NAME OF REPOSITORY]

As you can see in the above picture, my repository name is “My-GitHub-Project” and this command made me go to that specific directory.

**NOTE:**When you clone, Git will create a repository on your computer. If you want, you can access your project with the computer user interface instead using the above ‘cd’ command on the terminal.

Now, in that folder we can create files, work on them, and save them locally. To save them in a remote place — like GitHub – we have do a process called a “commit”. To do this, get back to your terminal. If you closed it, like I previously stated, use the ‘cd’ command.

cd [NAME OF REPOSITORY]

Now, in the terminal, you’re in your repository directory. There are 4 steps in a commit: ‘status’ , ‘add’ , ‘commit’ and ‘push’. All the following steps must be performed within your project. Let's go through them one by one.

  1. “status”: The first thing you need to do is to check the files you have modified. To do this, you can type the following command to make a list of changes appear.
git status

2. “add”: With the help of the change list, you can add all files you want to upload with the following command,

git add [FILENAME] [FILENAME] [...]

In our case, we’ll add a simple HTML file.

git add sample.html

3. “commit”: Now that we have added the files of our choice, we need to write a message to explain what we have done. This message may be useful later if we want to check the change history. Here is an example of what we can put in our case.

git commit -m "Added sample HTML file that contain basic syntax"

4. “push”: Now we can put our work on GitHub. To do that we have to ‘push’ our files to Remote. Remote is a duplicate instance of our repository that lives somewhere else on a remote server. To do this, we must know the remote’s name (Mostly remote is named origin). To figure out that name, type the following command.

git remote

As you can see in the above image, it says that our remote’s name is origin. Now we can safely ‘push’ our work by the following command.

git push origin master

Now, if we go to our repository on the GitHub web page, we can see the sample.html file that we’ve pushed to remote — GitHub!

NOTE: Sometimes when you’re using Git commands in the terminal, it can lead you to the VIM text editor (a CLI based text-editor). So to get rid of it, you have to type

:q

and ENTER.

Describes how pull & push work

Pulling is the act of receiving from GitHub.

Pushing is the act of sending to GitHub.

Type 2: Work on your project locally then create the repository on GitHub and push it to remote.

Type 2 lets you make a fresh repository from an existing folder on our computer and send that to GitHub. In a lot of cases you might have actually already made something on your computer that you want to suddenly turn into a repository on GitHub.

I will explain this to you with a Survey form web project that I made earlier that wasn’t added to GitHub.

As I already mentioned, when executing any Git commands, we have to make sure that we are in the correct directory in the terminal.

By default, any directory on our computer is not a Git repository – but we can turn it into a Git repository by executing the following command in the terminal.

git init

After converting our directory to a Git repository, the first thing we need to do is to check the files we have by using the following command.

git status

So there are two files in that directory that we need to “add” to our Repo.

git add [FILENAME] [FILENAME] [...]

NOTE: To “add” all of the files in our Repository we can use the following command:

git add .

After the staging area (the add process) is complete, we can check whether the files are successfully added or not by executing the git status

If those particular files are in green like the below picture, you’ve done your work!

Then we have to “commit” with a description in it.

git commit -m "Adding web Survey form"

If my repository started on GitHub and I brought it down to my computer, a remote is already going to be attached to it (Type 1). But if I’m starting my repository on my computer, it doesn’t have a remote associated with it, so I need to add that remote (Type 2).

So to add that remote, we have to go to GitHub first. Create a new repository and name it whatever you want to store it in GitHub. Then click the “Create repository” button.

NOTE: In Type 2, Please don’t initialize the repository with a README file when creating a new repository on the GitHub web page.

After clicking the “Create repository” button you’ll find the below image as a web page.

Copy the HTTPS address. Now we’ll create the remote for our repository.

git remote add origin [HTTPS ADDRESS]

After executing this command, we can check whether we have successfully added the remote or not by the following command

git remote

And if it outputs “origin” you’ve added the remote to your project.

NOTE: Just remember we can state any name for the remote by changing the name “origin”. For example:

git remote add [REMOTE NAME] [HTTPS ADDRESS]

Now, we can push our project to GitHub without any problems!

git push origin master

After completing these steps one by one, if you go to GitHub you can find your repository with the files!

Conclusion

Thank you everyone for reading. I just explained the basics of Git and GitHub. I strongly encourage you all to read more related articles on Git and GitHub. I hope this article helped you.

Check out my original article in Medium.

Thank you.

Basic Git/GitHub Cheat Sheet

Basic Git/GitHub Cheat Sheet

Basic Git/GitHub Cheat Sheet: The Beginner's Guide to Version Control

If you aren’t already familiar with version control and incorporating it into your daily workflow, now is the time to get started. This is a barebones basic guide to get you started with Git and give you a solid foundation to develop further. Git is almost certainly used in any professional environment and the more you familiarize yourself with it early on the more valuable you will be to employers. Also, this will make your personal experience better by being able to switch computers without having to worry about saving your project on a flash drive. Working on groups projects will become so much easier to manage. Ever messed up your code so bad you felt like it would just be easier to start from scratch? With version control, you can just revert back to a stable version free from all of those crazy ideas you wanted to implement at 2 am.

Git and GitHub

Git is the actual version control system. It is an open source DVCS (distributed version control system) that runs in the command line. This basically means it saves the entire history of the project. The history of your project and the history of the same project that’s being worked on by your peers will all have copies. This is the opposite of SVN (subversion) where the entire history is stored in only one place.

GitHub, commonly confused with Git, is actually a repository hosting service. You might not understand what a repository is right now but hang in there, you will by the end of this. GitHub actually has a lot to it but for now, we are going to keep it simple. This is where you will be uploading your history using Git. This allows you and your peers to retrieve the latest copy of your project while also allowing multiple people to work on it without hindering each other.

Getting Started

Git is complex and there are many things to learn but to get started you really only need to know a few key things to get started. The more you use Git, you will encounter situations where this will absolutely not be enough but there are many resources out there that can aid you when that occurs. So, use this to get you started but do keep expanding your knowledge.

The first thing you are going to want to do is to download Git. For Windows users I suggest also installing Git Bash, which is available when installing Git. For Mac users, using the Terminal will be completely fine. Once installed go ahead and head to GitHub create a free account. Now you have Git, the command line tool, and a GitHub account, where you will be uploading your repositories.

Cheat Sheet

Using Git Bash or the Terminal navigate to the actual project folder. If you are using Git Bash you can right-click the project folder and select “Git Bash Here” and it will start you in that working directory.

<strong>git init </strong>

This will create a .git repository in your project. A repository or “repo” is a collection of all the changes you’ve made to your project over time and will build a history of these changes. This is the first thing you want to do with a new project.

git config --global user.name "Your Name"

git config --global user.email "[email protected]"

This sets up your information that is used every time you commit. This only needs to be done once when you first install Git.

git add filename.extension

Replace “filename.extension” to whatever file you are trying to add like “index.html”. This will add the file you specify to what is called a “staging area” or index. Think of the staging area like a section where things are getting set up to be moved to your repository.

git add .

If you want to add everything from the project folder to the staging area this command will do that instead of having to add each file one by one.

git add *.html

If you want to add all .html files to your staging area this would be the command to use. The extension can be changed to whatever you want.

git status

Shows what has already been added to the staging area and what files have been changed that need to be added to the staging area.

git reset filename.extension

Removes specified file from the staging area.

git rm --cached filename.extension

This will remove the file from the staging area and sets it to be untracked.

git commit -m "Description of the commit"

Takes the files from your staging area and commits them to your local repository. In quotes will be a brief description of what was changed with each commit. Try to describe the commit in brief detail such as “fixed bug where user name wasn’t updating” rather than a commit message like “some changes.”

touch .gitignore

This will create a file called .gitignore. You can open that file with a text editor and write the name of files or folders you want to be ignored from your repository. Ignored files won’t show up when you run git status to prevent you from committing files you’ve previously said you don’t want to commit or even know about their changes.

git branch branchName

Creates what is called a branch. A branch is a direct copy of your codebase from previous branch you were on (often the master branch).

git checkout “branchName”

Will allow you to checkout the branch you created and work within that branch. You can make any changes to your code that you want here. When it’s ready, you can commit your code and push the branch to GitHub (see below) or you can delete the branch if something goes wrong or you decide you don’t need that feature or bug fix any longer.

git merge branchName

While inside Master you can use this command to take the commits from the branch you were working in and merge them together with the main repository.

git remote add origin <a href="https://github.com/userName/project.git" target="_blank">https://github.com/userName/project.git</a>

This adds the location of your remote repository. Everything up until now has been on your local repository on your computer. You will need to go to your GitHub account and create a new remote repository where you will be able to push your local repository. After you created your remote repository you will be provided with a link and that link is the location you will want to use in the above command.

git remote

List of your remote repositories that have been associated with your project.

git push -u origin master

This will push your local repository to your remote repository. This command only needs to be written like this when you do it for the first time.

git push

This is what you will use to push your code to GitHub after your initial push.

git clone <a href="https://github.com/userName/project.git" target="_blank">https://github.com/userName/project.git</a>

If you don’t have your project on the computer you’re working with this will allow you to clone (or download) the entire project into the directory you are working.

git pull

If you are working on the same codebase with other people, this command will allow you to pull the latest version from the remote repository and update your local version so you can work with the latest updates as their changes enter the codebase.

Conclusion

Hopefully, this has given you enough information to get started and have a basic understanding of what’s going on. There is a lot more to Git but you can build on top of this information. Many people have no idea where to begin or think it’s daunting to understand but just take this information and get started. You will quickly see the benefits and also will have increased your value as a programmer.

Git and Github: A Beginner’s Guide for Absolute Beginners

Git and Github: A Beginner’s Guide for Absolute Beginners

If you are a developer and you want to get started with Git and GitHub, then this article is made for you.

What is Git?

Git is a free, open-source version control software. It was created by Linus Torvalds in 2005. This tool is a version control system that was initially developed to work with several developers on the Linux kernel.

This basically means that Git is a content tracker. So Git can be used to store content — and it is mostly used to store code because of the other features it provides.

Real life projects generally have multiple developers working in parallel. So they need a version control system like Git to make sure that there are no code conflicts between them.

Also, the requirements in such projects change often. So a version control system allows developers to revert and go back to an older version of their code.

The branch system in Git allows developers to work individually on a task (For example: One branch -> One task OR One branch -> One developer). Basically think of Git as a small software application that controls your code base, if you’re a developer.

Git Repositories

If we want to start using Git, we need to know where to host our repositories.

A repository (or “Repo” for short) is a project that contains multiple files. In our case a repository will contain code-based files.

There are two ways you can host your repositories. One is online (on the cloud) and the second is offline (self-installed on your server).

There are three popular Git hosting services: GitHub (owned by Microsoft), GitLab (owned by GitLab) and BitBucket. We’ll use GitHub as our hosting service.

Before using Git we should know why we need it

Git makes it easy to contribute to open source projects

Nearly every open-source project uses GitHub to manage their projects. Using GitHub is free if your project is open source, and it includes a wiki and issue tracker that makes it easy to include more in-depth documentation and get feedback about your project.

If you want to contribute, you just fork (get a copy of) a project, make your changes, and then send the project a pull request using GitHub's web interface. This pull request is your way of telling the project you're ready for them to review your changes.

Documentation

By using GitHub, you make it easier to get excellent documentation. Their help section and guides have articles for nearly any topic related to Git that you can think of.

Integration options

GitHub can integrate with common platforms such as Amazon and Google Cloud, with services such as Code Climate to track your feedback, and can highlight syntax in over 200 different programming languages.

Track changes in your code across versions

When multiple people collaborate on a project, it’s hard to keep track of revisions — who changed what, when, and where those files are stored.

GitHub takes care of this problem by keeping track of all the changes that have been pushed to the repository.

Much like using Microsoft Word or Google Drive, you can have a version history of your code so that previous versions are not lost with every iteration. It’s easy to come back to the previous version and contribute your work.

Showcase your work

Are you a developer who wishes to attract recruiters? GitHub is the best tool you can rely on for this.

Today, when searching for new recruits for their projects, most companies look at GitHub profiles. If your profile is available, you will have a higher chance of being recruited even if you are not from a great university or college.

Now we’ll learn how to use Git & GitHub

GitHub account creation

To create your account, you need to go to GitHub's website and fill out the registration form.

Git installation

Now we need to install Git's tools on our computer. We’ll use CLI to communicate with GitHub.

For Ubuntu:

  1. First, update your packages.
sudo apt update

2. Next, install Git and GitHub with apt-get

sudo apt-get install git

3. Finally, verify that Git is installed correctly

git --version

4. Run the following commands with your information to set a default username and email when you’re going to save your work.

git config --global user.name "MV Thanoshan"
git config --global user.email "[email protected]"
Working with GitHub projects

We’ll work with GitHub projects in two ways.

Type 1: Create the repository, clone it to your PC, and work on it.(Recommended)

Type 1 involves creating a totally fresh repository on GitHub, cloning it to our computer, working on our project, and pushing it back.

Create a new repository by clicking the “new repository” button on the GitHub web page.

Pick a name for your first repository, add a small description, check the ‘Initialize this repository with a README’ box, and click on the “Create repository” button.

Well done! Your first GitHub repository is created.

Your first mission is to get a copy of the repository on your computer. To do that, you need to “clone” the repository on your computer.

To clone a repository means that you're taking a repository that’s on the server and cloning it to your computer – just like downloading it. On the repository page, you need to get the “HTTPS” address.

Once you have the address of the repository, you need to use your terminal. Use the following command on your terminal. When you’re ready you can enter this:

git clone [HTTPS ADDRESS]

This command will make a local copy of the repository hosted at the given address.

Now, your repository is on your computer. You need to move in it with the following command.

cd [NAME OF REPOSITORY]

As you can see in the above picture, my repository name is “My-GitHub-Project” and this command made me go to that specific directory.

**NOTE:**When you clone, Git will create a repository on your computer. If you want, you can access your project with the computer user interface instead using the above ‘cd’ command on the terminal.

Now, in that folder we can create files, work on them, and save them locally. To save them in a remote place — like GitHub – we have do a process called a “commit”. To do this, get back to your terminal. If you closed it, like I previously stated, use the ‘cd’ command.

cd [NAME OF REPOSITORY]

Now, in the terminal, you’re in your repository directory. There are 4 steps in a commit: ‘status’ , ‘add’ , ‘commit’ and ‘push’. All the following steps must be performed within your project. Let's go through them one by one.

  1. “status”: The first thing you need to do is to check the files you have modified. To do this, you can type the following command to make a list of changes appear.
git status

2. “add”: With the help of the change list, you can add all files you want to upload with the following command,

git add [FILENAME] [FILENAME] [...]

In our case, we’ll add a simple HTML file.

git add sample.html

3. “commit”: Now that we have added the files of our choice, we need to write a message to explain what we have done. This message may be useful later if we want to check the change history. Here is an example of what we can put in our case.

git commit -m "Added sample HTML file that contain basic syntax"

4. “push”: Now we can put our work on GitHub. To do that we have to ‘push’ our files to Remote. Remote is a duplicate instance of our repository that lives somewhere else on a remote server. To do this, we must know the remote’s name (Mostly remote is named origin). To figure out that name, type the following command.

git remote

As you can see in the above image, it says that our remote’s name is origin. Now we can safely ‘push’ our work by the following command.

git push origin master

Now, if we go to our repository on the GitHub web page, we can see the sample.html file that we’ve pushed to remote — GitHub!

NOTE: Sometimes when you’re using Git commands in the terminal, it can lead you to the VIM text editor (a CLI based text-editor). So to get rid of it, you have to type

:q

and ENTER.

Pulling is the act of receiving from GitHub.

Pushing is the act of sending to GitHub.

Type 2: Work on your project locally then create the repository on GitHub and push it to remote.

Type 2 lets you make a fresh repository from an existing folder on our computer and send that to GitHub. In a lot of cases you might have actually already made something on your computer that you want to suddenly turn into a repository on GitHub.

I will explain this to you with a Survey form web project that I made earlier that wasn’t added to GitHub.

As I already mentioned, when executing any Git commands, we have to make sure that we are in the correct directory in the terminal.

By default, any directory on our computer is not a Git repository – but we can turn it into a Git repository by executing the following command in the terminal.

git init

After converting our directory to a Git repository, the first thing we need to do is to check the files we have by using the following command.

git status

So there are two files in that directory that we need to “add” to our Repo.

git add [FILENAME] [FILENAME] [...]

NOTE: To “add” all of the files in our Repository we can use the following command:

git add .

After the staging area (the add process) is complete, we can check whether the files are successfully added or not by executing the git status

If those particular files are in green like the below picture, you’ve done your work!

Then we have to “commit” with a description in it.

git commit -m "Adding web Survey form"

If my repository started on GitHub and I brought it down to my computer, a remote is already going to be attached to it (Type 1). But if I’m starting my repository on my computer, it doesn’t have a remote associated with it, so I need to add that remote (Type 2).

So to add that remote, we have to go to GitHub first. Create a new repository and name it whatever you want to store it in GitHub. Then click the “Create repository” button.

NOTE: In Type 2, Please don’t initialize the repository with a README file when creating a new repository on the GitHub web page.

After clicking the “Create repository” button you’ll find the below image as a web page.

Copy the HTTPS address. Now we’ll create the remote for our repository.

git remote add origin [HTTPS ADDRESS]

After executing this command, we can check whether we have successfully added the remote or not by the following command

git remote

And if it outputs “origin” you’ve added the remote to your project.

NOTE: Just remember we can state any name for the remote by changing the name “origin”. For example:

git remote add [REMOTE NAME] [HTTPS ADDRESS]

Now, we can push our project to GitHub without any problems!

git push origin master

After completing these steps one by one, if you go to GitHub you can find your repository with the files!

Conclusion

Thank you everyone for reading. I just explained the basics of Git and GitHub. I strongly encourage you all to read more related articles on Git and GitHub. I hope this article helped you.

Happy Coding!