[beermonster]

> Using git can be daunting at first. Like my good friend Chris once said, "everyone knows the happy path but the minute it gets hairy we're all screwed".

Sounds familiar. Lots of people just learn a few template use-cases, but don’t take the time to learn/study the tool. You might argue you shouldn’t need to but Git isn’t intuitive and does require investment. It comes with its own terminology; there’s no point just guessing what a branch is for e.g..

Like all powerful *nix cli tools, if you don’t you’ll shoot yourself in the foot one day. Even if you want to use a GUI interface, it’s no substitute for learning how git works behind the scenes.

Sometimes when I offer to help a colleague that’s got themselves into knots the sad thing is often they can’t even explain the problem they got into.

[jareklupinski]

> "everyone knows the happy path but the minute it gets hairy we're all screwed". Sounds familiar.

"Everybody has a plan until they get punched in the mouth."

-Mike Tyson

[KronisLV]

> Like all powerful *nix cli tools, if you don’t you’ll shoot yourself in the foot one day.

Surely we can do better than this? A tool being powerful should be no excuse for it having footguns!

For example, see "Why SQLite Does Not Use Git": https://sqlite.org/whynotgit.html

In my eyes it addresses many of the problematic bits of Git and offers alternatives to them. Admittedly, it was sad to see other VCSes like SVN die out, since there were some things that they did more clearly than Git (e.g. revision numbers), despite their other shortcomings.

Currently, for many Git is essentially forced upon them and they have to learn commands that they don't understand to use it, much like you said. If version control were easier and more intuitive, then more people would adopt it and the ones using it would be more efficient with it, rather than people messing up their repositories and others blaming them for it - even though they'd be right, that sort of elitism also doesn't help much, since clearly some mistakes are easier to make than others.

I think that most of the systems out there will eventually be improved or rewritten until finally they are both powerful and usable, even Git probably isn't immune to this. Whether the incentives to do that are there now (since GitHub, GitLab and others are already de facto within the industry) will only affect whether this is done in the next 50 or 100 years.

Here's an issue that we ran into this week:

  - at work, we have a "main" branch and a "development" branch
  - a new "feature" must be based off of "main", but eventually moved into "development", since that's what the test environments are configured against
  - thus, we have a "feature-development" branch, into which we merge "feature", to not sacrifice our ability to put "feature" back into "main" without the "development" changes, if ever needed
  - then, we merge the "development" branch into the "feature-development" branch to solve any conflicts or do any refactoring that we need to ensure that those two branches play together nicely, before merging "feature-development" into "development"
  - this week, someone did the opposite, they merged "feature-development" back into "feature", thus moving all of the "development" changes into "feature", which we can't allow
  - the solution? who knows, one option would be to force push the earlier position of a branch, thus erasing the merge commit, but force pushes are considered a bad practice
  - what we opted for in the end was having another commit that reverts the merge (through the GitLab UI), however now the history still shows that "feature" has 100+ commits in it
  - the problem that we might run into down the road now is that when we merge "feature" into "feature-development", we'll probably also carry over the revert commit, which we'll then need to revert or do something so that the "feature-development" branch doesn't have all of the "development" changes essentially removed (which may or may not be true)

All of that pain, essentially caused by one bad merge, whereas other colleagues are now also asking me about rebasing. I don't feel like i know Git well enough to be the "go to guy" and would rather just write the code i need for the features, rather than worry about the branching strategies and what colleagues have done and weird client requirements for what branches must be used as a base since there are not enough test environments. Furthermore, GitLab not having an easy way to say "i want this commit gone" is equally annoying. If they offer you to do reverts, surely they can also ensure the equivalent of a force push?

Then again, chances are that it's too early for me to say anything vaguely accurate and even so someone out there probably can solve all of it in a line or two. Nonetheless, it feels to me that an easy to use tool would expose solutions for the most common problems in an approachable way.

[masklinn]

> Surely we can do better than this? A tool being powerful should be no excuse for it having footguns!

Of course we can but they all lost the vcs wars so we’re left with git, a chainsaw you can’t shut down with hooked spikes bolted to the handle and an old “handle with care” sticker long gone unstuck and slipped under one of the shop’s cabinets.

[leokennis]

Fantastic analogy.

Personally I am not interested to learn "proper git". It's plumbing and not an end goal.

When I start working on something, I do a pull and then create a branch. Then I make edits to the files I need and save a copy of them locally.

If then something goes awry with my commit/push/MR/whatever, I delete the repo, clone it, create a new branch, using human intelligence re-apply my changes from the local copies and try again.

[xorcist]

> GitLab not having an easy way to say "i want this commit gone"

To be fair to GitLab, that would just be another way to say "force push".

Either you want the change gone from history, which makes it necessary to coordinate with everyone who has taken out a branch during that time (which is a force push) or you want the merge-and-backout to be visible in eternity (which is a revert commit). There's no way to have both, by definition.

The way to avoid screwups, in any version control system, is to have everyone actually read what they are about to persist to our shared history.

The by far most popular process to enforce that is code review. Any pull request which pulls in hundreds of unrelated commits hopefully won't get accepted. And if it does, there'll be plenty of time to evaluate why while coordinating the cleanup.

[zibzab]

> the solution? who knows, one option would be to force push the earlier position of a branch, thus erasing the merge commit, but force pushes are considered a bad practice

This is definitely a better solution and the _only_ time force push is okay.

(Well unless this is a big public repo that have since moved on)

[beermonster]

> Surely we can do better than this? A tool being powerful should be no excuse for it having footguns!

I agree. In fact I’d even say they exist but yet they didn’t win.

I have often wondered why a tool that sits atop of git doesn’t exist. One that exposes some basic opinionated operations.

[KronisLV]

> I have often wondered why a tool that sits atop of git doesn’t exist.

Well, some software like SourceTree allows making certain workflows, like Gitflow easier: https://weaintplastic.github.io/web-development-field-guide/... and https://www.atlassian.com/git/tutorials/comparing-workflows/...

Of course, that workflow is now considered a bit dated at this point and is only good for some projects, as a way to manage their complexities.

Now, my memory might be failing me, but i actually recall GitKraken having a lot of nice functionality, like being able to get rid of bad branch merges with ctrl+z, much like one would undo a bad text edit in other software, which seemed really intuitive and functional: https://www.gitkraken.com/

Personally i'm only aware of such small, yet nice improvements in the GUI space, like how GitHub Desktop also attempted simplifying working with Git (within their platform) somewhat: https://desktop.github.com/

I guess that perhaps a larger amount of people who use the Git CLI are okay with it or just tolerate it, rather than the ones in the Git UI app space, where new apps pop up every now and then?

[dude187]

Phabricator is like that, kind of a git repo host that comes with an opinionated command line tool that crafts your commits for you.

Personally, as someone familiar with git I didn't like the abstraction layer on top. However, it's a nice self hosted alternative to something like GitHub

[rvdginste]

The way you setup branches and how you work with them, is your own choice and is not directly tied to a specific version control system. I used to work with feature branches on subversion before I moved to git. Git does support more types of branch configurations and more ways of bringing code from one branch into another branch.

I believe that the issue that you ran into would have been best solved with a reset and a force push, as long as you see it rightaway and thus before other commits were done and as long as you can warn the whole team that an error happened and that it will be fixed with a reset+force push. At least that's the way I would do it. We use bitbucket and disable reset+force push on the main branch, but allow it on feature branches. When it is really needed, we temporarily enable it on the main branch to do a fix and immediately disable it again.

Also, IMHO, if you have a main and development branch, I think that the feature branches should be based on the development branch and not on the main branch. Normally you want the feature branch to take into account the most recently merged code. To me it seems that if you want to make a new release of 'main' before the release of 'development', you are talking about a hotfix and that should be exceptional. For a hotfix, you'd base the fix off the version with the bug, and then check whether the fix is also needed on development. Moving commits around like that with git can be done fairly easily using 'cherry-pick'. But mainly my point is: all the different branches that you define and how you work with them is really your own choice, you can make it as hard or as simple as you want. It seems a lot of people are making that setup very complex, but remember that not everyone is working on a project used by 10 customers with 3 active major versions, each of which requiring features and bugfixes. In a lot of cases, you can get away with one long-living main branch and short-living feature branches. As long as each release is properly tagged, you can make a bugfix or hotfix release for anything that you released before. And, again in my opinion, the default should be that when a feature is merged, it means that it was ready for release and will be in the next 'regular' release.

> Surely we can do better than this? A tool being powerful should be no excuse for it having footguns!

I don't really understand what you mean here. Git is very powerful and allows you to manipulate commits in a lot of different ways, some of which are destructive... but that is part of its power. What are in your opinion the footguns and how would you remove them?

What I did notice, is that a lot of people just seem to refuse to take the time to actually learn how git works and how they can work with it. A lot of people seem to be convinced that it is a much better use of their time to search for a git UI that hides all the complexities and shows them a more simplified presentation that likely is a bit closer to how they are used to work with other source control systems, than that they use the same time to learn to use git. Personally, I use the git tools that come with git: the git cli, gitk to visualize history and git gui to commit work. (I do like the UI built into JetBrains IDEs because it is pretty good and doesn't try to hide anything or invent a new name for certain git terms.)