top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration

Facebook Login
Site Registration

git rebase after a pull

+1 vote

Is it required to do a git pull before doing a git push.and is it required to do a git rebase after git pull just before git push. one of my git repo mandates the above wondering if there is a valid reason for this.

posted Sep 21, 2013 by Bob Wise

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

Only if your local changes have diverged. You have to either merge or rebase.
'git pull' by default does a merge, but you can force it to do a rebase: 'git pull --rebase'.

answer Sep 21, 2013 by Jai Prakash
Similar Questions
0 votes

I run across this problem quite a bit: I have a branch that I'm working on. Unfortunately for me, in order to get my code tested and built by our build servers and infrastructure (which is a requirement before it can be code reviewed and merged, plus it builds my code on platforms I don't otherwise have easy access to) I have to push it to our main git repo, since that's the only place the build infrastructure can get it from.

This means I have to publish my work-in-progress branches up to the git server, including all the false starts, backups, single-line "oops" fixes, etc. Then if I merge my branch into the master branch, all that
becomes part of the mainline of the code.

If it's a small change which is really just one thing I can just use a squash merge into master. But for larger changes what I'd like to do is clean it all up into a smaller set of well-formed commits and push
those. This sounds like a job for rebase -i.

However, I've already pushed my branch to master. I know rebasing stuff you've already pushed is considered a no-no in general, but I can't avoid it. Does anyone have suggestions for how to make this work better? Should I be rebasing to a brand new branch, then merge that to master? Just rebase directly to master? None of the above? Something else entirely?

+1 vote

I have many commits: A, B, C, ..., Z. I plan to do some housekeeping using rebase. One thing I want to do is to reorder Z to be the first commit. However, other commits will be in conflict with Z's changes. I know I can go through and interactively resolve the conflicts manually. But this is tedious and error prone. I would like to be able to mark Z's changes as authoritative while rebasing. That is, I want to tell git, "whenever a commit conflicts with Z (during this rebase operation) I want you to keep Z's changes and ignore the other." Is this possible? Is there another (hopefully better) way to accomplish what I'm trying to do?

+1 vote

There's a challenge that i'm currently facing after migration from WINCVS to GIT. The problem here is I need to pull/fetch a specific branch (and NOT clone the entire repository) from the repository to a particular location on the AIX server.

Earlier while using WINCVS this functionality was achievable using JCVSExport package as we could just checkout a particular branch and fetch the package on to the server location.
WINCVS Command : java JCVSExport -h -u abcde -p xxxxxx -d /abcd/cvs/testing -c "$REPOSITORY" -m "$PACKAGE"

I am not able to achieve the same functionality using GIT. I DO NOT want to clone the entire repository on the AIX server instead I just want to fetch/pull a specific branch contents on the server. Can someone please help me out with the solution or any possible way with which I can achieve the same functionality.

Contact Us
+91 9880187415
#280, 3rd floor, 5th Main
6th Sector, HSR Layout
Karnataka INDIA.