- Margot Robbie ( @MargotRobbie@lemm.ee ) 130•6 months ago
I think this is a fake quote that somebody made up for an Internet comedy bit, since it seems unlikely for Hollywood actress Sydney Sweeney to have such uncharacteristically strong opinion on software version control, of all things.
Because she of all people would know that there isn’t anything wrong with using
git merge
, and it ultimately comes down to personal preference to what you are used to.- archomrade [he/him] ( @archomrade@midwest.social ) English69•6 months ago
Fair point, Margot Robbie
- Margot Robbie ( @MargotRobbie@lemm.ee ) 48•6 months ago
That’s esteemed Academy Award nominated character actress Margot Robbie to you!
- sundray ( @sundray@lemmus.org ) English12•6 months ago
And successful Hollywood film producer – props on getting into the stakeholder end of the business so early in your career!
- Artyom ( @Artyom@lemm.ee ) 35•6 months ago
Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that
git merge
is better thangit rebase
, then I simply had to disregard the whole thing.- Margot Robbie ( @MargotRobbie@lemm.ee ) 21•6 months ago
This is why Sydney Sweeney isn’t on Lemmy.
- DudeDudenson ( @DudeDudenson@lemmings.world ) 11•6 months ago
But they were arguing that it’s personal preference not that one is better than the other
- beeng ( @beeng@discuss.tchncs.de ) 29•6 months ago
“Don’t always trust what you read on the internet.”
- Benjamin Franklin
- ManniSturgis ( @ManniSturgis@lemmy.zip ) 2•6 months ago
Wait a second, there wasn’t even any social media sites back when Benjamin Franklin lived. Did he write that in his newsletter or something?
- masterofn001 ( @masterofn001@lemmy.ca ) 4•6 months ago
I think he was a senior contributor for the underground cracker mag 1600 back in the late 80s.
They called em zines.
- Conyak ( @Conyak@lemmy.tf ) English4•6 months ago
I mean, it’s posted in programming humor so yeah.
- René Descartes ( @renedescartes@literature.cafe ) 3•6 months ago
A bit of the old on the internet no-one knows you’re a dog, I think. Therefore I am a webdev dog too.
- 13 ( @13@kbin.run ) 47•6 months ago
Imagine rewring history
- wise_pancake ( @wise_pancake@lemmy.ca ) 58•6 months ago
History is written by the squashers.
- magic_lobster_party ( @magic_lobster_party@kbin.run ) 17•6 months ago
Imagine working with a tangled spaghetti of history
- tengkuizdihar ( @tengkuizdihar@programming.dev ) 35•6 months ago
Please for the love of god don’t use merge, especially in a crowded repository. Don’t be me and suffer the consequences. I mistakenly mention every person with a commit between the time I created the branch until current master.
- Atemu ( @Atemu@lemmy.ml ) 5•6 months ago
Merge is not the issue here, rebase would do the same.
- tengkuizdihar ( @tengkuizdihar@programming.dev ) 2•6 months ago
really? how come? I thought they are mentioned because of the diffs if compared to master, which merge basically just… merge on top of my branch (?)
- Atemu ( @Atemu@lemmy.ml ) 2•6 months ago
They were mentioned because a file they are the code owner of was modified in the PR.
The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren’t in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).
If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it’d be as if you tried to merge the other branch into master + your changes.
- Cyborganism ( @cyborganism@lemmy.ca ) 32•6 months ago
I prefer to rebase as well. But when you’re working with a team of amateurs who don’t know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.
I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you’re dealing with a team of Git-illiterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don’t give a shit, or you can just do a regular merge and go on with your life.
Those are my two cents, speaking from experience.
- TechNom (nobody) ( @technom@programming.dev ) English11•6 months ago
I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It’s good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don’t know how to edit them.
- AggressivelyPassive ( @agressivelyPassive@feddit.de ) 13•6 months ago
Honestly, I’m pretty sure 99.9% of git users never really bother with the git history in any way that would be hindered by merging.
Git has a ton of powerful features, but for most projects they don’t matter at all. You want a distributed consensus, that’s it. Bothering yourself with all those advanced features and trying to learn some esoteric commands is frankly just overhead. Yes, you can solve great problems with them, but these problems almost never occur, and if they do, using the stupid tools is faster overall.
- Chamomile 🐑 ( @chamomile@furry.engineer ) 4•6 months ago
@agressivelyPassive @technom That’s a self-fulfilling prophecy, IMO. Well-structured commit histories with clear descriptions can be a godsend for spelunking through old code and trying to work out why a change was made. That is the actual point, after all - the Linux kernel project, which is what git was originally built to manage, is fastidious about this. Most projects don’t need that level of hygiene, but they can still benefit from taking lessons from it.
To that end, sure, git can be arcane at the best of times and a lot of the tools aren’t strictly necessary, but they’re very useful for managing that history.
- AggressivelyPassive ( @agressivelyPassive@feddit.de ) 4•6 months ago
I’d still argue, that the overhead is not worth it most of the time.
Linux is one of the largest single pieces of software in existence, of course it has different needs than the standard business crap the vast majority of us develop.
To keep your analogy: not every room is an operating room, you might have some theoretical advantages from keeping your kitchen as clean as an OR, but it’s probably not worth the hassle.
- Chamomile 🐑 ( @chamomile@furry.engineer ) 0•6 months ago
@agressivelyPassive You should still clean your kitchen though, that’s my point.
- AggressivelyPassive ( @agressivelyPassive@feddit.de ) 2•6 months ago
Did I say anything otherwise?
- TechNom (nobody) ( @technom@programming.dev ) English1•6 months ago
Only users who don’t know rebasing and the advantages of a crafted history make statements like this. There are several projects that depend on clean commit history. You need it for conventional commit tools (like commitzen), pre-commit hook tools, git blame, git bisect, etc.
- AggressivelyPassive ( @agressivelyPassive@feddit.de ) 2•6 months ago
Uuuh, am I no true Scotsman?
Counter argument: why do you keep fucking up so bad you need these tools? Only users who are bad at programming need these. Makes about as much sense as your accusation.
You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools. I literally never used pre-commit hooks or bisect in any semi-professional context. And I don’t know a single project that uses them. And before you counter with another “well u stoopid then” comment: the projects I’ve been working on were with pretty reputable companies and handled literally billions of Euros every year. I can honestly say, that pretty much everyone living in Germany had his/her data pushed through code that I wrote.
- TechNom (nobody) ( @technom@programming.dev ) English2•6 months ago
Uuuh, am I no true Scotsman?
That’s a terrible and disingenuous take. I’m saying that you won’t understand why it’s useful till you’ve used it. Spinning that as no true Scotsman fallacy is just indicative of that ignorance.
You keep iterating the same arguments as the rest here, and I still adhere to my statement above: hardly anybody needs those tools.
And you keep repeating that falsehood. Isn’t that the real no true Scotsman fallacy? How do you even pretend to know that nobody needs it? You can’t talk for everyone else. Those who use it find it useful in several other ways that I and others have explained. You can’t just judge it away from your position of ignorance.
- xigoi ( @xigoi@lemmy.sdf.org ) 4•6 months ago
Why would you want to edit your commit history? When I need to look at it for some reason, I want to see what actually happened, not a fictional story.
- Atemu ( @Atemu@lemmy.ml ) 2•6 months ago
Because when debugging, you typically don’t care about the details of
wip
,some more stuff
,Merge remote-tracking branch 'origin/master'
,almost working
,Merge remote-tracking branch 'origin/master'
,fix some tests
etc. and would rather follow logical steps being taken in order with descriptive messages such ascomponent: refactor xyz in preparation for feature
,component: add do_foo()
,component: implement feature using do_foo()
etc. - TechNom (nobody) ( @technom@programming.dev ) English1•6 months ago
You can have both. I’ll get to that later. But first, let me explain why edited history is useful.
Unedited histories are very chaotic and often contains errors, commits with partial features, abandoned code, reverted code, out-of-sequence code, etc. These are useful in preserving the actual progress of your own thought. But such histories are a nightmare to review. Commits should be complete (a single commit contains a full feature) and in proper order. If you’re a reviewer, you also wouldn’t want to waste time reviewing someone else’s mistakes, experiments, reverted code, etc. Self-complete commits also have another advantage - users can choose to omit an entire feature by omitting a commit.
Now the part about having both - the unedited and carefully crafted history. Rebasing doesn’t erase the original branch. You can preserve it by creating a new branch. Or, you can recover it from reflog. I use it to preserve the original development history. Then I submit the edited/crafted history/branch upstream.
- Rusty Shackleford ( @RustyShackleford@programming.dev ) English4•6 months ago
Git-
illeterateilliterate- Cyborganism ( @cyborganism@lemmy.ca ) 1•6 months ago
Ah thanks.
- magic_lobster_party ( @magic_lobster_party@kbin.run ) 3•6 months ago
How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.
- expr ( @expr@programming.dev ) 5•6 months ago
I don’t want squashed commits. It makes git tools worse (
git bisect
,git cherry-pick
, etc.) and I work very hard to craft a meaningful set of commits for my work and I don’t want to throw all of that away.But yeah, I don’t actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.
- expr ( @expr@programming.dev ) 25•6 months ago
ITT: people who have no idea how rebasing works.
- magic_lobster_party ( @magic_lobster_party@kbin.run ) 20•6 months ago
Skill issue tbh
- CmdrKeen ( @CmdrKeen@lemmy.today ) 11•6 months ago
No doubt.
git rebase
is like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.
- expr ( @expr@programming.dev ) 5•6 months ago
Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do
git rebase --interactive
, since if anything goes wrong, you can easily get out withgit rebase --abort
.In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.
- ipkpjersi ( @ipkpjersi@lemmy.ml ) 3•6 months ago
True, the real danger is using git reset with the --hard flag when you haven’t committed your changes lol
- thanks_shakey_snake ( @thanks_shakey_snake@lemmy.ca ) 2•6 months ago
You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.
When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.
- expr ( @expr@programming.dev ) 1•6 months ago
Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.
But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.
- thanks_shakey_snake ( @thanks_shakey_snake@lemmy.ca ) 2•6 months ago
Ah, you’ve never worked somewhere where people regularly rebase and force-push to master. Lucky :)
I have no issue with rebasing on a local branch that no other repository knows about yet. I think that’s great. As soon as the code leaves local though, things proceed at least to “exercise caution.” If the branch is actively shared (like master, or a release branch if that’s a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it’s worth.
You can mitigate that with good processes and well-informed engineers, but that’s kinda true of all sorts of dubious ideas.
- expr ( @expr@programming.dev ) 1•6 months ago
Pushing to master in general is disabled by policy on the forge itself at every place I’ve worked. That’s pretty standard practice. There’s no good reason to leave the ability to push to master on.
There’s no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It’s a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage
fix typo
commits (and spurious merge commits) that you’d have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.
- aubeynarf ( @aubeynarf@lemmynsfw.com ) 1•4 months ago
If “we work in a way that only one person can commit to a feature”, you may be missing the point of collaborative distributed development.
- expr ( @expr@programming.dev ) 1•5 months ago
No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.
Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.
- RonSijm ( @RonSijm@programming.dev ) 17•6 months ago
Rebasing is for noobs.
git reset head~42 git push -f
- Crow ( @Crow@lemmy.blahaj.zone ) 14•6 months ago
I’ve been using merge, and I hate that I don’t even know what rebase really does
- andrew ( @andrew@lemmy.stuart.fun ) English31•6 months ago
Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.
- pineapple_pizza ( @pineapple_pizza@lemmy.dexlit.xyz ) 8•6 months ago
This diagram seems wrong to me. Isn’t the second image a squash merge? Also why would rebasing a feature branch change main?
- Atemu ( @Atemu@lemmy.ml ) 2•6 months ago
The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @andrew@lemmy.stuart.fun meant.
- andrew ( @andrew@lemmy.stuart.fun ) English2•6 months ago
Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.
- bort ( @bort@sopuli.xyz ) 2•6 months ago
why would rebasing a feature branch change main?
the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.
- Elise ( @xilliah@beehaw.org ) 5•6 months ago
I’m relatively new to git and rebase looks like a mess to me? Like it appears to be making duplicate commits and destroys the proper history?
If you use rebase to get a more readable history, isn’t the issue the tool you use to view the history?
I guess I have to try it out a few times to get it.
- Ephera ( @Ephera@lemmy.ml ) 5•6 months ago
What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then
git status
will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.Well, and what is the “proper history”? If your answer is “chronological”, then why so?
For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed
randomlychronologically, but rather related commits following one another.
And of course, you also lose the merge-commits, which convey no valuable information of their own.- Atemu ( @Atemu@lemmy.ml ) 2•6 months ago
you also lose the merge-commits, which convey no valuable information of their own.
In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.
- someonesmall ( @someonesmall@lemmy.ml ) 1•6 months ago
Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).
- Ephera ( @Ephera@lemmy.ml ) English1•6 months ago
Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.
Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.
You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.
- AggressivelyPassive ( @agressivelyPassive@feddit.de ) 3•6 months ago
The commits aren’t duplicated, but applied to the main branch. Since git has commit ids, they won’t be re-rebased either.
- Crow ( @Crow@lemmy.blahaj.zone ) 5•6 months ago
That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it
- RecluseRamble ( @RecluseRamble@lemmy.dbzer0.com ) 4•6 months ago
Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).
- Transtronaut ( @Transtronaut@lemmy.blahaj.zone ) 1•6 months ago
Facts. Force push belongs in Star Wars, and nowhere else.
- expr ( @expr@programming.dev ) 3•6 months ago
Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.
- Transtronaut ( @Transtronaut@lemmy.blahaj.zone ) 1•6 months ago
You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.
- expr ( @expr@programming.dev ) 1•6 months ago
That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.
A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.
- RecluseRamble ( @RecluseRamble@lemmy.dbzer0.com ) 1•6 months ago
Of course it has its uses. I didn’t mention them because the guy just learned about rebase - it’s unlikely to be applied flawlessly from the start.
- expr ( @expr@programming.dev ) 1•6 months ago
I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.
Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using
git rebase --interactive
. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.
- jjjalljs ( @jjjalljs@ttrpg.network ) 13•6 months ago
I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.
All the garbage “spelled thing wrong” and “ran formatter” commits go away. Main is clean and linear.
- DinosaurSr ( @DinosaurSr@programming.dev ) 1•6 months ago
Squash and rebase or squash or rebase?
- jjjalljs ( @jjjalljs@ttrpg.network ) 5•6 months ago
…and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.
You then rebase so you have a nice linear history with no weird merge commits hanging around.
- GissaMittJobb ( @GissaMittJobb@lemmy.ml ) 1•6 months ago
You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up
The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.
Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.
- cobra89 ( @cobra89@beehaw.org ) 1•6 months ago
Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.
- jjjalljs ( @jjjalljs@ttrpg.network ) 3•6 months ago
There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.
Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch
Rebase takes your commit(s) and sticks them on the end.
Merge does something else I don’t understand as well, and makes a merge commit.
Also there was an earthquake in NYC when I was writing this. We may have angered the gods.
- Atemu ( @Atemu@lemmy.ml ) 1•6 months ago
You should IMO always do this when putting your work on a shared branch
No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.
Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.
- jjjalljs ( @jjjalljs@ttrpg.network ) 2•6 months ago
I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.
Do you?
Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.
- Atemu ( @Atemu@lemmy.ml ) 1•6 months ago
Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.
- cobra89 ( @cobra89@beehaw.org ) 1•6 months ago
Lmao I’m in the NYC area and my whole house shook. I’m right there with you. Thanks for the explanation!
- Zagorath ( @Zagorath@aussie.zone ) English13•6 months ago
Okay this is the second time I’ve seen Sydney Sweeney referenced in a meme in less than half a day. I had never heard of her before. Who is she, and why is she suddenly attracting so much meme attention?
- Strawberry ( @Strawberry@lemmy.blahaj.zone ) 7•6 months ago
She’s an American actress who was in Handmaid’s Tale and a few other things and then blew up thanks to her role in Euphoria. She’s become a bit of a meme recently because online conservatives think that her boobs are anti-woke
- Zagorath ( @Zagorath@aussie.zone ) English3•6 months ago
What a bizarre story. Mr. W is me right now:
- FriendBesto ( @FriendBesto@lemmy.ml ) 4•6 months ago
Two reasons.
- hitmyspot ( @hitmyspot@aussie.zone ) 12•6 months ago
Did she just tell people up git good?
- jollyrogue ( @jollyrogue@lemmy.ml ) 9•6 months ago
git rebase
is only for terrorists. 🥸Also for me when I’ve been drinking and committed some really stupid shit into the repo. No one needs to know what I really think of my team members.
- 7heo ( @7heo@lemmy.ml ) 5•6 months ago
Yeah totally merge everything, people like a good spaghetti salad.
- Scrollone ( @Scrollone@feddit.it ) 3•6 months ago
spaghetti salad
Found the German :D
- lightrush ( @lightrush@lemmy.ca ) 7•6 months ago
git merge --no-ff
- SrTobi ( @SrTobi@feddit.de ) 4•6 months ago
git config --global merge.ff no
- JoYo ( @JoYo@lemmy.ml ) 5•6 months ago
Anyone mind explaining to me how
git rebase
is worth the effort?git merge
has it’s own issues but I just don’t see any benefit to rebase over it.- Jesus_666 ( @Jesus_666@feddit.de ) 12•6 months ago
I use interactive rebases to clean up the history of messy branches so they can be reviewed commit by commit, with each commit representing one logical unit or type of change.
Mind you, getting those wrong is a quick way to making commits disappear into nothingness. Still useful if you’re careful. (Or you can just create a second temporary branch you can fall back onto of you need up your first once.)
- bamboo ( @bamboo@lemmy.blahaj.zone ) English2•6 months ago
This 100%. I hate getting added to a PR for review with testing commits in the history, and I’m expected to clean those up before merging into main.
- Zangoose ( @Zangoose@lemmy.one ) 2•6 months ago
I feel like squash and merge on GitHub/GitLab is nicer for that anyway though, it makes the main branch so much cleaner automatically
- bitcrafter ( @bitcrafter@programming.dev ) 3•6 months ago
The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.
- rimjob_rainer ( @rimjob_rainer@discuss.tchncs.de ) 5•6 months ago
Daily circlejerk
- NullPointer ( @nullPointer@programming.dev ) 4•6 months ago
do it often. you may end up with 150 conflicts to have to wade through.