Hi Vicki,
  I *think* I understand what you want to achieve, which is...

   1. Create a feature branch from master which is where a dev will do 
   their work.
   2. They want to update their branch time-to-time with the latest changes 
   in master.
   3. Eventually get their feature-branch back into master.
   4. Avoid merge commits as that creates a commit with two-parents, you 
   want to keep a linear history. So essentially every "merge" will be a 

If what I've said is what you're trying to achieve then to achieve this in 
a repeatable set of steps I would do...

git checkout master
git pull
git rebase master feature-branch

In the cases you've described this is what I *believe* is happening (*please 
somebody correct me if I have this wrong*)

git checkout feature-branch (just making it clear you currently have the 
feature-branch checked out)
git fetch
git rebase origin master

...will do nothing to your feature branch, it will simply checkout master 
and fast-forward merge master to match origin/master. You would still need 
to rebase your feature branch on top of master to have your local changes 
on top of master.

git checkout feature-branch
git pull --rebase origin master

Will essentially do...
git fetch origin master - Which will update your local reference of 
origin/master with the commits from the remote, it will not touch your 
local master or your feature-branch.
git rebase origin/master - Which will replay your local feature-branch 
changes on top of origin/master, not your local master. So at this point 
your local master is actually out of date, your reference to origin/master 
is up-to-date and your feature-branch is on top of origin/master.

If you want to make sure your local master is up-to-date with the remote 
you would subsequently need to do...

git checkout master - You'll get a message saying master is behind the 
git pull - The help text when you did the "checkout master" will prompt you 
to do this, your master will fast-forward to the same commit as 



On Thursday, 14 November 2013 23:03:29 UTC, Vicki Kozel wrote:
> We've recently switched to Git and Gerrit, and are drafting the best 
> practices workflow for our development team. One thing we want to avoid is 
> "merge" commits that have two parents since if these commits fail Gerrit's 
> review it is hard to rebase them. 
> I know that "git pull" will do the "fetch" + "merge" that may create those 
> two-parent commits. Instead we recommend to do:
> on the feature branch:
> git fetch
> git rebase origin master
> or
> git pull --rebase origin master
> The problem with this last command is that it does not put my local commit 
> on top of commits from origin. So if I need to amend my last local commit - 
> I can't - since it's not on top of history any longer. To amend this commit 
> I have to run rebase --interactive, but we are trying to avoid commands 
> that are either complicated or numerous. Is there a way to run git pull 
> --rebase in such a way that my latest local commit ends up on the top of 
> commit history?
> Thank you!

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to