search

ACCESS-NRI / access-hive.org.au

Documentation hub for the Earth System models, ACCESS, and their community
https://access-hive.org.au/
8 stars 11 forks source link

Jasmeen/update bom logo 727 #738

Closed KAUR1984 closed 2 weeks ago

KAUR1984 commented 2 weeks ago

Fixes the issue #727.

github-actions[bot] commented 2 weeks ago

PR preview :---: ⚠️ There was an error in the pr-preview deployment. For more information, please check the Actions tab. 2024-08-28 15:54 AEST

KAUR1984 commented 2 weeks ago

Thanks @atteggiani ! I haven't tweaked the history of branch commits. I did some pulls (from development and main) and pushes, and that's what it seems to be reflecting :)

atteggiani commented 2 weeks ago

Thanks @atteggiani ! I haven't tweaked the history of branch commits. I did some pulls (from development and main) and pushes, and that's what it seems to be reflecting :)

I see, the branch only needs to be rebased to development.

KAUR1984 commented 2 weeks ago

Thanks Davide! I really like the non-destructive way of handling commits - using git merge, would not use git rebase unless I absolutely have to. Very happy to discuss it a bit more in our discussion :) Happy to leave this PR open till then :)

atteggiani commented 2 weeks ago

Thanks Davide! I really like the non-destructive way of handling commits - using git merge, would not use git rebase unless I absolutely have to. Very happy to discuss it a bit more in our discussion :) Happy to leave this PR open till then :)

I am not talking about the way (merge/rebase) to add commits from feature branches (like your jasmeen/update-bom-logo-727 to the development branch. We've been using merge-commits for that and is completely fine.

The jasmeen/update-bom-logo-727 is not up to date with development. This means that there are commits in developments that were added after jasmeen/update-bom-logo-727 was created (the commits are not included in the history of jasmeen/update-bom-logo-727). In general, it is always better to rebase the feature branches with development before merging to it (with a merge-commit), so we avoid any conflicts and make sure we are on track with development. In this case we should rebase and not merge because we don't want an additional merge-commit to be created for commits that are already present inside development.

Hopefully this explanation made sense. Please let me know if you need further clarification :)