2

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.

kevin0110w
  • 43
  • 3

3 Answers3

1

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.

matt
  • 515,959
  • 87
  • 875
  • 1,141
0

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.

Gaël J
  • 11,274
  • 4
  • 17
  • 32
  • How would this be any different to `git pull --rebase origin/main` used in step 5? – deepakchethan Jun 06 '21 at 23:21
  • OP says _sourcetree seems to make me want to pull from origin/branch-1_ thus I guess this is not the command used in step5 or it confuses SourceTree for some reason – Gaël J Jun 07 '21 at 07:27
  • @GaëlJ That's merely the OP's failure to understand the SourceTree interface. – matt Jun 07 '21 at 20:38
0

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.

eftshift0
  • 26,375
  • 3
  • 36
  • 60
  • That easily risks _pushing_ unwanted changes directly to origin/main. What is the rest of the workflow for integrating changes? – AD7six Jun 06 '21 at 22:13
  • Not _easily_ because if you only try running `git push` git will complain that the name of your local branch and the upstream branch are not the same and it won't push, actually... but it is indeed better to explain that pushing should be done on the remote feature branch. Let me add it. – eftshift0 Jun 06 '21 at 22:28
  • That does not match my experience/understanding. Do you have a reference for `git will complain that the name of your local branch and the upstream branch are not the same and it won't push`? Trying just now that’s not what I observered, I was unimpeded `git push`Ing from myfeature1 (to origin/main). – AD7six Jun 06 '21 at 22:42
  • @AD7six surely it's a question of what you specify on the first push? If you `git push -u origin my-feature1` you establish the tracking and now `git push` does the right thing. – matt Jun 06 '21 at 23:04
  • Actually, I did try too before posting. `fatal: The upstream branch of your current branch does not match the name of your current branch. To push to the upstream branch on the remote, use.... etc etc`. It also asks to check for `push.default` in `git help.config`. https://stackoverflow.com/questions/24864700/fatal-the-upstream-branch-of-your-current-branch-does-not-match-the-name-of-you – eftshift0 Jun 06 '21 at 23:04
  • @matt what happens then if you try to use `git pull`? Because it sounds like the upstream got changed and so you will need to specify which branch to pull from. – eftshift0 Jun 06 '21 at 23:06
  • I never say git pull. – matt Jun 06 '21 at 23:10
  • @matt `surely it's a question of what you specify on the first push?` My point is what happens if you do not explicitly specify where to push to, given the branch config is to push to master. – AD7six Jun 07 '21 at 07:48
  • @eftshift0 I think it's important to realise, and call out, that doing it the way this answer describes configures the tracking branch to pull _and push_ to master. The only thing preventing a push to master working is the setting for `push.default` ([example](https://gist.github.com/AD7six/6ec00969cf6d70f91b73e1941d0d1c27)) or personal/learned git habits. Atm it's akin to juggling knives - you might not have been cut personally, but it sure seems like a risk :) I'd suggest to use `git checkout --no-track -b my-feature origin/main`. – AD7six Jun 07 '21 at 07:54