When you stare into git, git stares back.

It's fucking infinite.

Me 2 years ago:
"uh was it git fetch or git pull?"

Me 1 year ago:
"Look, I printed these 5 git commands on a laptop sticker, this is all I need for my workflow! branch, pull, commit, merge, push! Git is easy!"

Me now:
"Hold my beer, I'll just do git format-patch -k --stdout HEAD..feature -- script.js | git am -3 -k to steal that file from your branch, then git rebase master && git rebase -i HEAD~$(git rev-list --count master..HEAD) to clean up the commit messages, and a git branch --merged | grep -v "\*" | xargs -n 1 git branch -d to clean up the branches, oh lets see how many words you've added with git diff --word-diff=porcelain | grep -e '^+[^+]' | wc -w, hmm maybe I should alias some of this stuff..."

Do you have any git tricks/favorites which you use so often that you've aliased them?

Me typing
git rebase --help
GF: What!? Oh... nevermind it says rebase. I thought it said rebae.
Me: What?
GF: I'm the only bae you need in your life!
Me: ... This is going on devrant.

The superpower to perform version control on reality. (Git)

Imagine this universe (the current branch), which is made up of a series of events (commits).

Having this ability to allows us to:

- undo events (git reset/git revert)
- reorder events (git rebase)
- transfer to another universe (git checkout)
- derive a new universe from current universe (git checkout -b)
- delete a universe (git branch -D)
- apply an event from another universe (git cherry-pick)

and my favorite:
- merge universes and their events (git merge)

we have to resolve conflicting events, of course.

What else? ;)

Force Push Pitfalls😏

I "Git Pushed" my friend to "git commit" with a girl he likes for long time

But now my other friend wants to "git rebase" on top of her ....WTF

Now need to resolve this merge conflict 😂😂😂

Usually I do love my colleagues, but lately....

FOR FUCKS SAKE I AM NOT YOUR WALKING HUMAN GOOGLE SEARCH ENGINE SHITOVERFLOW CHATGEPETTO INSTANCE! READ YOUR FUCKING LOGS, DO A FUCKING INFORMATION LOOKUP, READ THE FUCKING MANUAL.

OH YOU HAVE A QUESTION YOU SAY? PLEASE FOR FUCK SAKE ELABORATE WITH SOMETHING MORE THEN 'Please help me with the pipeline"' WHILE YOUR ACTUAL PROBLEM IS A LACK OF KNOWLEDGE AND UNDERSTANDING OF GIT, LINUX OPERATING SYSTEMS AND AUTOMATION.

OH YOUR BRANCH IS, WHAT, 3 MONTHS BEHIND MASTER? NEVER HEARD OF A FUCKING REBASE? WHATS THAT YOU SAY??? YOU DONT KNOW WHEN TO SKIP A COMMIT??? ITS YOUR FUCKING CODEBASE! READ THE FUCKING DOCUMENTATION !!!

WHATS THAT? YOU WORK IN VSCODE AND YOU DO T K OW HOW? AGAIN READ THE FUCKING DOCUMENTATION !

Self.end(rant)

Every time I mess up my git branch I usually find that its pretty futile to fix it with fancy commands like 'git reset', 'git prune', 'git rebase', etc. I usually find it easier to just start over from scratch.

They should really add a command for that

'git fuck-it-start-over'

Let the student use their own laptops. Even buy them one instead of having computers on site that no one uses for coding but only for some multiple choice tests and to browse Facebook.

Teach them 10 finger typing. (Don't be too strict and allow for personal preferences.)

Teach them text navigation and editing shortcuts. They should be able to scroll per page, jump to the beginning or end of the line or jump word by word. (I am not talking vi bindings or emacs magic.) And no, key repeat is an antifeature.

Teach them VCS before their first group assignment. Let's be honest, VCS means git nowadays. Yet teach them git != GitHub.

Teach git through the command line. They are allowed to use a gui once they aren't afraid to resolve a merge conflict or to rebase their feature branch against master. Just committing and pushing is not enough.

Teach them test-driven development ASAP. You can even give them assignments with a codebase of failing tests and their job is to make them pass in the beginning. Later require them to write tests themselves.

Don't teach the language, teach concepts. (No, if else and for loops aren't concepts you god-damn amateur! That's just syntax!)

When teaching object oriented programming, I'd smack you if do inane examples with vehicles, cars, bikes and a Mercedes Benz. Or animal, cat and dog for that matter. (I came from a self-taught imperative background. Those examples obfuscate more than they help.) Also, inheritance is overrated in oop teachings.

Functional programming concepts should be taught earlier as its concepts of avoiding side effects and pure functions can benefit even oop code bases. (Also great way to introduce testing, as pure functions take certain inputs and produce one output.)

Focus on one language in the beginning, it need not be Java, but don't confuse students with Java, Python and Ruby in their first year. (Bonus point if the language supports both oop and functional programming.)

And for the love of gawd: let them have a strictly typed language. Why would you teach with JavaScript!?

Use industry standards. Notepad, atom and eclipse might be open source and free; yet JetBrains community editions still best them.

For grades, don't your dare demand for them to write code on paper. (Pseudocode is fine.)

Don't let your students play compiler in their heads. It's not their job to know exactly what exception will be thrown by your contrived example. That's the compilers job to complain about. Rather teach them how to find solutions to these errors.

Teach them advanced google searches.

Teach them how to write a issue for a library on GitHub and similar sites.

Teach them how to ask a good stackoverflow question :>

!rant.
Here's some useful git tricks. Use with care and remember to be careful to only rewrite history when noones looking.

- git rebase: powerful history rewriting. Combine commits, delete commits, reorder commits, etc.

- git reflog: unfuck yourself. Move back to where you were even if where you were was destroyed by rebasing or deleting. Git never deletes commits that you've seen within at least the last 50 HEAD changes, and not at all until a GC happens, so you can save yourself quite often.

- git cherry-pick: steal a commit into another branch. Useful for pulling things out of larger changesets.

- git worktree: checkout a different branch into a different folder using the same git repository.

- git fetch: get latest commits and origin HEADs without impacting local braches.

- git push --force-with-lease: force push without overwriting other's changes

git-rebase-no-conflict

What's your favorite shell alias that you made for yourself?

I use this one all the time:

squash () {
git rebase -i HEAD~${1}
}

Runner up though is `git-fuckit` which resets everything to origin/master.

just recently....

Working with the french person in the office and git gets me every time.

shit push, shit merge, shit rebase

Goddamn accent!

The power to change history.

Oh, wait, git already can do that!

My progression of learning git rebase:

Year 1: WTF just happened?! Where is my code?! *deletes and re-clones repo*

Year 2: Ok if I do it suuuper carefully I can get the other dev's one-line change into my branch...shit...shit...wait...fuck...oh lol it worked.

Year 3: Oh yeah let me organize my commits real quick. *drop pick pick squash reword pick fixup drop pick* *git push -f* 😎

a tale of daily frustration:

git fetch
*yup I'm up-to-date ...*
git add -p .
*hack in beautiful patch ...*
git status -bs
*correct branch, didn't forget any files ...*
git diff --cached
*yep, that is what I mean to commit ...*
git commit -m"[TKT-NUM] Meaningful commit message"
git log -p -1
*double-checking ... looks good ...*
git push remote tkt-num-etc

*for a brief moment feel accomplished ...*

*notice typo in commit message ...*

I don't have a funny image or punchline to sum this post up. But know that if you recognise this feeling, then I am your brother in git.

Please, stop being afraid of git rebase.

Please stop merging master branch into feature branch just to fix pull request conflicts.

Super stressed.
What I did is:
1. git pull --rebase
2. Forgot to build to check if everything is working after pulling new changes
3. git push
4. Now, I realized I forgot to implement a method of the recently changed interface.
It's a production code. Not a joke. And was my first push to prod and I messed it up.
Sad life. Fixing it. Senior Devs must be crazy for my silly mistake.

git pull valentine
git rebase you --onto me
git commit my-love

We're no strangers to code
You know the conventions and so do I
A full commit is what I'm thinking of
You wouldn't get this from any other dev

I just want to tell you about my problem
Gotta make you solve it for me

Never gonna git you up, never pull you down
Never gonna rant around and rebase you
Never gonna merge your branch, never gonna say $#@*!!
Never gonna risk a cry and build you

How can people use git like that ?
Paris' metro has a simpler network.
If you can stop yourself from all working on the same branch at least do `pull --rebase`.

Two things before this all:
- I fucking love gitlab so far
- I miss the fuzzy searching from sublime text, as vsCode still can't do it properly..

I was fed up with all the shitty overbloated git deployment scripts, sync scripts, automatic backup solutions and hosted git servers out there, so now my own solution is:

- remote git cloned local files
- local files are synced via dropbox, to easily edit them on any device
- all changes and deleted files are saved up to 1 year on dropbox
- remote has gitlab running and webhooks setup
- the webhooks point to my node scripts, which then rebase the code to its dedicated dev server
- daily server backup with 7 days roll
- cold storage backup each 30 days

Sounds like overkill, but from my experience, you really can't have enough places that have a backup, especially coldstorage backups.

My goal in general though is to have everything on my computer backupped and ready to go asap, if something happens.

I wanted to just use a virtual machine for development stuff, but that wouldnt be able to run on my laptop, so I need a more general solution, where I sync all configs and all projects across. (and have some sort of basic list of tools needed, so I dont need to remember them)

Found for example something for vscode to sync its settings and plugins via any sort of git, will give it a try in near future too.

The more i use git.. more the fun it is.. Just found out the usage of rebase and cherry-pick.. I have read about the implications of these commands in a shared repo.. But it is fun to use it in a solo repo..

So I was told why a bash with Git isn't allowed in my company.

The people that built the development kit (IDEs, tools, etc) estimated that Git wasn't necessary since integrated in Visual Studio.

They clearly never tried to do a pull request or a rebase then. Good to know.

(a coworker gave me a way to have a bash anyway, so that made my day \o/ but rant needed anyway)

Caught a co-worker's gigantic fuck up today – dude totally wiped important code off master with a terrible git rebase + git push.

Gave him the nicest earful I could muster, but I think this is one of those times where I'm allowed to be royally pissed.

Not necessarily a "language" per se, but goddamn do I love git's rebase function. I mean, that shit lets you rewrite history!

Just imagine how the world would change if we could do a rebase on it. 🤔

OH
MY
GAAWWWWWD

The funniest thing happened today. I was helping a teammate rebase his branch onto master. Since his root was a merged local branch with 3 commits already in master, but squashed, we had to do an interactive rebase. So we have 3 commits to drop, and one to pick. He was using vsCode on windows, so he got vi to edit the rebase. I told him to change the first three pick for the letter d (alias for drop). Since he was not too familiar with vi, he only changed the first letter. I was like : dick is not a valid command, it's just d. Then he removed it and did the same thing again! When he finally understood, we both died of laughter,and so my ghost is now writting this rant. In the bus. Laughing like a crazy person. 😎

Merge VS Rebase:
- Did you pick a side?
- Practical tips? Like dealing with merge conflicts
- Have you ever regretted using either?

My answer
* My team squash-merges all branches to master so we don't really care what the branch history looks like. Master history should be pretty - but a branch history can be ugly and filled with a dozen commits.
* Practical tip 1: use `git config rerere.enabled true`. rerere stands for "reuse recorded resolution" and this means if you rebase often you don't have to resolve the same merge conflict twice.
* Practical tip 2: use `git commit --fixup oldcommithash` and then rebase with `--autosquash`
* I like using Rebase. But I have regretted the amount of time I've spent on trying to rebase old branches with many commits only to give up and to `git rebase --abort` since I realised I couldn't handle trying to reapply all the commits chronogically as the changes in the 1st commit were no longer relevant.

Never `git rebase` when you get home from the pub....

GIT COMMMIT LOG VERSION 011
-------------------------
4cc7d0d Derp, asset redirection in dev mode
6b6e213 Lock S-foils in attack position
1e44549 I am even stupider than I thought
2f6bec9 You should have trusted me.
891851a To those I leave behind, good luck!
3367d77 Update .gitignore
46d6b0f Merging the merge
b12f6fe First Blood
0598e4f 8==========D
9151ff4 Finished fondling.
3a0ec1e ...
8358c20 c&p fail
bc1e834 magic, have no clue but it works
31bb17a I don't get paid enough for this shit.
21edb91 :(:(
7a71610 Stephen rebase plx?
2060661 Copy-paste to fix previous copy-paste
21ac5d2 Handled a particular error.
2dedd90 pam anderson is going to love me.
c3d4c83 omg what have I done?
d38bafd Herping the derp derp (silly scoping error)
e461773 Merge pull request #67 from Lazersmoke/fix-andys-shit Fix andys shit
1faf82b Is there an award for this?
1f6e3f3 Feed. You. Stuff. No time.
6f0097d I'm too old for this shit!
133179e I'm just a grunt. Don't blame me for this awful PoS.
d3e5202 harharhar
57d9a7c THE MEM TEST FUNCTION YOU ARE LOOKING FOR, IS HERE. SAY THANKS FOR THIS COMMIT MESSAGE

I think the reason why git beginners have a hard time with it is because the api is a bit untuitive.

For example: if you want to "unstage" staged changes, you run git reset, and if you want to "delete" those changes from your working copy, you git checkout those files.

But then, you find out that you can do all of that if you git add . and git reset --hard.
So you're like "huh..."

And then you discover that if you end the resethard with a branch name/commit id then you also make current branch point to the commit or that branch/commit (respectively).
So you're like "huh..."

And also if you add a commit id or branch name to git checkout, you change the current branch to specified/enter detached state with HEAD pointing to that commit (respectively).

Oh and you don't use git branch to create branches, you use git checkout -b because it's a lot shorter.

So here's a rundown: git reset mutates things related to files, but also mutates things related to branches.
git checkout also mutates things related to files and mutates things related to branches too (in a diff way). Also, creates new branches.

I don't think this is intuitive. We users use the same commands for different purposes with just a different flag.
Commands shouldn't mutate different types of things. But don't composite commands (as in, "smart" commands that mutate different things) shoudln't be a flag in an existing command, it should be a single new command of its own.

Maybe if I reread the internals of git now, I'll be able to disgest the dozens of technical terms they throw at you (they are many). And in my mind, the api will cognitively fit to the explanations.

Here's another one that feels weird too.
If you want to make your changes start on top of someone else's commit, you do git rebase.
But git rebase -i can be used for that, and also to delete, modify changes or message of, reorder or combine previous commits of the current branch.

Maybe the reason why several things we do overlap with the same commands is because they internally do similar things, and while not separating those commands might make it less intuitive, it makes them more sensible? i dunno...

disclaimer: I'm not setting this opinion in stone though, and am aware that git was created by one of the most infuential programmers.

Holy shit interactive git rebase is the best thing

Well, learned how to git rebase today, which was nice.

When you git cherry-pick for the first time, screw up, rebase-drop, repeat, screw up again, and end up just pasting the correct versions of the files and commiting on top of the branch.

Dirty, but it works.

Team leads who act like they're the terminal god, but screw up every single rebase they touch 😡.

Yet, I, who stick to git GUIs have almost never had a git problem 🤷‍♂️

After almost 8 years of professional career, I've used "git rebase" only once and quite recently to be honest 🙊🙊

How well do you speak git? Name all commands you know how to use 😄:

init, add, commit, remote, cherrypick, push, rm, rebase, reset, submodule.

Did I miss something?

For the first time in my life I removed a wrong commit with git rebase and I did not made a mess.

More then 10 years of using git and keep learning.

I love git stash.

It's helps a lot for doing refactors to me. I guess it's not the most complex workflow, but it wasn't obvious to me when I started with git. Let me explain.

Refactors. As you start writing the first lines of a refactor, you start to notice something: you're changing too many things, your next commit is going to be huge.

That tends to be the very nature of refactors, they usually affect different parts of code.

So, there you are, with a shitload changes, and you figure "hey, I have a better idea, let me first do a smaller cohesive commit (let's call it subcommit) that changes a smaller specific thing, and then I'll continue with the upper parts of the refactor".

Good idea, but you have a shitload of changes nearly touching every file in your working copy, what do you do with these changes? You git stash them.

Let's say you stash and try to do that smaller "subcommit". What sometimes happens to me at this point is that I notice that I could do an even smaller change inside this current "subcommit". So I do the same thing, I git stash and I work on that even smaller thing.

At some point I end up `git stash pop`ing up all these levels. And it it shows that git stash is powerful for this.

* You never lose a single bit of work you did.
* Every commit is clean.
* After every commit you can run tests (automated or manual) to see shit is still working.
* If you don't like some changes that you had git stashed, you can just erase them with git reset --hard.
* If a change overlaps between a stash you're applying and the last "subcommit", then
if they differ, git shows conflicts on the files,
if they are identical, nothing happens.

with this workflow things just flow and you don't need to wipe out all your changes when doing simpler things,
and you don't need to go around creating new branches with temp commits (which results in bloated temp commits and the work of switching branches).

After you finish the refactor, you can decide to squash things with git rebase.

(Note: I don't use git stash pop, because it annoys the fuck out of me when I pop and you I get conflicts, I rather apply and drop)

Friend: Hey I am rebasing my commits and got stuck into a weird window and i was not able to come out of it?
Me: It is vi LMAO. Just press `:wq`
Friend: Wait I'm pressing the same but still nothing happened, it is displaying on my screen?

... After 200 messages...
Me: Just close the computer and I am going to Himalayas. Peace

Share your own useful terminal aliases here:

- grm=git rebase origin master
- gforbm=git fetch origin && git rebase origin master
- vm=vim Makefile
- idea=vim ~/repos/ideas/README.md (where I store all my programming ideas)

I hate git rebase! Hate! Double hate! Hate e to the x!

Sick of merge commit by commit!!!

I believe Torvalds hates it too.. please tell what’s the big deal not having clean history. Enlighten me.

git rebase -i HEAD~48

* children are crying on the background

That moment when you forget you're on the live environment and you git pull --rebase from an old repo because you thought you were on a local box and you set the wrong url for the git project.

We've all been there before mastering git commit --amend, rebase, and squash

Git :- Push rejected. Merge or Rebase?

Me :- git push -f origin master.

git rebase > git merge

I'm honestly tired of colleagues completely fucking up the git history along with creating conflicts for no reason at all.
How do you even manage to "recommit" changes when merging?

I can't even squash properly because there are 5 merge commits on the feature branch. Fuck off

They told the intern to "just rebase". The unflawed masterminds of HR also gave the intern more permissions than they did me on Stash.

Now I can't even fix our interns "just rebase" without waiting two days on a permissions ticket.

It's going to be a good week. 😑

Lesson learned. As a newbie to git and vcs in general, always verify a rebase to make sure you didn't accidentally delete your last days work before force pushing and overwriting the company repository. Also, don't get into a situation where you need to do that in the first place.

Ok finally, I can tell now.

There's a college project I'm in with 2 more people that uses Python and AnyLogic (separately).
We also need to write some LaTeX, so as I was already using PyCharm for the Pyshit, I used it for the LaTeX and for Git.
I used it for Git too because I didn't know how it used Git and was worried that if I used the console it didn't recognize something or glitched out or something. And what the hell, it's a mature IDE, what could be so hard or possibly go wrong?

I had to re download the repo a couple of times because between pushes, pulls, merges and commits something happened and the repo ended in a weird state.
These are all the things I do:
Add, commit, create branches, merge, push, pull and delete branches.

So, I hadn't opened in some time. The last time I tried to bring something from another branch, and stayed up late to finish something. I was waiting for my classmates to join the call when I thought something like "Hey, I should commit what I did until now, it worked great.". When I examined the IDE I found out I was in the middle of a rebase or something. I start clicking buttons to at least try to commit. I press "Skip Commit". I lose everything.

What the fuck‽ As you can see in the comprehensive list above, I never do something similar to a rebase. Apparently when I tried to merge a couple of branches, the stupid IDE thought I tried to do a rebase and never asked me to finish it. Why do something I have never asked? Plus, why haven't you prompted me to finish the operation? That's so stupid. I'm never trusting IDEs again.
I was so lit for losing so many hours of work I did a couple of weeks before, I would have to think it and do it all over again because of something I never asked.

We spent an hour looking for a way to recover the lost code.
Why an hour, you ask, if you can use the Local History for that in PyCharm?
Because none of us had used it before and the articles we found said that you had to open it from the toolbar. From the toolbar it was greyed out.
Then I found the option in the contextual menu of the files. Recovered the LaTeX files but on the AnyLogic files, it was greyed out.
I had to open the Local History of the folder containing the AnyLogic file.
And that was that.

I almost faint.
Fuck Python, fuck PyCharm.

I don't copy meme , I don't reuse codes.

--- Just Joking ^_^

After having witnessed developers use IntelliJ's built-in git functionality, I am persuaded that it should have never existed in the first place.

Asking you if you want to git add after every file you create, providing dangerous shortcuts that do pull, merge and push at once, but most importantly providing just enough comfort to keep their users ignorant about interactive git add or rebase, and other advanced git functionality.

The search for all the UI buttons + IntelliJ's baseline 5G RAM consumption is both slower and more error-prone than using the Git CLI

alias 'git pull'='git pull --rebase'

Yesterday, I was expecting my merge request to be closed.
I've done all the stuff my tech lead told me to do.

All tests passes, green light boyzzzzz.
Gitlab CI pipeline passes, greeeeeen light I said.

In Jenkins everything f*cked up...

Why ??

Well it was a conflict with 3 other MRs, missing rebase from other dudes.

And because they were remote working, got to clean up all this mess.

That's was a day off.

PS : well that's was not so off, I could fix a UB on a ternary and extend a test which was not covering some cases.

PS2 : learn git damn

Today, rebase finally made sense to me and I was able to squash a branch to remove a whole lot of unnecessary commits.

It only took 2 years... Guess all three times I used git in command line and all the Linux terminal/acting finally made a synergy.

Given I had to use force push that means it's like overwriting an existing repo with a different one?

Remember how u all got traumatized by tapping ctrl + s several times? More than once as if once wasnt enough? That same way now i got traumatized to `git pull --rebase` more than once before i create a new branch...

When your changes keep being reverted and you finally discover the 'experienced' contractor has been using rebase and 'take mine' in git merges.

Git is way too complicated, but even then I still get painfully annoyed when someone needs assistance with using it. Especially when they're using some GUI I don't know. You mean this thing can't rebase??

You know what really grinds my gear?
.
.
.
Commit messages like this

git rebase is like fish.

Hours after the kill: hmm, tasty.
A day after the kill: not too bad.
A few days: time to toss this in the trash
More than a week: dig a hole and bury this thing before it stinks up the neighborhood.

That being said, I'd rather eat a plate of Hákarl than deal with rebasing a diverance that is over a month old. I simply don't use rebase. It's just too stinky. I just merge very often and keep things in sync.

If you need the effect of a rebase without the crazy hassle:
git checkout master
git checkout -b rebase_branch
git merge --squash dev_branch

My mind was blown when I first discovered the interactive flag of git rebase.

Worst one was git rebase vs merge with me defending merge against rebasing everything into a single commit before review... making my existence on this planet miserable.

It’s certainly a feeling of progress as a dev when you get to using the advanced features of git to rewrite history successfully.

Though to make this a proper rant: holy hell what a ride! I’m glad I had everything backed up somewhere. Somehow I’d went Thanos on the repo. Deleted about half the files at random. Had to fast forward and then rewrite the history via rebase. Dropped a bunch of commits I think I should have squashed. I’m still wondering if I even did the right thing. I think cherrypicking is what I’ll go for next time. My repo now reads 59 commits behind but whatever. All my work got into one commit which is what the dev controlling prod wanted.

When you have a brain fart and forget the difference between fix-up and squash in Git rebasing. Why yes I wanted to stay an hour late at work redoing the changes I just lost!

REBASE BEFORE CREATING A PULL REQUEST

Especially if you've had to pull from main 7 times. No one has pulled from your branch, you have no excuse!

that feeling when you go through a rebase hell and after all, it finally rebases

Forgot to "git rebase --continue" after fixing conflicts, wondering why my code doesn't work. EVERY SINGLE TIME ahhhhhhhh

I ran `git rebase` on a shared branch and pushed it to the origin. It messed the whole history. I tried a few things to fix what I did (I don't remember the commands I tried) but I only made it worse.

The final result? Even though I was new to the project, every old commit in the history was changed to include my name as the author of that commit.

Lesson learned the hard way :hands_down_emoji:

I need some help. I have a 1 months old MR in gitlab with 5 commits of a feature that I have to revert.

I have hard time understanding how to solve git revert conflicts and frankly this three windows GUI on intellij idea is very confusing to me. I am like afraid that I will accept a bad change or miss something.

Is there any other way to make this merge conflict solving easier? I was thinking maybe I could just rebase to head where I added my commits, revert them without conflicts and then rebase that branch on latest develop?

In that case I would be solving merge conflict by adding stuff instead of removing old stuff and being afraid that I will mess up something. Goal is to create a revert feature MR.

on desktop:

to edit my post i have to copy it, delete it, add a new comment, paste it, correct it and post it..

i feel like i'm doing a git rebase on master

'git pull --rebase' a day
Keeps the merge conflicts away

Scrum Master: Any updates on this ticket?
Me: ...

If i have 2 branches on git
- main
- infra

You cannot push directly to main. It is forbidden. You can only merge to main

Now. Once i push to infra branch. Assuming all the shit went good pipeline passed tests passed etc. Then i merge it to main.

Now

Locally while im on infra branch. I have to pull latest changes from main otherwise ill fuck up everything and cause conflicts.

After trial and error i realized i just have to do:
git fetch

This fetches all shits from main (defaukt branch) into infra branch. And now it works. No rebase. No pull. Wtf?

Is this the correct way to do it?

Also i need someone to explain this to me like im 5:
- git pull
- git pull --rebase
- git fetch

What is the difference between those 3 commands? I tried googling and chatgpting but i cant seem to understand any explanation. Explain it to me in simple terms with examples

How to use git rebase when working with master and staging branch?

It might be a stupid question, but I really like the idea of creating a feature branch, work on it, if there are multiple commits squash them, rebase in top of master and then create a pull request from that branch to master.
It keeps the gut log pretty clean.

However, how would you do this, when not only working with a master branch but a staging/testing too?
Would you just rebase onto staging, merge to staging and when everything is fine, rebase onto master and merge again? Is there a netter way?

git rebase is really nice. Can recommend it to clean up a git history :D

Joined a new team and was presented with the statement

'We can't use git pull on our repo, we rebase, it works better than merge'?

Have a question about git rebase with android studio.

So I have a feature branch which I finished working on, I made a pull request to develop branch and now I see many conflicts because develop is few commits ahead.

In android studio I switched to my feature branch, then did a git rebase develop and resolved all conflicts. After conflicted files were fixed I did a git add conflicted_file and continued with git rebase --continue until the end.

Now everything is finished. I have a local feature branch that was rebased to current develop, and I resolved all conflicts.

Problem is when I do a git push to my remote feature branch, I get a merge conflict error conflict from android studio and now I have to solve all merge conflicts yet again for some reason.

What I am doing wrong?

Looking back on it, I don't understand why I used merge commit strategy as go-to to merge git branches the first +-3 years of my career. It sucks

Guess I was just afraid of rebase after I accidentally erased history the first time I used it and failed.

And I thought I knew a lot about practical git... But today I learned about fixup commits and autosquash. Awesome!

Is git a history of what happend or a list intentional changes?

Had this discussion with my boss. He said i shouldn't rebase my feature branch because it is too much hassle (I did some squashing and fixups). I should just commit on top and merge master into my branch.

What is your git philosophy?
Do you "own" a feature branch until you create the PR?

!rant

/* Key to piece of mind: Work fast, commit soon, let co-workers deal with rebasing */

git rebase >>> git pull/git merge

Let's have a discussion, devRant style:

Fuck history, git rebase to the rescue! Especially interactive rebase is a power tool. I use it all the time.

At this moment I won't argue why or why not. Let's hear what you have to say!

!rant
To embrace the TIFO (today I found out)
$git rebase -i <hash>^

You can reorder commits and squash.
I just used it, to amend a commit that was not HEAD with some changes I’ve done later.

getting tons of fucking merge conflicts on rebasing remote branch with current master because that mockerfucking code review is still pending

Here goes nothing!

git merge "conflicts"

(not really an issue, but still a waste of time and concentration, when every now and then, using more than one branch, small edits, merge, and rebase, git diff complains about "conflicts" that are obvious to solve for a human but still not for a machine, despite the hype about the age of AI, coding co-pilots and the like...)

I played around with Git Rebase today to learn a bit about it, and it was fun, but in the process I completely obscured my process and erased a commit that has a published artifact associated with it. What remains is a few incremental preparation commits hoisted up from today's cleanup, then a pair of commits on two projects both of which only compile against the version of the other repo built from the other commit.

Pull >>>> Rebase

The advantages of rebase (clean git history) are minimal but the risks are massive (rebasing in the wrong direction, rebasing after raising a PR, rebasing a public branch)

Contributing to big repositories on git be like,
and here goes my push,
Wait, I need to rebase
Ok, done, now push
Oh fuck, I need to rebase again.
The cycle goes on 😓

Can someone tell me how to properly rebase changes from main branch

I always fuck myself over. Fucking merge conflicts i caused by myself. Since the CD pipeline creates a commit or i merge into main from a side branch, i often forget to pull those changes locally from main branch

What happens then is i just create a new branch to start working on the next feature

git checkout -b feature/shit

Totally forgetting to first do

git pull --rebase

From main branch. Because of this when i push shitload of features to feature/shit branch and then try to merge that shit into main. CD pipeline gets fucked. There are merge conflicts now because i havent rebased

Question -- if i switch to a new branch, make a shitload of changes and forget to rebase from main branch First, what command do i type to rebase right there (on the new branch) but rebase from main branch so these conflicts dont appear?

No. You cant „git rebase -i master“ your bad memories!