Bring your feature branch up to date with master. Deploying from Git branches adds flexibility. Bring your branch up to date with master and deploy it to make sure everything works. If everything looks good the branch can be merged. Otherwise, you can deploy your master branch to return production to its stable state.

Update-branch.md

Updating a feature branch

First we'll update your local master branch. Go to your local project and check out the branch you want to merge into (your local master branch)

$ git checkout master

Fetch the remote, bringing the branches and their commits from the remote repository. You can use the -p, --prune option to delete any remote-tracking references that no longer exist in the remote. Commits to master will be stored in a local branch, remotes/origin/master

$ git fetch -p origin

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".

$ git merge origin/master

Check out the branch you want to merge into

$ git checkout <feature-branch>

Merge your (now updated) master branch into your feature branch to update it with the latest changes from your team.

$ git merge master

Depending on your git configuration this may open vim. Enter a commit message, save, and quit vim:

1. Press a to enter insert mode and append text following the current cursor position.
2. Press the esc key to enter command mode.
3. Type :wq to write the file to disk and quit.

This only updates your local feature branch. To update it on GitHub, push your changes.

$ git push origin <feature-branch>

thanks, really help me a lot😊

is this different from executing git pull origin master in our feature branch?

@pablocar80 I think this will only update the master branch, not your feature branch. I'm also not sure about this.

Handy I always come back to this one for reference :)

Saved my life thanks!

@pablocar80 same actually. Pull is internally fetch followed by a merge.

git pull = git fetch + git merge.
I think we can use "git pull origin master" for the local master branch, to stay updated with the remote master branch.
Then we can checkout to the feature branch on to which, we can merge the work of the local master.

@pablocar80 @tavisca-tgoyal yes, this simplifies the first couple of steps though, so you don't have to switch branches at all

@BharathKoneru471 @varunmathuria can I do git pull origin master directly from my feature branch? If so what happens exactly? Does it update both my feature and local master branches?

Awesome, thanks!

@BharathKoneru471 @varunmathuria can I do git pull origin master directly from my feature branch? If so what happens exactly? Does it update both my feature and local master branches?

git pull origin master will pull changes from the origin remote master branch and merge them to the local checked-out branch.

I always come back to this. Thanks!

Great explanation, thanks!

thank you for this ❤️

Love it , works just the way we need it

Thanks well written, to the point!

Thank you very much 👍

Thanks! (I didn't have access to my account when I (ie someone) sent this??)

Thanks!

Thank you for this.

is there way to update automatically using yml code

Thanks a lot. Great explanation 👍

Thanks for this explanation

Thanks a lot ...really appreciated your efforts

Is this the same as rebasing?

@nrowley71115

Rebase is generally not recommended if the branch is already on the remote.

Rebasing rewrites the git history, which means you'll need to use the force option when pushing (since the branch is already on the remote).
Additionally, if there are multiple ppl are working on the same branch, this is error-prone and can lead to conflicts when others pull the branch.
Moreover, in a project with a CI/CD process, rebasing can lead to a cascade of issues.

Saved my life thanks

It's not always convenient to switch back to main (or master) as occasionally a feature branch may have changes which will necessitate stashing before the switch. (turning the OP into roughly git stash && git checkout master && git pull && git checkout - && git stash pop && git merge master (yikes)

I tend to prefer the simpler equivalent which avoids all that:

git fetch origin master
git merge origin/master

Disclaimer: if you have changes which would have prevented a switch to main in the first place you'll still have to deal with them of course - just won't have to do quite so many steps beforehand