Is it ok to continue on a branch if you also merge back main into it? Like, branch gets merged into main on remote, local main pull, local merge main into local branch, push branch?
So this workflow is needed if you are working on a public, i.e. multiple devs collaborating on a single branch, scenario. But it is much better to avoid this as much as possible. Usually it is a ‘scoping’ issue, where you create a branch that is too broad. For example ‘api-for-frontend’, which is a massive thing.
But let us say you absolutely have to get multiple devs on same branch, then this workflow is totally fine. There is nothing wrong in it.
In our org we prefer to delete the branch after merge. In a way it says ‘this branch is closed’. This is to encourage devs to define smaller and more logically scoped branches.
I want to take this opportunity to say that, branch is just a label on a commit, with some additional functions. Once you start focus on commits and lineage of the commits, then branches become some what irrelevant.
Aha. I was part of a project where each dev had their own long running branch for non-specific work and this was the norm, but it always felt clunky. And often resulted in merge issues.
That is a very weird setup. I have no clue why that flow is needed in the first place. Branches should be something disposable easily. What was the logic behind the setup? Any idea?
You don’t have to squash to avoid merge commits. Instead, you can git rebase main to update your branch. Effectively, this will rewrite the history of your branch, as if you had just branched from the main-branch and then instantly coded all your changes on top of that. (Well, the commit timestamps won’t change, but they will sit on top of the changes of the main-branch.)
Afterwards, you should be able to merge into main by switching to it and then running git merge--ff-only your_branch.
Because all the changes sit on top of the main-branch commits, it should be able to fast-forward. No actual merging needs to take place then. You’ve already resolved any conflicts while rebasing.
This also allows you to keep branches for longer, so long as you frequently rebase and merge back.
Is it ok to continue on a branch if you also merge back main into it? Like, branch gets merged into main on remote, local main pull, local merge main into local branch, push branch?
So this workflow is needed if you are working on a public, i.e. multiple devs collaborating on a single branch, scenario. But it is much better to avoid this as much as possible. Usually it is a ‘scoping’ issue, where you create a branch that is too broad. For example ‘api-for-frontend’, which is a massive thing.
But let us say you absolutely have to get multiple devs on same branch, then this workflow is totally fine. There is nothing wrong in it.
In our org we prefer to delete the branch after merge. In a way it says ‘this branch is closed’. This is to encourage devs to define smaller and more logically scoped branches.
I want to take this opportunity to say that, branch is just a label on a commit, with some additional functions. Once you start focus on commits and lineage of the commits, then branches become some what irrelevant.
Aha. I was part of a project where each dev had their own long running branch for non-specific work and this was the norm, but it always felt clunky. And often resulted in merge issues.
That is a very weird setup. I have no clue why that flow is needed in the first place. Branches should be something disposable easily. What was the logic behind the setup? Any idea?
Oh I know the reason, nobody knew git and had just worked alone before.
On some repositories, sure.
But better maintained repositories don’t allow merge commits (because merge commits suck), and so will have squashed (or rebased) on merge.
(If squashed) The squash will have changed commit IDs, so a long running branch rebased won’t benefit from a clean shared commit history.
So it can work, but “you’re gonna have a bad time.”
In general, git works best if branches are thrown away as soon and as often as possible.
(Edit: Good clarification in response below, added here for consistency and accuracy.)
You don’t have to squash to avoid merge commits. Instead, you can
git rebase mainto update your branch. Effectively, this will rewrite the history of your branch, as if you had just branched from the main-branch and then instantly coded all your changes on top of that. (Well, the commit timestamps won’t change, but they will sit on top of the changes of the main-branch.)Afterwards, you should be able to merge into
mainby switching to it and then runninggit merge --ff-only your_branch.Because all the changes sit on top of the main-branch commits, it should be able to fast-forward. No actual merging needs to take place then. You’ve already resolved any conflicts while rebasing.
This also allows you to keep branches for longer, so long as you frequently rebase and merge back.