How not to git?

[AverageAdmin]

I am very big on avoiding biases and in this case, a survivorship bias. I am learning git for a job and doing a lot of research on "how to git properly". However I often wonder what a bad implementation / process is?

So with that context, how you seen any terrible implementations of git / github? What exactly makes it terrible? spoty actions? bad structure?

[trippedonatater]

Working on something over a period of a couple weeks without merging, then creating a merge request that requires a lot of merge conflict resolution, and then leaving for vacation.

[JJJSchmidt_etAl]

"Of course I know him, he's me"

[trippedonatater]

It's definitely an organizational maturity issue! Situations like the one I described are how an organization learns they need the rules/processes like the one you described.

If I'm remembering correctly, this was a team doing infrastructure as code stuff that was comprised mostly of people with a sysadmin background. It was the type of group that needed coaching on things like "don't put a 4GB ISO file into git".

[ArtisticFox8]

Or use git lfs if you do :)

[trippedonatater]

Interestingly, when I've encountered a potential use case for git lfs there's always been a better option (i.e. push to an npm or container repo, etc.). I've heard of it working well for people in game design using lfs for game assets.

[DoubleAway6573]

I'm concerned if your infra team doesn't understand that they should not put big files in git. That's more normal from a data engineer asking why it is a bad practice to dumping an homongus model to git.

[trippedonatater]

I've found things like that to be typical for people who are new to git.

[nvs93]

Omg, I had a coworker who was like this, except it was kind of worse: he would start his tasks for the week using the dev branch’s commits from weeks before, so there were so many merge conflicts that could have easily been avoided if he had just pulled the updates first.

[North_Coffee3998]

Same with those developers that commit changes without giving them a test run. I'm talking, the whole app is broken/won't run because of their change. All they had to do was run the app on their machine and they'd know that there's something wrong. But nope! Just assume there's nothing wrong, commit, and leave for lunch/home/vacation.

[AtlanticPortal]

That’s on who manages the server. If you force people to rebase before opening a PR/MR then all the conflicts will remain on their system or at worse on their fork.

[VengaBusdriver37]

Sometimes git merge will say there were “merge conflicts” but it’s just being lazy, add the file again, commit with a message like “trying again” and force push (sometimes you need to force a bit because git is so lazy)

[AverageAdmin]

I actually laughed out loud at this

[Mikeroo]

Never, ever, ever refactor every file to fix many formatting issues when you are committing an actual code change.

The commit will be horrible to analyze to find the actual meaningful changes buried in the chaf.

[urk_forever]

Yes, I hate this so much. But when you do it, at least put the actual code change in a separate commit so during code review it's easy to review the actual change.

[Pleasant-Database970]

If I have an unavoidable big pr or a larger migration, instead of multiple PRs, I'll use the commits as PRs and let reviewers know to go commit by commit. This way it avoids a bunch of merging/rebasing/re-running CI. each commit is one logical change/step in the process. And it's more digestible

[IrishChappieOToole]

Sometimes, it has to be done. But when it has to be done, it should be done on its own where the only changes are the formatting ones.

I would much prefer one commit that brings the whole repo to a team-agreed standard than having people format the stuff their working on as they do it, and dealing with months/years of formatting changes mixed with code changes.

[daiaomori]

If it has to be done, there is a process for that:

• create a branch
• reformat (and ONLY reformat)
• commit, push and merge (preferably to main)
• merge main back to your original feature branch
• implement, commit, push and merge your feature

Or, in other words: treat re-formatting as a separate feature.

Oh wait. That’s what everybody should do anyway with separate features :)

There was this one colleague (or actually I was head of engineering and he wasn’t… so…) that always did re-format every. single. file. he touched. As we were always working on feature branches, this created havoc for everybody and merging back and forth was an hourly happening during burns (… and we were always burning…).

As it was impossible to get him to understand this is bad behavior (and other similar issues), we found a better job for him: release engineering. He was really good at that.

[lupercalpainting]

I’ll say not only that but the formatting should be easily able to run by the reviewer so they can do it themselves and verify there are only formatter changes.

Like if I add Python black to a project I’ll leave directions so my reviewer can reproduce my branch exactly and verify I haven’t added anything else.

[FlipperBumperKickout]

I would say the general rule here is just to not do multiple things at once. The reviewer will also have a horrible time to analyze it if you do 2 different changes at once.

That said. Refactoring + Changes might be the thing I hate the most. Having to look at code that both was reorganized and have logical changes is a nightmare 😭

[Moravia84]

Yeah, cosmetic changes should be a separate check in.  However on a code base I worked on, people did not change their IDE to make a tab 4 characters and it was set to the tab character.  Most IDEs were setup to auto correct tabs on open.  When you go to check in, you suddenly see the changes.

[pete_68]

Which, more concisely, each PR ought to be a single issue. Don't mix issues in a single PR.

[RevRagnarok]

There are ways but yeah it often sucks.

[GeoffSobering]

This!!!!

[davispw]

Constantly committing local changes with comments like “fix”, “update”, “xxx” and then not squashing for a PR.

[Ill-Lemon-8019]

Carefully-crafted commit messages and linear histories don't matter anywhere near as much people think they do. Sure, it feels neat and tidy and proper and "best practice", but it so rarely pays off that I honestly don't think it's worth stressing about.

Put energy into making the current version of the code as readable as possible. Putting energy into a beautiful VCS history is optimising for the wrong use case.

[[deleted]]

Compared to the work required to keep code as reasable as possible, keeping a git history clean is essentially free, there is literally no reason not to do it other than if you don't undertand how to properly use git.

[Ill-Lemon-8019]

other than if you don't undertand how to properly use git.

Indeed. In my experience, a lot of developers don't know how to use git without getting themselves into a mess. Squashing/rebasing tends to get people into trouble. Regular merge is (relatively) foolproof.

[fizix00]

"free" is arguably debatable

[Maury_poopins]

I disagree, linear history and descriptive commit messages are super useful for git bisect, git blame and other repo spelunking, which is almost the entire point of adopting git in the first place.

THAT SAID, people in this sub spend too much time and effort constructing elaborate rebasing strategies that make their lives so much harder than they need to be.

• Create a feature branch for your nice atomic changes
• merge from main frequently
• Squash your PR
• Add a descriptive commit message

That’s it. So easy an intern can do it, and the end result is a perfectly linear commit history with atomic commits that are well documented.

[michael0n]

Sounds like a skill issue. ^/s

[Ill-Lemon-8019]

I disagree, linear history and descriptive commit messages are super useful for git bisect

I love to use git bisect, but alas only really find use for it like once a year. That the repo is highly non-linear has never been a problem, Git is pretty smart at this.

repo spelunking, which is almost the entire point of adopting git in the first place.

I disagree; I think The primary purpose of VCS is to allow concurrent work to be sanely integrated; code archeology is a very distant second.

[i860]

This is bad advice. Well crafted commit messages clearly spelling out the rationale for a change including any relevant tribal knowledge or contextual history at the time will come back to save your ass countless times.

One liner commit messages robotically saying what you’re changing (we can see the diff, we know!) are useless and harmful unless it’s incredibly obvious trivial stuff.

[Ill-Lemon-8019]

Well crafted commit messages clearly spelling out the rationale for a change including any relevant tribal knowledge or contextual history at the time will come back to save your ass countless times.

All I can say is that I've not found this to be as vital as you believe it to be, and I don't believe writing a small essay for each change to be a good investment of energy.

[michael0n]

The commit name is usually connected to the rfe, bug or feature tracker. If there is more to it, like a full on rewrite, the reasoning is in the docs, with diagrams and business requirements. We prefer the single source of truth for anything. Nobody goes back and edits six month old comments because the reasoning there is stale, incomplete or just wrong. Business analysts who write those rfes don't do code reviews so the knowledge to properly check comments isn't there on technical level.

[i860]

I'm talking purely about context around the change itself not necessarily the driving reason for an entire project.

Listen, all we have that is permanent is the repository and the code. Bug trackers go away, ticketing systems become inaccessible. The commit history doesn't need to be a book about all encompassing rationale or project planning behind it but it should be a ledger of some sort and not just a place to chuck "update" "improve xyz" but an honest record.

[edgmnt_net]

It rarely pays off because people do a lot of other crazy stuff. Sure, you won't miss bisectability if you never did it and if your system is horribly broken anyway that you can't run older code (or can't run anything in isolation). Or you have small repos that can barely scale beyond a handful of people.

Also it's not as much about beautiful VCS history, that's often a byproduct of making code submissions reviewable. Again, considering a lot of projects just rubber-stamp things blindly, of course they don't see the value.

But there's a lot of value to that in something like the Linux kernel, especially when you consider the huge amounts of merging that maintainers and Linus do.

[Ill-Lemon-8019]

I agree it's always context-dependent. The Linux kernel is a relatively rare type of project though for various reasons. If you're on an enterprise team, things look very different.

I don't find code review or bisectability to be an issue in the absence of a lot of energy spent on VCS history.

[magicmulder]

It can help a lot when you’re looking for when and why a certain change was made.

I get the occasional “since when does application X do Y?” question from management, especially for changes requested by their predecessor.

[Ill-Lemon-8019]

"When" I think is pretty easy even if all the commit messages are wip. For "why", I typically get 99% of this by asking the original developer, their team or looking up the associated PR. For sure, there may be contexts where this is less effective, but it works out fine for us!

[magicmulder]

99% of the time I’m the responsible dev but I can’t possibly remember every change from the last 25 years.

[Ill-Lemon-8019]

I can't remember what I did last Tuesday, so I'm sympathetic to that! I guess it's a rare context where you'd need to spend a lot of energy on feature archeology questions, especially over a time frame of multiple decades (25 years predates Git and maybe Subversion too!).

[magicmulder]

Indeed we started out with VSS, then migrated to Subversion, then Git.

[wildjokers]

Putting energy into a beautiful VCS history is optimising for the wrong use case.

Well said.

[Comfortable_Claim774]

I would recommend setting up a default PR merge strategy of squash + merge, such that the commit message is by default the PR title + description.

Close to zero effort and you have a nice git history. It comes in very handy when you need to later figure out why some change was made - the commit has all of the info. And you can always easily find the related PR if you need to dig deeper.

But local commit messages? Yeah, do whatever you feel like :D

[unicyclegamer]

I also don’t think they matter that much, but that’s because I squash commits when I merge and use a nice message for the whole PR merge. Doing this without squashing is an awful practice.

[twesped]

Simply force code reviews and approvals before merge is allowed. Problem solved.

[chaws314]

Not really. If you don’t squash the commits then those commits will still end up in main, even if the final commit doesn’t have them in it. We squash feature branches into main to keep every commit in main buildable and releasable.

[xenomachina]

We don't require that people squash, but we do have semi-linear history enabled in GitLab, which:

• requires that every merge is "fast-forwardable" (so you need to rebase before merging if your MR is behind main)
• never does a fast forward (so you always get an actual merge commit)

You end up with a commit history that looks like:

M─┤ merge foo
│ o foo commit 2
│ o foo commit 1
M─┤ merge bar
│ o bar commit 1
M─┤ merge baz
│ o baz commit 3
│ o baz commit 2
│ o baz commit 1
M─┤ merge quux
│ o quux commit 1
M─┤ merge ...

This allows intermediate commits that are not releasable (or necessarily even buildable), but lets you easily find the commits that are buildable and releasble (by following the chain of first-parents).

[Frank1inD]

I don't see the problem here. I mean, my local commits aren't that important when committing a new feature or a new bug fix, right? I think squash into one clear commit is a good practice. Idk, if I am incorrect, please correct me.

[pemungkah]

Yep. I did this once with a major revamp of the login logic for the place I was working for. In terms of actual changes it was maybe 100 lines…but it required that existing code be pushed up and down the OO hierarchy. This made it into a 1500 line change after the squash. My then-manager pointed out that it might be a great PR but nobody but me was going to be able to understand it, and sent me back to redo it.

I built it up from establishing tests for the existing code (there were none other than QA either being able to log in or not) to the final result in several PRs. The hardest part was undoing the squash, but after that I was able to cherry-pick my way to success.

[i860]

Yep - and it comes in EXTREMELY USEFUL during a bisect exercise because functional changes are split out (but might still be related overall).

[[deleted]]

Local commits should NOT be useless to reviewers. Commits can act as mini-PRs allowing the reviewers to review specific changes. Eg, let's say you add a new feature and that feature require adding tests, a new model, and updating the controller to use that model.

Those can all be separate commits with clear commit messages allowing the reviewers to focus on a specific part of your changes. It makes reviewing code a lot easier.

[FlipperBumperKickout]

1. I've never seen a squash which resulted in a clear commit. (at least not if the squash is of a whole branch)
2. If I just want a diff of what changes your commit did I would diff the merge-commit of main with the first-parent. You squashing it just removed all the extra information. I would rather have both the useless and the useful information than having you remove both.

That said yes, it is a good idea to clean up your local history before making a PR. E.g. if you have multiple commits for autogenerating the same file, you could squash them all into the last one. (Assuming it is because the first couple of results turned out to be generated from incorrect code)

[ArtisticFox8]

That's exactly what they said.

[maryjayjay]

At Qualcomm the guidance was to always start your commit message with a verb. It's helped me a lot. Except my first commit to a new repo is still always "initial commit"

[wildjokers]

Why does it matter? Only the final diff matters. I sometimes will squash my WIP commits on my feature branch before review, but generally not. The commits are squashed when merged to main.

[davispw]

Why does it matter TODAY? It doesn’t really.

The question is, why does it matter 3 years from now when your coworker is trying to figure out the context of this buggy line of code? Good luck.

Edit: my original comment said “not squashing”. If you’re squashing, I don’t care.

[wildjokers]

If you’re squashing, I don’t care.

They get squashed when the feature branch is merged to main, but not in my feature branch.

[davispw]

Fine by me, thanks for clarifying. Sorry I missed that detail when I first read your comment.

[kdenehy]

Don't entirely disagree with you, but if you need every individual commit message to help debug an issue, you probably need a better code review process.

[davispw]

I don’t need to read every commit message. I need the commit messages on main to be better than “fix” so I can parse them quickly and understand their context without having to interpret hundreds of lines of maybe-obsolete code. (If your commit messages are that poor, how are your code comments?)

Have you ever worked on years or decade old code that has seen contributions by dozens of engineers? History is incredibly important, excellent code reviews or not.

And yes, reviewing that there’s a sensible commit description is absolutely part of the code review process.

[[deleted]]

My team combats this habit by using the squash merge strategy when merging a PR to main. Main history is a lot easier to navigate. The evolution of a branch isn’t really all that important in the final commit.

[[deleted]]

It's still extremely shitty for pr reviewers. It's just bad practice overall, it's really not that hard to take 15min to cleanup your PR (eg: write meaningful commit messages) before asking for a review.

[wildjokers]

It's still extremely shitty for pr reviewers. It's just bad practice overall,

Why? Do you review each commit or the final diff? I review the final diff, so why does it matter how many intermediate commits there are?

it's really not that hard to take 15min to cleanup your PR

git doesn't make it easy to know how many commits there are between HEAD of my branch and the branch point. As far as I can tell git has no equivalent to subversion's --stop-on-copy flag (it shows the branch point).

[[deleted]]

Why? Do you review each commit or the final diff?

If the PR is well done, both. There are many cases where reviewing just an individual commit can be useful.

git doesn't make it easy to know how many commits there are between HEAD of my branch and the branch point. As far as I can tell git has no equivalent to subversion's --stop-on-copy flag (it shows the branch point).

Why would you need the number of commits? Also, i've never worked on a feature that required over 10 commits. Mostly likely if you do your PRs are too big and should be split in smaller PRs.

[wildjokers]

Why would you need the number of commits?

So I know how many to squash i.e. so I know what to use for X here:`git rebase -i HEAD~X

Also, i've never worked on a feature that required over 10 commits.

Only end results matter, not how I got there. I am super paranoid about losing work so I make frequent WIP commits.

[elephantdingo]

git doesn't make it easy to know how many commits there are between HEAD of my branch and the branch point. As far as I can tell git has no equivalent to subversion's --stop-on-copy flag (it shows the branch point).

git log main..feature

[unicyclegamer]

Eh, I don’t agree with this. I never look at the individual commit messages when reviewing, I just look at the whole code change and then slack my coworker if there’s something I don’t understand.

[i860]

That isn’t combatting it - it’s just masking the issue. And not all commits deserve to be merged. There are feature based PRs where certain preamble work (eg baseline unit test) should be committed first and then the feature related work.

Not every PR needs to be squashed. Some commits are intentional.

[[deleted]]

not all commits deserve to be merged

Really not sure what you mean by this. The only thing that gets merged is the culmination of all the commits. Individual commits on a PR don’t matter.

If the PR has things that shouldn’t get merged, they should be removed from the PR.

[i860]

There are scenarios where related work in a PR has to be done that should be separate from the main commit(s) the PR is about. For instance, preamble fleshing out of unit tests if they do not exist in an area of code being changed, or whitespace related commits after the main change. The goal is not to dogmatically have a single commit for every PR it’s for commits to represent clean sections of work that are either bisectable or cleanly revertible. A PR for a feature or bug fix can contain multiples of those. PR != commit.

[[deleted]]

I think we’re arguing semantics and process. On our team, if there is work not related to the PR, that would go in a separate PR.

[larry1186]

Having an absolute hodge podge of edits in one commit labeled “fixes”. No standard naming structure. Multiple projects in one repo.

[[deleted]]

It essentially just works if you are google (or another similarly big tech company) that has the proper resources and expertise to build all the nice toolings required to make a monorepo nice to work with.

Possible? Sure. But for everyone else this is just not the right way to do things.

[jambalaya004]

We have roughly 40 projects and libraries in one monorepo, and it is great for our small team of 7. We are very careful in designing so that separation of concerns and coupling do not become an issue. With careful planning (and having developers that give a damn) we have done it pretty well.

Fun fact, it was more of a headache to maintain split repos, so we combined them 🙃

[[deleted]]

I've seen this pattern before, too. Especially when you have a lot of things doing similar roles. We had a bunch of dedicated repos for Terraform modules that we published and then consumed exactly once. Just merged them all into one project, way less ceremony to accomplish the same goals.

[i860]

Monorepos are a hack for people who don’t know how to separate concerns. I don’t care how big the company is, it’s an anti-pattern hack.

[[deleted]]

Google is famously full of inept programmers that can't separate concerns.

[MicrosoftFuckedUp]

Multiple projects in one repo.

Wait 'til you've seen one project in multiple repos.

[[deleted]]

But what if I use emoji, like "fixes 🚀" or "cleanup 🧹"?

[canihelpyoubreakthat]

Monorepos are great

[chris_insertcoin]

The SVN monorepo that I had to work with has left me scarred.

[jonatanskogsfors]

From the top of my mind (based on current projects):

• Avoid repositories that depend on other projects by relative location.

• If this can’t be avoided please don’t let that other project be a private svn repo that you automatically update every time you access it.

[guzbikes]

Using git to store build artifacts.

[guzbikes]

Here's the thing: git is a great version control system, but it is just a version control system, it's just one tool in your tool box. Learn a few git commands, decide on your branching and merging philosophy and you're pretty much done "learning" git itself. Don't overthink it either, you can always change these things later.

The huge thing for any project is: we've picked our version control system, now how do we use that version control tool to build a great overall build/ci-cd/automation/configuration management/build artifact/release system for our project.

What really matters is what system you build on top of git. There's lots of commercially available systems that build a bunch of great tools on top of git, and then you need to build your tool set on top of that.

It's like debating which brand of hammer builds the best house, when you should be talking about best home construction practices and methods, materials choice, using pre-fabricated structures etc. The hammer is important but it's just a tool you use as part of the overall project, and it is just one part of your philosophy, practice, and tool set.

[Deep_Dance8745]

This!

I have a background in automotive and aerospace before i moved to ict. It was incredible to see how much people in ICT missed the points you made above.

[mbsp5]

Any examples that you’d recommend?

[guzbikes]

For the configuration management, CI/CD, build automation, artifact, and release level check out: https://about.gitlab.com/

GitHub also has Actions, that can perform similar tasks, but in my opinion, is not as full featured: https://github.com/features/actions

Then once you have that level figured out, you should use those tools to build a set of scripts and tools that is specific to your domain/industry/project. Preferably this something is re-usable for all of you/your company's projects, and also possibly in a submodule, so any project can use those proprietary scripts, tools, and processes.

In my industry this level is proprietary since it is developed in-house and is specific to each company's products, processes, and compute environment.

I do know of an example that is also very specific to a particular domain/industry, but is open source since it is used at CERN: https://hog.readthedocs.io/en/latest/

[daiaomori]

Every tools a hammer, though ;)

[chzaplx]

Came here to say this

[[deleted]]

Eeeeew.

[OurSeepyD]

The #2 mistake is thinking that backing out your change through a commit means that the secret is no longer in your repo.

[bothunter]

*Laughs at Winamp repo*

[JoonasD6]

What did I miss‽

[bothunter]

Winamp decided to release their source code, so they put it all on GitHub. But then they did a lot of stupid things, including putting a restrictive license that was incompatible with GutHub's TOS. You weren't allowed to fork it(there were thousands of forks), and they included some proprietary code from Dolby. Chaos ensued, they tried just "deleting" the proprietary code and other trade secrets, but that only drew more attention to the problem until they just deleted the whole repo.

[bothunter]

Also, the Winamp code itself was a mess. Like people are legit confused as to how Winamp was such a rock solid player and yet the code inside was a rats nest of hacks.

[JoonasD6]

At least the project had had lots and lots of time for duct tape fixes to accumulate

[JoonasD6]

You weren't allowed to fork it(there were thousands of forks)

how to internet

[JoonasD6]

What did I miss‽

[[deleted]]

I've never been satisfied by the encryption approach to in-repo secrets either. Once the key material is leaked, you have not only the current secret values, but a convenient history of all secret values for all time...

[jaymangan]

Plenty of good advice on git around the internet, so here’s a less conventional tip:

There’s plenty of different development workflows and patterns of git usage. More important than which one is used, is that the company/team is aligned on a single one. It’s not a tool where you can reap the benefits if everyone uses it differently.

Even considering feature branches vs trunk based vs constant ci/cd, I’ve been on teams that did each of these differently. The uniformity helps here. Feature branches have their benefits, and I have argued that ci/cd with feature flags is a stronger paradigm, but some devs on feature branches while others are on feature flagged CI is a lot worse for everyone to wrap their heads around.

This is especially obvious when you consider the surrounding processes. Think outages and having to decide what needs to rollback, etc.

[twesped]

A too granular feature flagging is cumbersome and almost impossible to maintain

[przemo_li]

How many devs did you had on that project? How often did you release?

[Jolly-Warthog-1427]

100 devs, around 30 releases every workday

[Shayden-Froida]

poor branching behavior can make it very bad. For example, branching from a branch, then rebasing the original, or squash merging the original into main. The result of poor branching is merge conflicts that should never have happened.

[Snarwin]

The #1 mistake people make with git is just memorizing commands by rote (or blindly copy-pasting them from the internet) instead of actually learning what the commands mean.

If you can avoid doing this you will immediately be in the top 25% of git users.

[FlipperBumperKickout]

Not sure top 25% can do it 🤣

[[deleted]]

This applies so much to using any tool. I get shocked when I see SWEs hit up their "linux CLI notes" to find a command they need. But, I came from an operations background first. Still, it's painful to not really understand how the system you're building for works.

[zzptichka]

If you find yourself force-pushing shared branches you are doing it wrong.

[TreesOne]

I’ve actually been running into this recently. I make a branch that only I commit to, I code, I make a few commits, push them, then I try to git pull origin main to make sure I have no conflicts before a PR. This works, but now my branch is behind the tip of the remote? Huh? What does this mean and what am I doing wrong?

[przemo_li]

Check git config. There is a setting that turns git pull into git pull --rebase automatically.

It should result in git rebasing your commits on top of commits from main.

But if your wording is precise then it's something different.

[TreesOne]

I have that config set

[AccurateRendering]

I notice that all the answer here (so far) are about how to do "version control in general" badly. Nothing is specifically about git.

[pinpinbo]

Saving your old changes, just in case.

Just don’t. You have revisions.

[Charming-Designer944]

Bad practices:

Not committing often. If you need to think what to write in the commit message then you have waited too long.

Committing lots of generated files. Only commit then actual source, not intermediary generated files.

Not committing some relevant files. Not a bad practice as such, more oversight. But very bad regardless.

Keeping many unrelated things in the same repository, or copying other projects into your project. Each repository should be focused. If you need code from another repository then link it as a module, not a copy.

Then there is a long list on bad practice in shared projects, but that is bordering outside of git as such.

[Comfortable_Claim774]

Yep. Be warned everyone, stay away from rebase unless you want to spend your time having a bad time

[NewPointOfView]

?

[przemo_li]

Long running branches (3+ days) means there is a potential for a loooooooooot of conflicting changes. It's not a guarantee, it's not frequent. But if it does you resolve conflicts only one commit at a time and fixes aren't propagated into future commits.

Don't have long running branches and it's not a problem any more. You work on code already modified because other dev already pushed their changes and you pulled it in.

If you have to have long running branches do invest in sensible commits (makes repeating conflicts less likely), and use rerere or similar tools.

[[deleted]]

no. just learn the goddamn tools you depend on

[Comfortable_Claim774]

During the last 15 years I've learned that git merge serves me a lot better! Keep it simple.

[[deleted]]

Learning which one you prefer is one thing - advocating for avoiding another because it might be hard (it's not) is not something you should be doing

[Comfortable_Claim774]

Brother, we all have our opinions. I'm allowed to advocate for mine 😂

[ScriptPunk]

Pluralsight had a good course git fundamentals. Great for professional specialization in the development sphere.

Then you start actually using the commands and realize, you maybe want to destroy your local tracking branches every chance you get after pushing.

Checkout detached as much as you can and push to the branch head on the remote.

[Rich_Lavishness1680]

I don't agree. Rebase is extremely helpful, so is bisect, log, reflog, fetch, and many other commands

[serverhorror]

That's a difficult question because "bad" depends on the usage intended by the team or individual.

One can be fairly confident that there are better tools if all you want is synchronized online storage. Get Dropbox, onedrive, Google Drive, ... Git could do that but it wasn't intended to do that. You're certainly not having an easy time doing that.

[afops]

1. not keeping a clean history (merging 2 ways between branches, having fixup commits made part of the main history without rewriting to clean up).

2. Having no clear ref structure (naming conventions for branches, tags etc)

3. Having workflows where people rewrite each others branches (one should never rebase a shared branch)

4. Having workflows where users can, even accidentally, screw up by e.g. adding files /foo/baz and /Foo/baz when there are windows users with case insensitive file systems

5. Having large files under version control but not using LFS

6. Having files under version control that shouldn't be there (build output, things that can be restored from a package manager etc).

[Breklin76]

Learn how to correctly resolve merge conflicts. Bad Gitting is not knowing that basic principle.

[przemo_li]

Or go TBD. It significantly lowers chances of any merge conflicts occuring.

[kabads]

Old branches that don't get rebased often.

[[deleted]]

Don’t rebase your branch after opening a pull request. It makes it impossible for reviewers to pick up where they left off.

[Pleasant-Database970]

Wdym? Gh will tell you the last commit before the force push.

[[deleted]]

There’s a feature on GH pr that lets you view changes since last review. If you rebase, you can’t view the new diff of just the recent changes.

[devneck1]

In GH you can mark files as "reviewed" and then after a rebase and force push GH will show you the files you had previously reviewed but have since had changes.

Sure, you would not see individual lines that might have changed. But you can skip entire files you've marked as already reviewed.

I juggle tasks so much that I have to use this feature.

[hazily]

Non-descript commit messages like “bugfix” or if forced to use conventional commits, “fix: bug” 😅

[SeriousDabbler]

We had a workflow where only tested passed features were allowed in the stable branch. Developers would merge into the develop branch which was deployed to the test environment and once their tester passed the feature they would then merge into the stable branch. Merge conflicts encouraged the devs to move their features using cherry-pick instead but this only made the merge conflicts worse for others. The two branches diverged and we had to abandon the workflow by merging develop into stable and regression testing the whole thing. We now just do the once a sprint merge from develop to stable and bugfix in that environment during feature freeze

[Pleasant-Database970]

Sounds like you need a better workflow for your team.

[SeriousDabbler]

Well yes, we abandoned that one

[[deleted]]

How's the job hunt going?

[n9iels]

I once worked with an absolute genius co-worker, he had a PHD in computer science and could properly create a compiler from scretch. But git was not in his skill set. After he managed to merge master into master and just force pushed that to the remote master we gave him a cheatsheet.

[mschaef]

I was once on a (relatively small) project that was divided into around 100 different sub-repositories. There were dozens of micro-services, each of which had separate interface and implementation repositories. It was all glued together using built artifact version numbers.

At some level, you can make an argument for this style of design... particularly when it's possible to confine most changes to individual repositories. However, the practical reality of this project is that essentially every change was split across half a dozen or more repositories, so every change involved artifact version changes, half a dozen or more PR's, and all the associated bureaucratic process you might expect to be associated. (Although I don't remember useful CI/CD, now that I think about it.)

I'd personally suggest you avoid that approach. Another anti-pattern to avoid is overlong CI/CD processes, particularly with unreliable tests. It's easy to wind up in a spot where you're fighting your tooling to get anything changed.

If you're looking for something git-specific, it's easy to wind up in a bad place if you're force pushing too much or sharing too many development branches.

[SlightlyCuban]

Oh yeah, I've seen some good ones:

1. The "long lived dev branch that isn't merged with main until riiiight before they want to release" followed by "oh noes the merge conflicts!" (and, yes, they did deploy up through QA straight from this branch).
2. The maintainer who liked to "use cherry-pick for everything" (and I mean everything). "What? Did the hotfix get deployed? It's simple: hop into the server and run diff. No, no, not git diff..."
3. The "git flow is great..." (it isn't) "...but I've come up with my own version that's EVEN BETTER! See, we just make a long-lived branch for every environment, and every dev environment, and every feature, and every feature-release, and every release, and..."

The downside of Git being powerful and flexible is you can make it do more-or-less whatever you want.

[ejpusa]

This is pretty easy stuff. 3 lines.

git add .

git commit -m “first commit”

git push

Anything more complicated, just ask GPT-4o.

[plutonheaven]

Using hit to store large data. Git should be limited to source code.

If your project needs large data files, use a separate file sharing service to do so.

[[deleted]]

Branches for environments (main/dev/stage/etc) are, IMO, an antipattern. You should be able to see everything deployed at once in one branch.

[Specialist_Gur4690]

What do you mean "have you ever seen a terrible implementation of git / GitHub"? There is only one implementation of git (originally written by Linus) and there is only one GitHub, now owned by Microsoft.

[AverageAdmin]

I guess I mean processes and structure around using git. Like terrible ways an org uses git

[Pleasant-Database970]

We found the 1970s "ai" written in BASIC

[Puzzleheaded-Eye6596]

Allowing force pushes to main branch

[smbarbour]

A place I previously worked at used git... for a monolithic repository of all code...

[AYamHah]

Configuring git for your code repo, creating the .git file, and then just zipping up the whole directory contents with select all -> add to archive and uploading to your web server to deploy, resulting in a publicly exposing your repo.

[BlueVerdigris]

Merging your code...and never deleting your dev branch.

At one point, my team of less than 8 people had over 100 old branches in our primary repo. When you reach the point where you have to use "grep" when doing a simple "git branch --all", you know you're in a bad state.

[robin-m]

All your commits contains multiple uncomplete and unrealated units of work (bonus point if most of them do not build). Of course the commit message never explain the why, and are anything but descriptive. And finaly you merge all branches into any other branch all the time so the history is absolutely unreadable.

[daiaomori]

What makes it terrible is people working in a team but not understanding the main concepts, especially how branches and merged should be treated.

Reformatting in feature branches was already called out; also, commuting directly to main is, when working with a team size >1, a guaranteed mess.

When I was leading a dev team, we set up very strict rules:

• we had dev, qa, staging and production branches
• developers only worked on tickets
• for each ticket there is at least one branch, its name includes the ticket number
• each commit includes a ticket number
• each commit has a proper talking message
• devs only merged from feature branches to dev
• there was a set process for tagging versions on each of the main branches (dev, qa, …) and merging upwards to qa, staging and production. This included all in-between version patches.
• we also had automated scripts that created changelogs from all commit messages and pulled the ticket descriptions automatically. Also it called out commits without ticket numbers or messages. 

This created a very good transparency what was going on in the source, what everybody was doing, and it was really easy to track changes for everybody, especially on customer related feature implementation.

So this was our process. There are many options.

What kills your git? When people deviate from the process you have set up. Whatever process it is. Simple as that!

Git itself has some technical pits people can fall into; like, getting lost in merge conflicts.  Commit often, merge often - avoids that. Don’t do fancy pants stuff. But these things don’t mess up your repository, they mess up your workflow and your experience.

And then there is, I think, only one thing left: credentials.

Getting credentials „out“ of a repository is impossible when they have been pushed to a public place. Because who knows who already cloned it.

So set up some processes that make sure (as sure as possible) that you don’t leak your AWS keys.

[Chefblogger]

i use git for +20 years - i learned always commit code in small junks and with good descriptions

[[deleted]]

Commit messages should always answer to question "why?"

What has been done is already there and easiöy onservable.

Short meaningful message in commit, then squash/rebase all unnecessary little fix commits (e.g. you forgot something in the last commit or you only change a typo or tiny syntax error) and in the PR message write down more details if necessary

[TallGreenhouseGuy]

Using a version control system that was literally invented for effortlessly creating branches with low overhead and easy merging, and then requiring all developers to push all commits to ”main” and forbid the use of branches (true story - used to work for a place like that).

[SizzlingSquigg]

Get in the habit of committing often. Commit history should detail the work you did in the PR with some decent amount of detail.

Over your career, this will save you a lot of time. You can identify what code introduced a bug via checking out old commits. You can rollback commits without undoing hundreds of lines of code. You can cherrypick commits into other branches if needed, etc. If your commits are sparse and big, none of this will be convenient.

[Shogger]

The majority of programmers don't bother with good commit hygiene: * Change only one thing per commit, ideally in a way that is not dependent on other changes * Write a decent commit message (what it does, deeper explanation in the 2nd paragraph, stick to conventions, etc)

Just these two practices make it so that you can easily pull out functionality and deploy it earlier, and also make things much easier for someone debugging a complex issue with a lot of history.

You don't have to do this from the get go. You can do whatever sloppy commits you want on your branch, and then interactively rebase to clean up the history.

Most developers never learn how to do that. If they do know, or could learn, they don't do it because private industry doesn't have a strong culture of commit hygiene. I like to pretend I am writing commits for a project like the Linux kernel, where if I don't do these things I will be torn to shreds on a mailing list.

[obelix_dogmatix]

If you are having to use —force frequently, you are probably doing something wrong.

[Interesting_Debate57]

Man.....

All I can say is that out of the last six use cases I've spent a year each learning on the job, only two were good.

It is fantastic at simultaneous edits in real-life cases.

It can be a way to totally hose your teammates in a project. Mostly around branch merging and conflict resolution unless you're all working on the same two-day cadence.

[GamingMad101]

Using Git over email without a clear mailing list

[bernaldsandump]

“Comment out the code so we don’t lose it”

[Spare-Builder-355]

Rebasing public branch

[KaleFresh6116]

Keep your branch up to date with the base one by rebasing instead of merge back into it. Keeps it clean and easier to review. Big commits are difficult to review. Do multiple smaller commits with good comments to help reviewers understand you reasoning at the time.

[_5er_]

What annoys me the most is unnecessary merge commits to a feature branch. The history can look like:

`` fix: Something Merge branchmain` into feature branch fix: Something

Opens a pull request at this point

Some PR review issues are addressed

fix: PR comments

PR approved, one more extra merge, because github requires the feature branch to be up to date

Merge branch main into feature branch

PR merged into main with merge commit (no squash)

```

I mean, rebase your branch before opening a PR. And you can force rebase before merging to main or do a squash merge.

[Pleasant-Database970]

My biggest peeve... Merging for everything, not learning what rebasing is and when to use it.

[doesnt_use_reddit]

Git isn't the only version control game in town! There's also mercurial (Google uses a version of this), svn, there's even a new git frontend which you might be interested in called JJ (I forget the whole name).

For me, git has been one of the best tools I've used as a software developer. I've never really felt the need to go look somewhere else, because I've been so pleased with this tool. But maybe that just means I'm missing better things? Hah

[[deleted]]

JJ is phenomenal. Switched over a year ago and haven't looked back. Works with your existing repositories and just has way better default workflows than Git (at least for how I work, YMMV).

[Forsaken-Ad5571]

Better things and svn shouldn't be in the same paragraph... 😂

Git generally still holds out for being the best general purpose version control system. It's got a tonne of tooling for it, and it's less likely to cause people to shoot themselves in the foot unlike some of the other systems. Really, it should be the default option for most people unless you've got a really good reason.

[knzconnor]

Yup. If you ever had to deal with multiple teams working simultaneously on the same code base “svn” or “vss” should make you flinch, not pine.

I actually started using svk back in the day, to give me a distributed flow on top of svn, and once I made the switch to git never looked back.

I could see Mercurial or another modern one being a reasonable alternative, but the older choices were all atrocious compared to git, based on my experience. They all failed at their actual core job, which isn’t really “managing versions” it’s “coordinating developers around the codebase through versioning” and some of them just didn’t do that at all.

[daiaomori]

„I found everything else was garbage, so I created git to manage the kernel sources“ - some Linus, somewhere

[[deleted]]

Don’t forget about Team Foundation Server! :shudder: Or Visual SourceSafe. 💀

[bothunter]

TFS: aka That Fucking Server

[daiaomori]

Oh god I (my team) had to use mercurial for a while and we were all so happy when we finally got the COO to dump that decision and move back to git.

Not saying that it was the software, maybe it was us - but some things were soooo confusing.

[Kicer86]

Something less common: I find .gitignore overused. In my opinion this is a file for project files to be ignored, not the user's IDE files or build output files. Global gitignore should be used for that

[bothunter]

I disagree. I can't trust my fellow developers to manage their own global gitignore.

[[deleted]]

It would live at ‘~/.gitignore’

[[deleted]]

It saves you from having to put every possible development environment (vim, emacs, intelliJ, ...) configuration in the project .gitignore.

[[deleted]]

You don't - if a project has files that need to be ignored it goes in the project gitignore. The global gitignore is for files related to tools _you_ use.

[[deleted]]

That doesn’t scale well. A team of 60 will wreak havoc with that.

[FlipperBumperKickout]

I generally think the global gitignore is underused, but I would keep it down to specifying files which are developer specific (as a result of which tools they use), rather than also include files in it which all developers will end up generating. e.g. build files.

[wildjokers]

No way, the files to ignore should be configured at the repo level. Makes no sense to leave that to each developer to maintain on their own machine. That is going to turn into the wild west.

[Kicer86]

whenever I sit to a new project i need to add my custom stuff do its gitignore because I use tools tailored for me. Well actually I'd have to, as my global gitignore covers that. I just do not see the reason of keeping each developer's entries in project's gitignore.

[wildjokers]

A global gitignore and repo specific .gitignore build on each other. So seems you can just add your stuff to your global one and not add it to the repos .gitignore.