Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Keeping a branch up to date with master

I have a remote repository that I've pulled and am branching from. I want to keep the new branch up to date with changes done to master. I'm thinking about the workflow below, does it make sense or are there are better ways to do this?

  1. Initial branching and checkout:

    git checkout master  git pull  git checkout -b my_branch 
  2. Do some work in my_branch, then periodically:

    git checkout master  git pull  git checkout my_branch  git merge master --no-ff 

Repeat step 2 as needed, with periodic pushes to the remote my_branch.

Then when ready for a merge back:

git checkout master  git merge my_branch --no-ff 

Sound ok?

like image 551
larryq Avatar asked Nov 03 '13 22:11

larryq


People also ask

How do you check if branch is up to date with master?

git show-branch *master will show you the commits in all of the branches whose names end in 'master' (eg master and origin/master).

How do I change my branch with Master without losing changes?

Merge the changes from origin/master into your local master branch. This brings your master branch in sync with the remote repository, without losing your local changes. If your local branch didn't have any unique commits, Git will instead perform a "fast-forward".


2 Answers

You can simplify your commands:

1.

git fetch git checkout -b my_branch origin/master 

2.

git fetch git merge origin/master 

git fetch updates your remote branches, there usually is no need to have a local copy of a branch when your are not planning to work on this branch.

You can omit the --no-ff after setting git config --global merge.ff false.

git help config says:

   merge.ff        By default, Git does not create an extra merge commit when merging        a commit that is a descendant of the current commit. Instead, the        tip of the current branch is fast-forwarded. When set to false,        this variable tells Git to create an extra merge commit in such a        case (equivalent to giving the --no-ff option from the command        line). When set to only, only such fast-forward merges are allowed        (equivalent to giving the --ff-only option from the command line). 

Be aware that git pull is just a combination of git fetch and git merge.

Usually you just want git pull --rebase which is essentially git fetch plus git rebase, and creates a much cleaner history.

Is there any reason for your "periodic pushes"? If no one else is working on the same branch it would be perfectly fine, just to push after finishing everything.

like image 138
michas Avatar answered Sep 22 '22 02:09

michas


I would advise to use a rebase workflow. So instead of using git pull you should use git pull --rebase.

I would do the same with the feature branch. So instead of doing a git merge master --no-ff I would use a git rebase master. However, if the feature branch is meant to be shared with co-workers during development, then you are better off to merge the master branch periodically into the feature branch.

But to be honest, I work on a small team and if we need to work on a feature branch together and we need to get it up to date with master then we just suspend our work for a short moment (and communicate the process clearly), rebase on master and force push the feature branch. But yep, that doesn't scale for bigger teams. However, I find it much more convenient to work with a feature branch that is rebased on master instead of having to deal with merges from master.

Make sure to read this.

Git workflow and rebase vs merge questions

like image 23
Christoph Avatar answered Sep 23 '22 02:09

Christoph