2

Generally whenever i want to push in the changes to remote Git i follow thee steps:

git stash
git pull
git stash pop
//Resolve conflicts if any
git push

However i have also seen my teammates doing the following:

git pull --rebase
//Resolve conflicts if any
git push

I just want to know is there anything beneficial over one another. Or even if there is any other approach that is good.

Prasanna
  • 10,956
  • 2
  • 28
  • 40

2 Answers2

4

It depends on your needs: rebase produces a linear history while pull could lead to merge commits. I's described in detail on that answer: https://stackoverflow.com/a/804178/520162

And your approach is only equivalent to git pull --rebase as long as you didn't commit anything since your last pull.


Side Note:

If you're using Git really that way, you're using it wrong. It's not like SVN where you have to ensure that your repo is in sync with an upstream repo before you could commit.

The usual Git workflow is:

  • fetch upstream
  • tell your story (i.e. do a bug fix, an improvement, whatever; do some commits)
  • once you're done it's time to fetch upstream again
  • merge or rebase your changes into upstream
  • push to upstream

Maybe you should browse a bit through Git for beginners: The definitive practical guide

Community
  • 1
  • 1
eckes
  • 64,417
  • 29
  • 168
  • 201
0

You want to avoid rebases. This applies mainly to permanent branches. Topic branches may use either.

Another thing to add is

git config --global push.default current

This ensures you push only the current branch when you issue the push command.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141