Skip to content

Conversation

@Muszkal
Copy link

@Muszkal Muszkal commented Feb 14, 2025

When working on a branch, You either push a branch to the remote(which might exist or not) with the same name or a new branch completely.
I don't think there are situations where you push to an existing remote branch that is different from the one you are on currently.

This solution gives the flexibility to push to any branch you want.

My usecase:
I develop on "develop" branch, than push to "feature" branch.
This is useful when dealing with bugs or small things.

before:
image

after:
image

and with new branch:

before:
image

after:
image

@love-linger
Copy link
Collaborator

Instead, I recommend creating the corresponding branch locally first, and then pushing it directly. For example: use a workflow tool such as git-flow. Always ensuring that the local branch name matches the remote branch name it tracks (the upstream of local branch) helps to understand the entire repository.

Imagine a situation where you have a develop branch both locally and remotely. If you add new changes directly to it, and then push it directly to another new remote branch feature/xxxx and then wait for the maintainer to merge into the develop branch. At this time, there are new requirements to be developed on the develop branch. Do you need to reset the develop branch to the original revision (considering that the previous feature/xxxx may not be merged into the develop branch by the maintainer for some reason)?

@Muszkal
Copy link
Author

Muszkal commented Feb 17, 2025

If after I pushed develop into feature/xxx, I need to develop something on the develop branch, then I would reset to remote.
When starting to develop something new or a bug fix, always start from resetting to remote.

If after pushing feature/xxx, I need to change something then I would checkout feature/xxx

But a new feature is not my use case. The use case here is mostly one-line bug fixes. something I need to investigate on the develop branch, and I encounter something I want to fix or find an issue.

@Muszkal
Copy link
Author

Muszkal commented Feb 17, 2025

There are more use cases for the ability to push to any branch I chose.
For example if i have a feature/xxx branch and I decide to try something on it, than I would create a feature/newxxx branch to test and if the test is successful than I would push feature/newxx to feature/xxx

@love-linger
Copy link
Collaborator

There are more use cases for the ability to push to any branch I chose. For example if i have a feature/xxx branch and I decide to try something on it, than I would create a feature/newxxx branch to test and if the test is successful than I would push feature/newxx to feature/xxx

Why not merge/reset/rebase the feature/newxx branch locally first and then push the merged/reset/rebase feature/xxx to the remote?

@Muszkal
Copy link
Author

Muszkal commented Feb 18, 2025

Well, I am not saying it is not possible. I would like flexibility so that different people with different workflows have a good experience. This change gives that flexibility without taking out something else.

On a side note, Is there a discord or some form of chat for this project?

@love-linger love-linger self-assigned this Feb 21, 2025
@love-linger love-linger added the not-planned It's not planned in the future label Feb 21, 2025
@mithom
Copy link
Contributor

mithom commented Feb 28, 2025

i'm in favor with the love-linger here.
GUI's are there to make working with git easier.
Supporting bad habbits does not make git easier for beginners.
if you want all flexibility git offers, there is the CLI, or sourceTree for you. i believe that GUI makers have the duty to guide users to use their tool correct.
also an easy solution that would keep the good habbits in place is to just rename your local branch and then push, keeping the names in sync.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

not-planned It's not planned in the future

3 participants