Live data from Hacker News

A Git client for simultaneous branches on top of your existing workflow

gitbutler.com

31–40 of 119 posts

Re: A Git client for simultaneous branches on top of your existing workflow

#31
post #23

Edit: I now realize much (most?) of this already exist as part of the temporarily hidden Timeline feature in GitButler: https://docs.gitbutler.com/features/timeline Now we just need automatic (possibly virtual[1]]) commits that get created whenever one does a refactoring or other wide, sweeping tool assisted changes and soon my skills as dev archeologist would either become less valuable (because everyone can see wha…

Don't know if that's what you're looking for but JetBrains tools have a Local History that saves all your local edits. It also notes whether unit tests where passing/failing at that point and let's you revert separate hunks.

Re: A Git client for simultaneous branches on top of your existing workflow

#32
post #7
post #6

I started using this yesterday. I'm a little unsure how to pull multiple real branches into my workspace. It'd be nice if I could have a virtual branch overlay a real branch so that I could continue working with both the advantage of GitButler and maintain productivity with colleagues that don't use it. As it stands right now, I'm a bit unclear on how to operate with others who use the old fashioned branching strateg…

You should be able to do this pretty easily. We list your other local and remote branches in the sidebar. If you apply them, they are essentially converted into virtual branches (remote targets too, I believe)

I think I got it working today. Not sure what I was doing wrong before.

Also, you I recommend that you add the capability to pull different hunks out of the commit, and separate/unsquash them, or even move them to different branches. The UI is begging me to drag parts of the commit out. I can squash commits, but it doesn't seem like I can do the opposite.

Use Case: Just now I made a change to a config file, and a build tool also updated the version in this same config file. I want to split the change out.

Using the CLI to split the commit, I would do this:

  git add -p .              # partial stage
  s                               # for each hunk
For splitting the hunk into a branch, I would do this:

  git checkout -b new-branch-name
  git reset HEAD^                 # if I already staged it
  git add -p
  s                               # for each hunk
Using Magit, splitting out the commit:

  M-x magit-status
  TAB                             # on the file diff
  s                               # per hunk
  e                               # when I need to refine it manually
Using Magit, to move hunks to a different branch:

  M-x magit-status
  TAB                             # on the file diff
  b c                             # new branch
  
  b b                             # as needed, switch branches
Again, want to thank you for you work here. It's really nice, I already am getting my team onboarded to it.

Re: A Git client for simultaneous branches on top of your existing workflow

#33

There's a very similar feature which allows you to checkout multiple branches from a single repo, and comes out of the box with git. Try 'git worktree' https://git-scm.com/docs/git-worktree

One of the first comments was this, and there is a longer answer to why this is different if you’re interested.

Short answer is that worktrees dont exist in the same working directory like virtual branches do.

Re: A Git client for simultaneous branches on top of your existing workflow

#34
Not sure this is something I need. One thing I do need though, maybe someone knows a solution:

Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push.

What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I have to temporarily rewind the branch to remove them, push, then cherry-pick them again.

It's all a bit awkward and I would love a tool that maintains a kind of "virtual branch" that isn't shown but is automatically re-based on top every time I make a commit, maybe letting me resolve conflicts or even telling me ahead of time if I've created one, before committing.

Someone must have already solved this, or am I doing it all wrong?

Re: A Git client for simultaneous branches on top of your existing workflow

#35

Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…

It depends on the kinds of changes you mean. The kinds of local changes I have are just env variables that allow the software to run locally a little bit differently than in the production environment. I'm able to do this by using a .env file and a library for my languages of choice that read a .env file if it's there, but use defaults that make sense for prod when it's not there. Then the .env file is gitignored so it doesn't make its way over to the production environment.

Each developer can modify their .env however they want without having to make any changes visible to git.

Re: A Git client for simultaneous branches on top of your existing workflow

#36

Not sure this is something I need. One thing I do need though, maybe someone knows a solution: Often I find myself maintaining a handful of "local" changes. I make some changes that only make sense in my local environment, that I don't want to push. What I end up doing is maintaining these changes as a commit, committing on top of them, and using `git rebase -i` to periodically move them up. Then before I push, I hav…

It sounds like a project structure issue where local environment config that shouldn't be tracked is (or a lack of optional additional config that could be specified locally). Or maybe I'm misunderstanding the sort of change you're talking about.

Re: A Git client for simultaneous branches on top of your existing workflow

#37
post #30
post #25

'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…

Im not following you. What do you mean by “don’t use other tooling”?

I think many developers don't want to have to jump to another tool. Myself, I've found the VS Code git client "good enough" (even though I have a Git Tower license). Are there plans for extensions for the tools that support them?

Re: A Git client for simultaneous branches on top of your existing workflow

#38
post #30
post #25

'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…

Im not following you. What do you mean by “don’t use other tooling”?

> Quick warning. You cannot use both GitButler virtual branches and normal Git branching commands at the same time, you will have to "commit" to one approach or the other.

& see the description of 'the integration commit' for some detail of how they make it work:

https://docs.gitbutler.com/features/virtual-branches/integra...

Basically anything you do with `git` (or another GUI) will get blown away by GitButler; or if you change branch away from it then it will stop working.

Re: A Git client for simultaneous branches on top of your existing workflow

#39
post #30
post #25

'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…

Im not following you. What do you mean by “don’t use other tooling”?

GitButler will literally not work when you use raw git, or other tools.

Re: A Git client for simultaneous branches on top of your existing workflow

#40
post #30
post #25

'Virtual branches' is a nice idea, but I think the 'don't use other tooling' caveat probably makes it a no-go for me. It's not exactly the same, but since it's how I achieve the same goal currently, I wish it were implemented instead as automatic management of fork-points & rebasing the currently 'active' branch; even if there isn't one you consider 'active' so you want this merge, there still effectively is as soon…

Im not following you. What do you mean by “don’t use other tooling”?

[deleted]
Post reply on HN