Can someone clarify the git workflow where there's a branch on the remote?

Viewed 189

I use sourcetree.

My usual workflow is normally:

  1. fetch and pull all changes from origin/main into my local
  2. create a local branch - branch-1
  3. do the dev work
  4. commit
  5. pull (w/ rebase from origin/main)
  6. push to origin/branch-1
  7. submit PR to merge origin/branch-1 into origin/main

However, if the PR is declined and i need to make further changes, what should the process be?

I currently do the same as above, staying on local/branch-1 then re-start from 3, except sourcetree seems to make me want to pull from origin/branch-1 (at stage 5) instead of origin/main. I'm not sure that's quite right? Or should I be pulling from origin/branch-1 and origin/main or something?

Thank you.

3 Answers

if the PR is declined and i need to make further changes, what should the process be?

Stay on your feature branch. Edit, add, commit, and push again to the feature branch's remote-tracking branch. Done. The new commit is added automatically to the pull request.

So, for example, while on myfeature (and assuming its upstream has been configured to origin/myfeature, and that there's a pull request pending on it):

echo hello > test.txt
git add test.txt; git commit -mtesting
git push

If you then go to the pull request in the browser you'll see that this commit has been appended to the pull request in good order.


Other comments:

fetch and pull all changes from origin/main into my local

This might be unnecessary. You could just fetch and then start your feature branch directly on origin/main. However, you might want to say --no-track when you do, so as not to be tracking origin/main by mistake. For example:

git fetch
git switch --no-track -c myfeature origin/main

That creates branch myfeature starting from an updated main.

pull (w/ rebase from origin/main)

This is unnecessary. Again, you could fetch and then rebase your feature branch onto origin/main, but once you've pushed that's probably a bad idea, as you will now be pushing rewritten history; and there is probably no need.

If the reason for updating from the remote is that you fear a conflict, or if you want to test your feature combined with the latest state of main, it would be better to fetch and then merge origin/main into the feature branch just before pushing it.

So for example, while on myfeature:

git fetch
git merge origin/main 

Either way there is no need to leave your feature branch, and no need to say pull ever.

sourcetree seems to make me want to pull from origin/branch-1 (at stage 5) instead of origin/main

No, you can pull from any remote branch in Sourcetree. Open the Remotes category on the left, control-click on a branch, and choose "Pull from...". However, I strongly advise against using pull.

I would replace step 5 (git pull) with:

# Retrieve work done on other branches without applying it, especially it updates your origin/main
git fetch
# Rebase your work on top of origin/main
git rebase origin/main

Using pull is usually to pull data from the remote into the same branch.

I would actually skip using a local equivalent of origin/main and would use origin/main as my upstream branch:

git checkout -b my-feature1 origin/main

Then, if I later need to pull changes from upstream:

git pull -r

And when you want to push into the remote branch:

git push origin my-feature1

But this is not a very popular workflow, apparently.

Related