0

I am setting up a workflow for a team of people. There will be a main repo, and the people will be instructed to fork the repo on github, then clone it to their local machines. The process for submitting code updates will look pretty much like this:

  • git checkout -b feature_branch # and do some work on the branch

After time has passed, I would like to have the people make sure that their copy of master is up to date, and ask them to do this:

  • git commit feature_branch # to save the work they did so as not to lose it (instead of git stash)
  • git fetch upstream
  • git checkout master
  • git merge upstream/master
  • git push origin master

Questions:

How should the person then update their feature_branch with the new information, since the copy of master they forked from changed?

Is it to use git diff to see the differences between their feature branch and the new master branch and adjust their feature branch manually? Or is it to have them create a new branch off of the new master and copy and paste code from their old branch to their new branch?

Either process seems a bit clumsy/manual, but I cannot see any other way.

I have found answers that confirm the general process but do not discuss best practices of the process of updating the feature branch.

Thanks.

Community
  • 1
  • 1
ivan7707
  • 1,146
  • 1
  • 13
  • 24

2 Answers2

0

They could do git fetch origin. Then to see all the latest changes: git log -p HEAD...origin. If they are happy with the changes they then do git merge origin

Hexana
  • 1,095
  • 2
  • 12
  • 35
0

In your workflow, I can see that your team never pushes their feature branch to their fork, so they can rebase it in local to get up to date with upstream/master.

Following workflow:

Teammate working on a feature in local:

  • git checkout -b feature_branch
    • do some work
    • git commit

Teammate making its fork up to date:

  • git fetch upstream
  • git checkout master
  • git merge upstream/master
  • git push origin master

Teammate making up to date its feature (in local) with the developments from upstream:

  • git fetch upstream
  • git checkout feature_branch
  • git rebase upstream/master (or if you just did the previous step : git rebase master)

Once finished, push the feature branch and ask for a pull request from fork/feature_branch to original_repo/master, after pushing your feature_branch to your fork.

That way, you don't have to git push --force.

If you already pushed your feature to your fork, you'll have to.

topheman
  • 7,422
  • 4
  • 24
  • 33
  • if I understand correctly (from reading the git rebasing page), then will this apply the changes from upstream to my master and feature branch, then overlay my changes from my branch afterwards? – ivan7707 Oct 14 '15 at 00:59
  • The way I presented it, in the 3rd block, it will only apply upstream/master's changes to feature - the 2nd block will apply upstream/master's changes to master – topheman Oct 14 '15 at 08:08