DEV Community

Pull Requests: a simple workflow

Jean-Michel 🕵🏻‍♂️ Fayard on December 04, 2017

Disclaimer: I’m not a git ninja, and I’m pretty sure a lot of people have written more sophisticated things on this topic. My only qualification is...

Read full post

Ben Halpern • Dec 4 '17

Really well described. Will reference this in the future.

Jean-Michel 🕵🏻‍♂️ Fayard • Sep 7 '22

Rewrite your git history in 4 friendly commands

Salma Alam-Naylor ・ Sep 6 ・ 4 min read

#git #webdev #beginners #tutorial

Radhakrishnan • Dec 5 '17 • Edited

How does this help?

git reset --soft origin/master

Can you explain?

Jean-Michel 🕵🏻‍♂️ Fayard • Dec 5 '17 • Edited

Sure!

origin is the original project and not your fork.
since you have pulled origin/master, that commit represents the latest and greatest that the project has.
since you have merged origin/master so that you are not behind the project's latest and greatest. The commit that you did after merging contains the right working tree that you want to submit.
after git reset --soft origin/master, when you commit again, you have the exact same right working working tree BUT its direct parent will be origin/master. (1)
from the perspective of the maintainer, the git history is clean : exactly one new commit above his master branch.

(1) As the friendly manual says,

  git reset --soft <commit> # here <commit> = origin/master
    Does not touch the index file or the working tree at all 
    (but resets the head to <commit>, just like all modes do). 
    This leaves all your changed files "Changes to be committed", 
    as git status would put it.

Hope that helps :)