There have been multiple accounts created with the sole purpose of posting advertisement posts or replies containing unsolicited advertising.

Accounts which solely post advertisements, or persistently post them may be terminated.

JATtho ,

To produce 1 commit, I end up rebasing the damm thing at least 3 times. If there is an problem, it’s at least 2³ times.

cupcakezealot ,
@cupcakezealot@lemmy.blahaj.zone avatar

i like to create ten different checkouts of main, rebase them all slightly differently and then no fast forward merge them all back into each other

tengkuizdihar ,
@tengkuizdihar@programming.dev avatar

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.

nialv7 ,

That was you! I remember this.

tengkuizdihar ,
@tengkuizdihar@programming.dev avatar

AAAH NOT LIKE THIS

https://programming.dev/pictrs/image/23f78662-f914-4958-805e-583a849e5374.jpeg

bear ,

There’s 102 people mentioned in that commit and two of them happen to meet in the comments of a meme thread on Lemmy of all places. I love the Internet.

Atemu ,
@Atemu@lemmy.ml avatar

Merge is not the issue here, rebase would do the same.

tengkuizdihar ,
@tengkuizdihar@programming.dev avatar

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 avatar

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.

Bourff ,

Just for the record, I think you’re conflating git and GitHub. They are not the same thing, even if GH would like you to think so.

Atemu ,
@Atemu@lemmy.ml avatar

I am not. Read the context mate.

jaemo ,

Could have been worse. I mean, like, imagine of you were using like CVS and you put a watch on the root! Haha and then like every trivial commit in the repo caused everyone to in the entire org to get an email and it crashed the email servers.

Like who’d even DO that?! Though, I bet if you met that guy he’d be ok. Like not a jerk, and pretty sorry for all those emails. A cool guy.

droans ,

You sent over twenty-two thousand notifications lmao.

And then the bot added about as many tags to the PR.

Croquette ,

I know this is a meme post, but can someone succinctly explain rebase vs merge?

I am an amateur trying to learn my tool.

letsgo ,

Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.

Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.

I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.

reflectedodds ,

I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.

With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear “D E F” so you don’t actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B’. You’d have to try to demangle it by looking at authors and dates.

The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault. I always rebase because it’s equivalent to checking out the latest changes and re-branching so I’m never behind and the patch is always a unique set of commits.

Atemu ,
@Atemu@lemmy.ml avatar

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits.

Your notation does not make sense. You’re representing a multi-dimensional thing in one dimension. Of course it’s a mess if you do that.

Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is “branched off” from some commit M. D’s and A’s parent would be M (though there could be any amount of commits between A and M). Since A is “on the main branch”, you can conclude that D is part of a “patch branch”. It’s quite clear if you don’t omit this fact.

I also don’t understand why your example would have multiple merges.

Here’s my example of a main branch with a patch branch; in 2D because merges can’t properly be represented in one dimension:


<span style="color:#323232;">M - A - B - C - C'
</span><span style="color:#323232;">             /
</span><span style="color:#323232;">    D - E - F
</span>

The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault.

If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They’re much faster too.

reflectedodds ,

You’re right, I’m not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.

I’m so used to rebasing I forgot there’s tools that correctly show all the branching and merges and things.

Idk, I just like rebase’s behavior over merge.

Atemu ,
@Atemu@lemmy.ml avatar

The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they’re done.

jaemo ,

👏 Super duper this is the way. No notes!

ActionHank ,

I would advocate for using each tool, where it makes sense, to achieve a more intelligible graph. This is what I’ve been moving towards on my personal projects (am solo). I imagine with any moderately complex group project it becomes very difficult to keep things neat.

In order of expected usage frequency:

  1. Rebase: everything that’s not 2 or 3. keep main and feature lines clean.
  2. Merge: ideally, merge should only be used to bring feature branches into main at stable sequence points.
  3. Squash: only use squash to remove history that truly is useless. (creating a bug on a feature branch and then solving it two commits later prior to merge).

History should be viewable from log --all --decorate --oneline --graph; not buried in squash commits.

JackbyDev ,

Folks should make sure the final series of commits in pull requests have atomic changes and that each individual commit works and builds successfully alone. Things like fixup commits with auto squash rebase. THIS WAY you can still narrow it down to one commit regardless of the approach.

jaemo ,

Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably main). This generates a merge commit.

Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.

TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.

Croquette ,

Thanks for the explanation. It makes sense. To my untrained eyes, it feels like both merge and rebase have their use. I will try to keep that in mind.

bitcrafter ,

Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (git rebase --abort) and using a merge instead.

Croquette ,

I have the bad habit of leaving checkpoints everywhere because of merge squash that I am trying to fix. I think that forcing myself to rebase would help get rid of that habit. And the good thing is that I am the sole FW dev at work, so I can do whatever I want with the repos.

JackbyDev ,

Yes. They do. A lot of people will use vacuous terms like “clean history” when arguing for one over the other. In my opinion, most repositories have larger problems than rebase versus merge. Like commit messages.

Also, remember, even if your team/repository prefers merges over rebases for getting changes into the main branch, that doesn’t mean you shouldn’t be using rebase locally for various things.

Croquette ,

How would rebasing my own branch work? Do I rebase the main into my branch, or make a copy of the main branch and then rebase? I have trouble grasping how that would work.

jaemo ,

Here’s an example

Say I work on authentication under feature/auth Monday and get some done. Tuesday an urgent feature request for some logging work comes in and I complete it on feature/logging and merge clean to main. To make sure all my code from Monday will work, I will then switch to feature/auth and then git pull --rebase origin main. Now my auth commits start after the merge commit from the logging pr.

Croquette ,

Thanks for the example. Rebase use is clearer now.

JackbyDev ,

You’re still rebasing your branch onto main (or whatever you originally branched it off of), but you aren’t then doing a fast forward merge of main to your branch.

The terminology gets weird. When people say “merge versus rebase” they really mean it in the context of brining changes into main. You (or the remote repository) cannot do this without a merge. People usually mean “merge commit versus rebase with fast forward merge”

Croquette ,

Yeah I was confused because you are right, merge is usually refered as the git merge and then git commit.

It makes sense. Thanks for the clarification

jaemo ,

You nailed it with the critique of commit messages. We use gitmoji to convey at-a-glance topic for commits and otherwise adhere to Tim Pope’s school of getting to the point

JackbyDev ,

Gitmoji?

jaemo ,

gitmoji.dev

Quasi parallel reply to your other post, this would kind of echo the want for a capital letter at the start of the commit message. Icon indicates overall topic nature of commits.

Lets say I am adding a database migration and my commit is the migration file and the schema. My commit message might be:


<span style="color:#323232;">     🗃️ Add notes to Users table
</span>

So anyone looking at the eventual pr will see the icon and know that this bunch of work will affect db without all that tedious “reading the code” part of the review, or for team members who didn’t participate in reviews.

I was initially hesitant to adopt it but I have very reasonable, younger team mates for whom emojis are part of the standard vocabulary. I gradually came to appreciate and value the ability to convey more context in my commits this way. I’m still guilty of the occasionally overusing:


<span style="color:#323232;">   ♻️ Fix the thing
</span>

type messages when I’m lazy; doesn’t fix that bad habit, but I’m generally much happier reading mine or someone else’s PR commit summary with this extra bit of context added.

Deebster ,
@Deebster@programming.dev avatar

I looked at it and there’s a lot of them!

I see things like adding dependencies but I would add the dependency along with the code that’s using it so I have that context. Is the Gitmoji way to break your commits up so that it matches a single category?

jaemo ,

Yes, that is another benefit, once you start getting muscle memory with the library. You start to parcel things by context a bit more. It’s upped my habit of discrete commit-by-hunks, which also serves as a nice self-review of the work.

Deebster , (edited )
@Deebster@programming.dev avatar

I don’t see that as a benefit tbh - if I have a dependency, I want to see why it’s there as part of the commit. I’m imagining running blame on Cargo.toml and seeing “Add feature x” vs “Add dependency”. I guess the idea is it’s “➕ Add dep y for feature x” but I’d still rather be able to see the related code in the same commit instead of having to find the useful commit in the log.

I suppose you could squash them together later, but then why bother splitting it out in the first place?

I see that some use a subset of Gitmoji and that does make sense to me - after all, you wouldn’t use all of them in every project anyway, e.g. 🏷️ types is only relevant for a few languages.

JackbyDev ,

I must have read that blog post in the past because that’s exactly the style I use. Much of it is standard though.

One MAJOR pet peeve of mine (and I admit it is just an opinion either way) is when people use lower case letters for the first line of the commit message. They typically argue that it is a sentence fragment so shouldn’t be capitalized. My counter is that the start of sentences, even fragmented ones, should be capitalized. Also, and more relevant, is that I view the first line of the commit more like the title of something than a sentence. So I use the Wikipedia style of capitalizing.

jaemo ,

100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use reflog, cos…well, then you done messed up now son… (but even then hope lives on!)

aubeynarf ,

Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).

tatterdemalion ,
@tatterdemalion@programming.dev avatar

Rebase feature branch, merge commit into main (NO SQUASH).

cupcakezealot ,
@cupcakezealot@lemmy.blahaj.zone avatar

make the commit message be “we’ve fixed bugs and improved performance. to experience the newest features and improvements, checkout the latest version of the branch.”

temmink ,

great new features

Jia Tan

iAvicenna , (edited )
@iAvicenna@lemmy.world avatar

I personally prefer “git off my lawn”

bitcrafter ,

Ah, yes, the good old git off --my lawn command.

jaemo ,

Fuck a merge commit! Rebase ervray day bay bayyy.

lightrush ,
@lightrush@lemmy.ca avatar

git merge --no-ff

SrTobi ,

git config --global merge.ff no

expr ,

ITT: people who have no idea how rebasing works.

magic_lobster_party ,

Skill issue tbh

CmdrKeen ,
@CmdrKeen@lemmy.today avatar

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 ,

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 with git 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 ,

True, the real danger is using git reset with the --hard flag when you haven’t committed your changes lol

thanks_shakey_snake ,

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 ,

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 ,

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 ,

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 ,

Why should no one be touching it? You’re basically forcing manually communicated sync/check points on a system that was designed to ameliorate those bottlenecks

aubeynarf , (edited )

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 ,

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.

Socsa ,

Tbh, we just don’t hire people if they can’t operate git.

merthyr1831 ,

Heres my based af workflow:

git checkout -b feature-branch

rebase on top of dev whilst working locally

git rebase origin/dev-branch && git push -f

if i need to fix conflicts with dev-branch during a PR

git merge origin/dev

sorter_plainview ,

I have been using something very similar to this. In my team I insisted on people without any git experience working on a separate local branch, than the feature branch

. To ensure screw ups are minimal, we pull and create a local feature branch and then a new local only dummy branch, on top of it. Once the team is more comfortable with git, I am planning to treat the local feature branch as a dummy branch.

So far things have been pretty neat. Spaghetti is no more with minimal conflicts.

jollyrogue ,

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 ,

Yeah totally merge everything, people like a good spaghetti salad.

Scrollone ,

spaghetti salad

Found the German :D

rimjob_rainer ,

Daily circlejerk

hitmyspot ,

Did she just tell people up git good?

MyNamesNotRobert ,

I know how to use git pull, git push, git commit, git status and git add *. I don’t even know how git commit and git push works I just know you run them in that order. Whenever I break everything I give up and go outside.

RonSijm ,
@RonSijm@programming.dev avatar

Rebasing is for noobs.


<span style="color:#323232;">git reset head~42
</span><span style="color:#323232;">git push -f
</span>
shield_gengar ,
@shield_gengar@sh.itjust.works avatar

Holy shit

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • [email protected]
  • random
  • lifeLocal
  • goranko
  • All magazines
    •