GitFiend
missing rebase feature
I'm not ready to implement it in GitFiend as it's not something we use where I work.
I would be keen to hear what your rebase workflow is and why, so I can think about adding it.
In GitFiend right now you can undo unpushed commits. You can use this to rewrite commit history.
I'm not yet use this feature, but it can make graph look better for review and manager :D
Hi Gitfiend looks amazing. However at my company we use rebase a lot. Our workflow is as follows:
- person A commits to the master branch
- person B is working on another branch, wants to pull in the changes from master, but not have a new brach. instead, just wants those changes integrated into his/her own branch. So person B performs a rebase.
- person B rebases code with the master, and has an updated branch with their own changes on top (no new branch or merge was needed)
- at some point, person B wants to push their branch to master. He/she does a force push to have the master updated with their new changes.
Benefit of this process is that the master branch will look a lot cleaner, no constant merges and loose branches. Also all programmers can often rebase with master on their own branches (this will not constantly create new merge commits, unless there are collisions). This means that you do not get a huge merge conflict collision when a longer running branch is being merged.
I don't even understand how it would be possible to work without rebasing. Surely someone will have pushed in stuff into the trunk after you branched from it and before you're ready to merge. So whenever you're ready to merge you rebase your branch onto the head of the trunk, resolve all merge conflicts, and then you can make a merge request for your branch to be merged onto the trunk.
I don't even understand how it would be possible to work without rebasing. Surely someone will have pushed in stuff into the trunk after you branched from it and before you're ready to merge.
Just merge from trunk regularly into your branch and fix any merge conflicts early rather than when you make your merge request. I think this is safer and faster than rebasing, but results in more commits.
Just merge from trunk regularly into your branch and fix any merge conflicts
That is what rebasing does; you pull in commits from trunk and add your own commits on top. Or are you suggesting to keep your own half-way done commits inbetween the commits you get from trunk???
I think you should do what the project you are contributing to requires. I don't think there is one true way to use git. I think the default option in git (merge, not rebase) is reasonable.
I think you should do what the project you are contributing to requires. I don't think there is one true way to use git. I think the default option in git (merge, not rebase) is reasonable.
Huh? I didn't try to get anyone to change how anyone does anything, nor claiming there's only one way of doing something. I'm trying to clarify, how is your branch (in your way of working) supposed to look pre-merge-request if not branching off of the head of the trunk? Is it branching off of an earlier point, and therefore risk causing merge conflicts? Or if it is supposed to be branching off of the head of the trunk then how do you get there if not by rebasing your branch onto that trunk head?
You branch when you when you create the branch. You merge from main into your branch as you go. The branch I am working on has the latest changes from main before starting a merge request. What part is not clear?
are you suggesting to keep your own half-way done commits inbetween the commits you get from trunk???
Yes, I think this is fine.
What part is not clear?
The part not clear was where your commits are in relation to others. If I understood correctly you spread out your implementation over lots of random mini-commits inbetween commits merged in from trunk, instead of organizing your commits so that one commit would be for one feature/fix/whatever at the end of the trunk. Sounds like it would be horrible to review such a MR with random commits with partially implemented features, but if it works for someone then sure, why not. In any case, it would be wonderful if GitFiend would support rebase, since it's so incredibly useful for making clean commit trees. :)
It's pretty rare that I care about individual commits when I review a merge request. I'm also more concerned about junior devs making merge conflict/rebase/force push mistakes than I am about clean commit trees. That being said, I want to support more workflows and I am working on rebase features.