What’s the difference between git fetch and git pull?

Patient Tools

Read, save, and share this guide

Use these quick tools to make this medical article easier to read, print, save, or share with a family member.

Article Summary

One of the feature git, has enabled us to record all changes by the commit. And saved it as our history. So when something unexpected happens, you can rollback to specific commits. But, too many commits may mess your git history. If you have a lot of fixup commits, and you merge all of them directly into master, the git history will be bloated (which...

Educational health guideWritten for patient understanding and clinical awareness.
Reviewed content workflowUse writer and reviewer profiles for stronger trust.
Emergency safety firstUrgent warning signs are highlighted below.

Seek urgent medical care if you notice

These warning signs are general safety guidance. Local emergency numbers and clinical judgment should always come first.

  • Severe symptoms, breathing difficulty, fainting, confusion, or rapidly worsening illness.
  • New weakness, severe pain, high fever, or symptoms after a serious injury.
  • Any symptom that feels urgent, unusual, or unsafe for the patient.
1

Emergency now

Use emergency care for severe, sudden, rapidly worsening, or life-threatening symptoms.

2

See a doctor

Book a professional medical evaluation if symptoms persist, worsen, recur often, affect daily activities, or occur in a high-risk patient.

3

Learn safely

Use this article to understand possible causes, tests, treatment options, prevention, and questions to ask your clinician.

One of the feature git, has enabled us to record all changes by the commit. And saved it as our history. So when something unexpected happens, you can rollback to specific commits. But, too many commits may mess your git history. If you have a lot of fixup commits, and you merge all of them directly into master, the git history will be bloated (which is something we don’t want). So, if your change consists of two commits X and Y, we want to squash them into a single commit Z

Some folks do it by hastily creating a new branch, porting all changes to it with a patch file and creating a separate pull request. But this is pain in the head or upper neck. সহজ বাংলা: মাথাব্যথা।" data-rx-term="headache" data-rx-definition="Headache means pain in the head or upper neck. সহজ বাংলা: মাথাব্যথা।">headache both for the contributor and project maintainer. There’s an easier way, which is git squash

https://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request

So before we start the process of squashing, first find out the number of commits we have made, we can inspect the total number of commits that have been made to the project with the following command:

git log

This will provide you with output that looks similar to this

Output
commit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 <email-2>
Date: Mon Dec 14 07:32:45 2015 -0400

    Commit details

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 <email-1>
Date: Fri Nov 27 20:24:45 2015 -0500

Commit details

The log shows all the commits made to the given project’s repository, so your commits will be mixed it with the commits made by others. For projects that have an extensive history of commits by multiple authors, you’ll want to specify yourself as author in the command:

git log --author=your-username

Now if you know the number of commits you’ve made on the branch (just count it) that you want to rebase, you can simply run the git rebase command like so:

git rebase -i HEAD~x

e.g.

git rebase -i HEAD~8

If, however, you don’t know how many commits you have made on your branch, you’ll need to find which commit is the base of your branch, which you can do by running the following command:

git merge-base new-branch master

This command will return a long string known as a commit hash, something that looks like this:

Output
66e506853b0366c87f4834bb6b39d341cd094fe9

We’ll use this commit hash to pass to the git rebase command:

git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

For either of the above commands, your command-line text editor will open with a file that contains a list of all the commits in your branch, and you can now choose whether to squash commits or reword them.

Now after running git rebase -i HEAD~8 the follwoing editor will open in the Terminal and this is where I have to choose which commit to Squash and which ones to Pick

When we squash commit messages, we are squashing or combining several smaller commits into one larger one.

In front of each commit you’ll see the word “pick,” so your file will look similar to this if you have two commits:

GNU nano 2.0.6 File: …username/repository/.git/rebase-merge/git-rebase-todo
pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature


# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

Now, for each line of the file you should replace the word “pick” with the word “squash” to combine the commits: And these lines will be arranged top to bottom like so, the most recent one (i.e. most recent commit) at the bottom most positon. And if I want to keep the lastest commit msg, all I have to do is edit the top-most line as pick and rest of all as squash.

GNU nano 2.0.6 File: …username/repository/.git/rebase-merge/git-rebase-todo
pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new feature

At this point, you can save and close the file ( Choosing the option shown in the Terminal, Control + O for writing out, then just press Enter for choosing the default file to write to and then finally Control+X to exit). After first exit, it will open the section editor inside Terminal where I should be able to edit and add the comments for my commit. So the same flow here as well. Edit inside Terminal Editor > press Control+O to write out > Press Enter to save to default file > Control+X to Exit

ISSUE – If I get Error – Git: “Cannot ‘squash’ without a previous commit” error while rebase

https://stackoverflow.com/a/51516360/1902852

Why it happened in my case was that, you cannot squash older commits onto a new commit. Here is an example say you have 3 commits:

pick 01mn9h78 The lastest commit
pick a2b6pcfr A commit before the latest
pick 093479uf An old commit i made a while back

Now if you say git rebase -i HEAD~3 and you do something like

pick 01mn9h78 The lastest commit
s a2b6pcfr A commit before the latest
s 093479uf An old commit i made a while back

This will result in the error :

error: cannot 'squash' without a previous commit You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'. Or you can abort the rebase with 'git rebase --abort'.

Solution :

When squashing commits , you should squash recent commits to old ones not vice versa thus in the example it will be something like this :

So put the ‘squash’ or ‘s’ word before the latest comment and ‘pick’ word before the oldest one

s 01mn9h78 The lastest commit
s a2b6pcfr A commit before the latest
pick 093479uf An old commit i made a while back

Now the FINAL step of actually pushing or updating the PR

Once you perform a rebase, the history of your branch changes, and you are no longer able to use the git push command because the direct path has been modified.

And you can check that by doing a git status You will get

Your branch and 'origin/master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

We will have to instead use the –force or -f flag to force-push the changes, informing Git that you are fully aware of what you are pushing.

At this point, we should ensure that we are on the correct branch by checking out the branch we are working on:

git checkout new-branch

Output
Already on 'new-branch'

Now we can perform the force-push:

git push -f

I could also do below, assuming I am in master branch, and all my squashing activities were in master branch

git push origin master --force

And now if I go to the exiting PR in Github, I will see the same PR has got fully updated with my latest changes, with just a single commit.

Note, all these squashing activities could have been done by the Repo’s Manager as well. The repository’s manager can squash all the commits in a pull request into a single commit by selecting “Squash and merge” on a pull request.

ISSUE – How to squash commits after the pull request has been opened ? That is, after I have created a PR, then squash my commits in my local machine and then when I go to the PR of the upstream Repo, I still see all the committs that were there previously.

Solution – (the below will save you many times)

The easiest way to squash all of these changes is probably start by resetting your current branch back to the upstream master branch:

$ git reset upstream/master

The magical thing abuout the above command is, this will reset the repository, but not your working directory, to the state of the upstream/master branch. Since it doesn’t modify the state of your working directory, this means that all your changes are preserved, but not the commit history. At this point, we see:

\$ git status
[...]
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

    modified:   app/server.go
    modified:   smtp.go

no changes added to commit (use "git add" and/or "git commit -a")

Now we can create a new commit:

$ git add -u
$ git commit

Now you have a single commit on top of the upstream master branch. You would then force push this to your own master branch, which would update the PR.

(NB: if you’re worried about screwing something up or losing your changes or anything like that, either work on a new branch, or just make a local copy of your working directory and work on that instead.)

What’s the difference between git fetch and git pull?

Before we talk about the differences between these two commands, lets stress their similarities: both are used to download new data from a remote repository.

git fetch really only downloads new data from a remote repository — but it doesn’t integrate any of this new data into your working files. It fetches all of the branches from the repository. This also downloads all of the required commits and files from the other repository.

git pull origin master

git fetch doesn’t integrate any of this new data into your working files. Fetch is great for getting a fresh view on all the things that happened in a remote repository. Due to its “harmless” nature, fetch will never destroy or manipulate anything in your local machine.

git pull, in contrast, is used with a different goal in mind: to update our current HEAD branch with the latest changes from the remote server. This means that pull not only downloads new data; it also directly integrates it into our current working copy files. This has a couple of consequences:

Since git pull tries to merge remote changes with your local ones, a so-called “merge conflict” can occur. Check out our in-depth tutorial on How to deal with merge conflicts for more information.

Like for many other actions, it’s highly recommended to start a git pull only with a clean working copy. This means that you should not have any uncommitted local changes before you pull. Use Git’s Stash feature to save your local changes temporarily.

So when you are working on Forked Repo, after fetching from the remote branch, you would still have to merge the commits. So you can actually replace

$ git fetch upstream

with

$ git pull upstream master

since git pull is essentially git fetch + git merge.

One of the feature git, has enabled us to record all changes by the commit. And saved it as our history. So when something unexpected happens, you can rollback to specific commits. But, too many commits may mess your git history. If you have a lot of fixup commits, and you merge all of them directly into master, the git history will be bloated (which is something we don’t want). So, if your change consists of two commits X and Y, we want to squash them into a single commit Z

Some folks do it by hastily creating a new branch, porting all changes to it with a patch file and creating a separate pull request. But this is pain in the head or upper neck. সহজ বাংলা: মাথাব্যথা।" data-rx-term="headache" data-rx-definition="Headache means pain in the head or upper neck. সহজ বাংলা: মাথাব্যথা।">headache both for the contributor and project maintainer. There’s an easier way, which is git squash

https://www.digitalocean.com/community/tutorials/how-to-rebase-and-update-a-pull-request

So before we start the process of squashing, first find out the number of commits we have made, we can inspect the total number of commits that have been made to the project with the following command:

git log

This will provide you with output that looks similar to this

Output
commit 46f196203a16b448bf86e0473246eda1d46d1273
Author: username-2 <email-2>
Date: Mon Dec 14 07:32:45 2015 -0400

    Commit details

commit 66e506853b0366c87f4834bb6b39d941cd034fe3
Author: username1 <email-1>
Date: Fri Nov 27 20:24:45 2015 -0500

Commit details

The log shows all the commits made to the given project’s repository, so your commits will be mixed it with the commits made by others. For projects that have an extensive history of commits by multiple authors, you’ll want to specify yourself as author in the command:

git log --author=your-username

Now if you know the number of commits you’ve made on the branch (just count it) that you want to rebase, you can simply run the git rebase command like so:

git rebase -i HEAD~x

e.g.

git rebase -i HEAD~8

If, however, you don’t know how many commits you have made on your branch, you’ll need to find which commit is the base of your branch, which you can do by running the following command:

git merge-base new-branch master

This command will return a long string known as a commit hash, something that looks like this:

Output
66e506853b0366c87f4834bb6b39d341cd094fe9

We’ll use this commit hash to pass to the git rebase command:

git rebase -i 66e506853b0366c87f4834bb6b39d341cd094fe9

For either of the above commands, your command-line text editor will open with a file that contains a list of all the commits in your branch, and you can now choose whether to squash commits or reword them.

Now after running git rebase -i HEAD~8 the follwoing editor will open in the Terminal and this is where I have to choose which commit to Squash and which ones to Pick

When we squash commit messages, we are squashing or combining several smaller commits into one larger one.

In front of each commit you’ll see the word “pick,” so your file will look similar to this if you have two commits:

GNU nano 2.0.6 File: …username/repository/.git/rebase-merge/git-rebase-todo
pick a1f29a6 Adding a new feature
pick 79c0e80 Here is another new feature


# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))

Now, for each line of the file you should replace the word “pick” with the word “squash” to combine the commits: And these lines will be arranged top to bottom like so, the most recent one (i.e. most recent commit) at the bottom most positon. And if I want to keep the lastest commit msg, all I have to do is edit the top-most line as pick and rest of all as squash.

GNU nano 2.0.6 File: …username/repository/.git/rebase-merge/git-rebase-todo
pick a1f29a6 Adding a new feature
squash 79c0e80 Here is another new feature

At this point, you can save and close the file ( Choosing the option shown in the Terminal, Control + O for writing out, then just press Enter for choosing the default file to write to and then finally Control+X to exit). After first exit, it will open the section editor inside Terminal where I should be able to edit and add the comments for my commit. So the same flow here as well. Edit inside Terminal Editor > press Control+O to write out > Press Enter to save to default file > Control+X to Exit

ISSUE – If I get Error – Git: “Cannot ‘squash’ without a previous commit” error while rebase

https://stackoverflow.com/a/51516360/1902852

Why it happened in my case was that, you cannot squash older commits onto a new commit. Here is an example say you have 3 commits:

pick 01mn9h78 The lastest commit
pick a2b6pcfr A commit before the latest
pick 093479uf An old commit i made a while back

Now if you say git rebase -i HEAD~3 and you do something like

pick 01mn9h78 The lastest commit
s a2b6pcfr A commit before the latest
s 093479uf An old commit i made a while back

This will result in the error :

error: cannot 'squash' without a previous commit You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'. Or you can abort the rebase with 'git rebase --abort'.

Solution :

When squashing commits , you should squash recent commits to old ones not vice versa thus in the example it will be something like this :

So put the ‘squash’ or ‘s’ word before the latest comment and ‘pick’ word before the oldest one

s 01mn9h78 The lastest commit
s a2b6pcfr A commit before the latest
pick 093479uf An old commit i made a while back

Now the FINAL step of actually pushing or updating the PR

Once you perform a rebase, the history of your branch changes, and you are no longer able to use the git push command because the direct path has been modified.

And you can check that by doing a git status You will get

Your branch and 'origin/master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

nothing to commit, working tree clean

We will have to instead use the –force or -f flag to force-push the changes, informing Git that you are fully aware of what you are pushing.

At this point, we should ensure that we are on the correct branch by checking out the branch we are working on:

git checkout new-branch

Output
Already on 'new-branch'

Now we can perform the force-push:

git push -f

I could also do below, assuming I am in master branch, and all my squashing activities were in master branch

git push origin master --force

And now if I go to the exiting PR in Github, I will see the same PR has got fully updated with my latest changes, with just a single commit.

Note, all these squashing activities could have been done by the Repo’s Manager as well. The repository’s manager can squash all the commits in a pull request into a single commit by selecting “Squash and merge” on a pull request.

ISSUE – How to squash commits after the pull request has been opened ? That is, after I have created a PR, then squash my commits in my local machine and then when I go to the PR of the upstream Repo, I still see all the committs that were there previously.

Solution – (the below will save you many times)

The easiest way to squash all of these changes is probably start by resetting your current branch back to the upstream master branch:

$ git reset upstream/master

The magical thing abuout the above command is, this will reset the repository, but not your working directory, to the state of the upstream/master branch. Since it doesn’t modify the state of your working directory, this means that all your changes are preserved, but not the commit history. At this point, we see:

\$ git status
[...]
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

    modified:   app/server.go
    modified:   smtp.go

no changes added to commit (use "git add" and/or "git commit -a")

Now we can create a new commit:

$ git add -u
$ git commit

Now you have a single commit on top of the upstream master branch. You would then force push this to your own master branch, which would update the PR.

(NB: if you’re worried about screwing something up or losing your changes or anything like that, either work on a new branch, or just make a local copy of your working directory and work on that instead.)

Pulling the latest update from a specific branch

The “pull” command is used to download and integrate remote changes.

The target (to which branch the data should be integrated into) is always the currently checked out HEAD branch.

The source (from which branch the data should be downloaded from) can be specified in the command’s options.

Before using git pull, make sure the correct local branch is checked out. Then, to perform the pull, simply specify which remote branch you want to integrate. Assuming I am in ‘master’ branch in my local machine, and I want to incorporate changes from a remote repository’s ‘dev’ branch into the local machine’s branch.

git checkout dev
git pull origin dev

The branch-name option can be omitted, however, if a tracking relationship with a remote branch is set up. In most cases, however, your local branch will already have a proper tracking connection with a remote branch set up. This configuration provides default values so that the pull command already knows where to pull from without any additional options:

git pull

It’s often clearer to separate the two actions git pull does. The first thing it does is update the local tracking branch that corresponds to the remote branch. This can be done with git fetch.

The second is that it then merges in changes, so in its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.

More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With — rebase, it runs git rebase instead of git merge.

Patient safety assistant

Check your symptom safely

Hi, I am RX Symptom Navigator. I can help you understand what to read next and what warning signs need care.
Warning: Do not use this in emergencies, pregnancy, severe illness, or as a substitute for a doctor. For children or teens, use with a parent/guardian and clinician.
A rural-friendly guide: warning signs, when to see a doctor, related articles, tests to discuss, and OTC safety education.
1 Symptom 2 Severity 3 Safe guidance
First safety question

Is there chest pain, breathing trouble, fainting, confusion, severe bleeding, stroke-like weakness, severe injury, or pregnancy danger sign?

Choose quickly

Browse by body area
Start here: Write or select a symptom. The guide will show warning signs, doctor guidance, diagnostic tests to discuss, OTC safety education, and related RX articles.

Important: This tool is educational only. It cannot diagnose, treat, or replace a doctor. OTC information is not a prescription. In an emergency, contact local emergency services or go to the nearest hospital.

Doctor visit helper

Prepare before seeing a doctor

A simple rural-patient checklist to help you explain symptoms clearly, ask better questions, and avoid unsafe self-treatment.

Safety note: This is not a prescription or diagnosis. For severe symptoms, pregnancy danger signs, children with serious illness, chest pain, breathing difficulty, stroke-like weakness, or major injury, seek urgent care.

Which doctor may help?

Start with a registered doctor or the nearest qualified health center.

What to tell the doctor

  • Write when the problem started and how it changed.
  • Bring old prescriptions, investigation reports, and current medicines.
  • Write allergies, pregnancy status, diabetes, kidney/liver disease, and major past illnesses.
  • Bring one family member if the patient is weak, elderly, confused, or a child.

Questions to ask

  • What is the most likely cause of my symptoms?
  • Which danger signs mean I should go to hospital quickly?
  • Which tests are necessary now, and which can wait?
  • How should I take medicines safely and what side effects should I watch for?
  • When should I come for follow-up?

Tests to discuss

  • Vital signs: temperature, pulse, blood pressure, oxygen saturation
  • Basic physical examination by a clinician
  • CBC, urine test, blood sugar, or imaging only when clinically needed

Avoid these mistakes

  • Do not use antibiotics, steroid tablets/injections, or strong painkillers without proper medical advice.
  • Do not hide pregnancy, kidney disease, ulcer, allergy, or blood thinner use.
  • Do not delay emergency care when danger signs are present.

Medicine safety and first-aid guide

This section is for patient education only. It does not replace a doctor, pharmacist, or emergency care.

Safe first steps

  • Avoid heavy lifting, sudden bending, and prolonged bed rest.
  • Use comfortable posture and gentle movement as tolerated.
  • Discuss physiotherapy, X-ray, or MRI only when clinically needed.

OTC medicine safety

  • For mild back pain, pain-relief medicine may be discussed with a doctor or pharmacist.
  • Avoid repeated painkiller use if you have kidney disease, stomach ulcer, uncontrolled blood pressure, or are taking blood thinners.

Avoid these mistakes

  • Do not start antibiotics without a proper medical decision.
  • Do not use steroid tablets or injections casually for quick relief.
  • Do not delay emergency care because of home remedies.

Get urgent help if

  • Back pain with leg weakness, numbness around private area, loss of urine/stool control, fever, cancer history, or major injury needs urgent care.
Medicine names, dose, and timing must be decided by a qualified clinician or pharmacist after checking age, pregnancy, allergy, other diseases, and current medicines.

For rural patients and family caregivers

Patient health record and symptom diary

Write your symptoms, medicines already taken, test results, and questions before visiting a doctor. This note stays on your device unless you print or copy it.

Doctor to discuss: Doctor / qualified healthcare provider
Tests to discuss with doctor
  • Basic vital signs: temperature, pulse, blood pressure, oxygen level if needed
  • Relevant blood, urine, imaging, or specialist tests only after clinical assessment
Questions to ask
  • What is the most likely cause of my symptoms?
  • Which warning signs mean I should go to emergency care?
  • Which tests are really needed now?
  • Which medicines are safe for my age, pregnancy status, allergy, kidney/liver/stomach condition, and current medicines?

Emergency warning signs such as chest pain, severe breathing difficulty, sudden weakness, confusion, severe dehydration, major injury, or loss of bladder/bowel control need urgent medical care. Do not wait for online information.

Safe pathway to proper treatment

Back pain care roadmap

Use this simple roadmap to understand the next safe steps. It is educational and does not replace examination by a doctor.

Go to emergency care if you notice:
  • New leg weakness, numbness around private area, or loss of bladder/bowel control
  • Back pain after major injury, fever, unexplained weight loss, cancer history, or severe night pain
Doctor / service to discuss: Orthopedic/spine specialist, physical medicine doctor, physiotherapist under guidance, or qualified clinician.
  1. Step 1

    Check danger signs first

    If danger signs are present, seek emergency care and do not wait for online information.

  2. Step 2

    Record the symptom story

    Write when symptoms started, severity, medicines already taken, allergies, pregnancy status, and test results.

  3. Step 3

    Visit a qualified clinician

    A doctor, nurse, or qualified healthcare provider can examine you and decide which tests or treatment are needed.

  4. Step 4

    Do only useful tests

    Discuss neurological examination first. X-ray or MRI may be needed only when red flags, injury, nerve weakness, or persistent severe symptoms are present.

  5. Step 5

    Follow up and return early if worse

    If symptoms worsen, new warning signs appear, or treatment is not helping, return for review quickly.

Rural patient practical tips
  • Take a written symptom diary and all previous prescriptions/test reports.
  • Do not hide medicines already taken, even herbal or over-the-counter medicines.
  • Ask which warning signs mean urgent referral to hospital.
  • Avoid forceful massage or bone-setting when there is weakness, injury, fever, or nerve symptoms.

This roadmap is for education. A real diagnosis and treatment plan requires history, examination, and clinical judgment.

RX Patient Help

Ask a health question safely

Write your symptom story. A health professional or site editor can review it before any answer is prepared. This box is not for emergency care.

Emergency first: Severe chest pain, breathing trouble, unconsciousness, stroke signs, severe injury, heavy bleeding, or rapidly worsening symptoms need urgent local medical care now.

Frequently Asked Questions

Now after running git rebase -i HEAD~8 the follwoing editor will open in the Terminal and this is where I have to choose which commit to Squash and which ones to Pick When we squash commit messages, we are squashing or combining several smaller commits into one larger one. In front of each commit you’ll see the word “pick,” so your file will look similar to this if you have two commits:GNU nano 2.0.6 File: …username/repository/.git/rebase-merge/git-rebase-todo pick a1f29a6 Adding a new feature pick 79c0e80 Here is another new feature# Rebase 66e5068..79c0e80 onto 66e5068 (2 command(s))Now, for each line of the file you should replace the word “pick” with the word “squash” to combine the commits: And these lines will be arranged top to bottom like so, the most recent one (i.e. most recent commit) at the bottom most positon. And if I want to keep the lastest commit msg, all I have to do is edit the top-most line as pick and rest of all as squash.GNU nano 2.0.6 File: …username/repository/.git/rebase-merge/git-rebase-todo pick a1f29a6 Adding a new feature squash 79c0e80 Here is another new featureAt this point, you can save and close the file ( Choosing the option shown in the Terminal, Control + O for writing out, then just press Enter for choosing the default file to write to and then finally Control+X to exit). After first exit, it will open the section editor inside Terminal where I should be able to edit and add the comments for my commit. So the same flow here as well. Edit inside Terminal Editor > press Control+O to write out > Press Enter to save to default file > Control+X to ExitISSUE - If I get Error - Git: “Cannot 'squash' without a previous commit” error while rebase https://stackoverflow.com/a/51516360/1902852 Why it happened in my case was that, you cannot squash older commits onto a new commit. Here is an example say you have 3 commits:pick 01mn9h78 The lastest commit pick a2b6pcfr A commit before the latest pick 093479uf An old commit i made a while backNow if you say git rebase -i HEAD~3 and you do something likepick 01mn9h78 The lastest commit s a2b6pcfr A commit before the latest s 093479uf An old commit i made a while backThis will result in the error :error: cannot 'squash' without a previous commit You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'. Or you can abort the rebase with 'git rebase --abort'.Solution :When squashing commits , you should squash recent commits to old ones not vice versa thus in the example it will be something like this : So put the 'squash' or 's' word before the latest comment and 'pick' word before the oldest ones 01mn9h78 The lastest commit s a2b6pcfr A commit before the latest pick 093479uf An old commit i made a while backNow the FINAL step of actually pushing or updating the PR Once you perform a rebase, the history of your branch changes, and you are no longer able to use the git push command because the direct path has been modified. And you can check that by doing a git status You will getYour branch and 'origin/master' have diverged, and have 1 and 2 different commits each, respectively. (use "git pull" to merge the remote branch into yours)nothing to commit, working tree cleanWe will have to instead use the --force or -f flag to force-push the changes, informing Git that you are fully aware of what you are pushing. At this point, we should ensure that we are on the correct branch by checking out the branch we are working on: git checkout new-branchOutput Already on 'new-branch'Now we can perform the force-push: git push -f I could also do below, assuming I am in master branch, and all my squashing activities were in master branch git push origin master --force And now if I go to the exiting PR in Github, I will see the same PR has got fully updated with my latest changes, with just a single commit. Note, all these squashing activities could have been done by the Repo's Manager as well. The repository's manager can squash all the commits in a pull request into a single commit by selecting "Squash and merge" on a pull request.ISSUE - How to squash commits after the pull request has been opened ? That is, after I have created a PR, then squash my commits in my local machine and then when I go to the PR of the upstream Repo, I still see all the committs that were there previously. Solution - (the below will save you many times) The easiest way to squash all of these changes is probably start by resetting your current branch back to the upstream master branch:$ git reset upstream/masterThe magical thing abuout the above command is, this will reset the repository, but not your working directory, to the state of the upstream/master branch. Since it doesn't modify the state of your working directory, this means that all your changes are preserved, but not the commit history. At this point, we see:\$ git status [...] Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory)modified: app/server.go modified: smtp.gono changes added to commit (use "git add" and/or "git commit -a")Now we can create a new commit:$ git add -u $ git commitNow you have a single commit on top of the upstream master branch. You would then force push this to your own master branch, which would update the PR. (NB: if you're worried about screwing something up or losing your changes or anything like that, either work on a new branch, or just make a local copy of your working directory and work on that instead.)What’s the difference between git fetch and git pull?

Before we talk about the differences between these two commands, lets stress their similarities: both are used to download new data from a remote repository. git fetch really only downloads new data from a remote repository — but it doesn’t integrate any of this new data into your working files. It fetches all of the branches from the repository. This also downloads all of the required commits and files from the other repository. git pull origin master git fetch doesn’t integrate any…

References

Add references, clinical guidelines, textbooks, journal articles, or trusted medical sources here. You can edit this area from the RX Article Professional Blocks panel.