3 ms·

This looks cool. I'm curious if people use Git's tree view, in any form, as part of the regular workflow? If so, how? I have never found it useful, intuitive, o

This looks cool. I'm curious if people use Git's tree view, in any form, as part of the regular workflow? If so, how? I have never found it useful, intuitive, or usually readable / parsable. Not the graph drawn on the command line, certainly not Github's tree view GUI of forked projects. I've also only ever worked on a project with one or two main trunk branches (master, and maybe dev), and feature branches, and very little merging between other arbitrary branches.

apocalyptic0n3 7y ago
I use it frequently. I work mostly solo but am often force to jump around quite a bit. So I use a variation of GitLab Flow[1] and often have dozens of active feature branches going on. It's useful seeing where a branch was created against develop so I can have some idea of what's been done on that branch since I last worked on the branch I just switched to, and what to expect when I merge or rebase. [1]: https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html
juped 7y ago
If you mean the history graph, try gitk (part of the git distribution, but you may need to install a separate git-x11 or similar package).
_ZeD_ 7y ago
Onestly, I always found all git interfaces (gui or text based) from just ugly and useless to totally counterintuitive. With one exception: the only good git ui that I tolerate for its clearance is the eclipse egit plugin https://www.eclipse.org/egit/ https://www.eclipse.org/egit/
gregmac 7y ago
At work, we use feature branching extensively, and there's often somewhere between 3 and 6 active feature branches at any time. The graph view is a good way to keep track of what's going on overall, if you're watching it regularly and branch parents are within a screen or two). Just earlier today I was working on testing a new feature that depended on 3 other independent fixes (basically, bugs found while I was building the feature). I did the fixes each as an independent branch, so I could get them in faster (before my new feature is done) plus to make the code review easier. The tree view is invaluable in testing my new feature to be sure I've merged the right fixes and am doing changes in the right branches. I also use it very occasionally to isolate if and/or why a particular fix got into a specific release branch (or not). I think there's probably better ways to do this (eg using bisect) but I do it so rarely I haven't bothered to learn.
Legogris 6y ago
I use it as part of my daily flow. One example: I work on a feature, which necessitates some refactoring, maybe upgrading a dependency, and oh, while I'm in the middle of it I notice some other, unrelated things, that need changing. In order to not have to break my flow and think too much about which changes are required for what, I just commit it all on the same local branch. This then gets broken up into different branches in individual PRs.
- stevebmark 6y ago
  I don't understand what this has to do with a visual view of branches and merges
  - Legogris 6y ago
    It certainly helps me when splitting, comparing and picking changes between branches. Also to keep track of how upstreams have changed compared to my working branch before doing rebases. Oh, and re Githubs fork view (which could be improved on the UI side), is helpful when seeing if anyone else has picked up the ball on unmaintained repos. If you don't find it useful, fine, I don't think we all need to grok each others personal workflows and motivate them to each other? Maybe you can compare it to a visual file manager that visualizes your directory structure as a tree; some people find it a necessity to get an overview of their file system, some don't.

apocalyptic0n3 7y ago

I use it frequently. I work mostly solo but am often force to jump around quite a bit. So I use a variation of GitLab Flow[1] and often have dozens of active feature branches going on. It's useful seeing where a branch was created against develop so I can have some idea of what's been done on that branch since I last worked on the branch I just switched to, and what to expect when I merge or rebase. [1]: https://docs.gitlab.com/ee/topics/gitlab_flow.html https://docs.gitlab.com/ee/topics/gitlab_flow.html

juped 7y ago

If you mean the history graph, try gitk (part of the git distribution, but you may need to install a separate git-x11 or similar package).

_ZeD_ 7y ago

Onestly, I always found all git interfaces (gui or text based) from just ugly and useless to totally counterintuitive. With one exception: the only good git ui that I tolerate for its clearance is the eclipse egit plugin https://www.eclipse.org/egit/ https://www.eclipse.org/egit/

gregmac 7y ago

At work, we use feature branching extensively, and there's often somewhere between 3 and 6 active feature branches at any time. The graph view is a good way to keep track of what's going on overall, if you're watching it regularly and branch parents are within a screen or two). Just earlier today I was working on testing a new feature that depended on 3 other independent fixes (basically, bugs found while I was building the feature). I did the fixes each as an independent branch, so I could get them in faster (before my new feature is done) plus to make the code review easier. The tree view is invaluable in testing my new feature to be sure I've merged the right fixes and am doing changes in the right branches. I also use it very occasionally to isolate if and/or why a particular fix got into a specific release branch (or not). I think there's probably better ways to do this (eg using bisect) but I do it so rarely I haven't bothered to learn.

Legogris 6y ago

I use it as part of my daily flow. One example: I work on a feature, which necessitates some refactoring, maybe upgrading a dependency, and oh, while I'm in the middle of it I notice some other, unrelated things, that need changing. In order to not have to break my flow and think too much about which changes are required for what, I just commit it all on the same local branch. This then gets broken up into different branches in individual PRs.

stevebmark 6y ago
I don't understand what this has to do with a visual view of branches and merges
- Legogris 6y ago
  It certainly helps me when splitting, comparing and picking changes between branches. Also to keep track of how upstreams have changed compared to my working branch before doing rebases. Oh, and re Githubs fork view (which could be improved on the UI side), is helpful when seeing if anyone else has picked up the ball on unmaintained repos. If you don't find it useful, fine, I don't think we all need to grok each others personal workflows and motivate them to each other? Maybe you can compare it to a visual file manager that visualizes your directory structure as a tree; some people find it a necessity to get an overview of their file system, some don't.