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?

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? ;)

This is what I found in the logs:
3280546 I had a cup of tea and now it's fixed
9daaf6c copy and paste is not a design pattern
958ca5b It compiles! Ship it!
a9edf8d LAST time, Masahiro, /dev/urandom IS NOT a variable name generator...
438072f 640K ought to be enough for anybody
1fb839b Too lazy to write descriptive message
4d70890 ...
d6ce0c8 Ugh. Bad rebase.
a00b544 Programming the flux capacitor
49715cb Fix my stupidness
4babf07 Do things better, faster, stronger
49b3a7b SEXY RUSSIAN CODES WAITING FOR YOU TO CALL
12c7b55 formatted all
2658c87 and so the crazy refactoring process sees the sunlight after some months in the dark!
2376c89 - Temporary commit.
a83220a I honestly wish I could remember what was going on here...
3347007 work in progress
3382b4c well crap.
109748a Glue. Match sticks. Paper. Build script!
c3f025e Useful text
70394e7 Who knows WTF?!
0d78f14 breathe, =, breathe
5344e39 removed tests since i can't make them green
8a3a6bf better grepping
2777cc4 first blush
cf620ff Continued development...
9591c19 Too lazy to write descriptive message
767e0cd Some shit.
763602a Yes, I was being sarcastic.
8d7a602 /sigh
c6296e5 rats

Why is the contributing manual of your open source project more thoughtfully cultivated than your code style guide and testing procedure?

Why the fuck do you care about the message in my PR, or even merge vs rebase of commits, when your spaghetti-tomatosource is so richly saturated with critically minced bugmeat?

Why are you standing there, shouting at me about your convoluted rules, in your little brown uniform? Why do I feel like the enemy when I contribute a useful fix, something which makes the code work better?

You know what, fuck all of you, you jilted acetous neckbeards, I will deploy my secret weapon, I will bypass the power you hold over your tiny fascist digital dominions.

If you play it like this, I will summon the nefarious vile side of Open Source. I will usurp your throne. I will stab out your crying eyes, rip out your conceited tongue, impale your lonely heart.

Tremble before me! I wield the almighty, legendary Fork!

The king is dead, long live the king!

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)

My team lead force pushed to master. This guys always complains when we merge PRs with wip or fixup commits and he just did it himself and tried to cover it up doing a rebase on the master branch.

Good job fucking up everyone. 👍

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

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

shit push, shit merge, shit rebase

Goddamn accent!

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* 😎

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.

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

Why the hell do you keep commit+push your shit to the master branch! We have develop, feature and hotfix, you *************!

Just because you want to test something in prd environment, you don't mess with the master to build the production image. And you do not even rebase fucking develop branch and keep it out of sync you POS!

Excuse my language, thank you.

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..

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.

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.

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.

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

Don't rebase and force-push a shared feature branch that's still in active development. FFS. A "senior" developer should know better.

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)

Trying to un-fuck a botched rebase of a months worth of work. It took me a couple days, but it forced me to learn a lot about git's best practises and gotchas. It also taught me not to keep a months worth of work on a single branch!

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

Why do some developers rebase or resolve merge conflicts when you can just email each other changes and force push?

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

The „UI-God“ in our team has never heard of dry or clean code.
Clashing classnames for modules in global namespace, gives a f* about patterns, naming conventions, structure and everytime I rebase it breaks my code.
I need the same amount of time fixing his work as he spends on it.

Team leader doesn’t know the difference between merge/rebase nor uses pull requests to propose changes to a humongous repo, just two branches where everyone commits and pushes freely! 💩💩💩

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.

Question: I completed a feature on separate branch. Since I'm not allowed to merge things on the master branch (only pm is allowed to) I open a pull request.

However, PM has decided that he will only accept PRs which can be automatically rebased & merged.

So now i opened my PR and PM says that GitHub complains that the branches cannot be automatically merged.

So I rebase the branch - push and tell him to try again. But the same issue - GitHub won't merge the PR. So I try again - rebase the feature branch onto master which runs me through the same rebase steps as on the last try. I successfully complete this one too and push. But still - GitHub won't swallow the PR.

Anybody an idea what could've went wrong here?

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

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.

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

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?

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

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

You just have to fucking love it... Trying to get a pull request merged into our master, but because we *must* use fast-forward-only a single change on the master forces a rebase on my side, and an other complete build which takes some 15 minutes.

And of course the entire dev team is in goddamn overdrive and working their ass off, so here I'm sitting hoping to chance on a 'calm' 15 minute slot on the master without any other merges... Let's try attempt number 5 to merge this sucker.

When you're getting roasted and given tasks of fixing and changing some code you didn't write trying to get a PR in, and the person you paired with who wrote it has moved on to other work.

Moreover you'll be stuck taking the blame down the road if they don't fire you, as the policy is to rebase squash merged in PR's so it will all unfortunately be under your name.

OMG I have a proper rant from last night.
It involves an unwanted rebase and lost uncommitted code from weeks.
Tune up after my shift.

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.

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.

How do you deal with situation when u need to merge multiple feature branches to develop branch? All feature branches have develop branch as base. So as soon as one feature is merged to develop then there will be contlicts in other feature branches.

Should I merge first feature branch to develop, then rebase feature2 branch on most recent develop and then merge the rebased feature2 branch to most recent develop and continue like that?

What if later I need to do hotfixes for previously merged branches? Should I revert them then rebase them on most recent develop and once again merge it to develop? Or should I just make small commits for fixes.

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

!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.

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?

Question about scrum in terms of developer/QA workflow. We have a problem in our team: basically when a dev submits an MR it needs to get 2 approvals from devs and then task is marked ready for qa. Now problem here is that qa takes 2-3 weeks to get to the task and when they do usually MR has merge conflicts and since QA are quite new-ish they have to wait for dev for conflicts to be resolved, ergo rendering the MR unable to be tested until dev resolves the conflicts.

Our teamlead proposes to solve this by forcing devs to rebase everyday (even if QA will get to working on the task 3-4 weeks later). Problem with that approach is that each conflict resolve removes approvals. So I had a situation where in 3 weeks I rebased like 15 times and 5 times I had resolve coflicts and because approvals were lost I had to annoy all devs and ask for reapprovals. And this is only with 1 MR. Now imagine all devs doing rebasing daily and spamming each other for reapprovals. Its not efficient.

Anyone could advice how to solve this issue?

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'?

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?

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

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.

When you have just made a new feature and you rebase to master, and the project won't compile because someone else pushed something which doesn't work...

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.

And one more.

When my senior ask me to rebase the PR, which I submitted f*n one month ago.

Where it was f*n important that time.

And your pull rebase ask you to fix the conflicts.

And you realize you need to reapply the changes again on top of the master.

And you have to run the FTs again.

Damn....

I'm working in a project that seems to be like a Multiplayer Tetris of Little Poo:

- figure out what the heck you have to code, because there is no debugging, the deploy to your devenv takes ages, the documentation does not exist or is unreadable, plus you are new and you are in a different timezone
- once you have your code, slowly pass the reviews of your remote team that will complain for every little extra line you've added for readability, slowly converting your code into a poo-like form, until it is completely shaped as shit
- repeat steps 1-2 until you pass the linter
- the carefully place your shit-shaped-code in the right place of the pile of shit
- wait for someone else to complain (like 'please rebase' 'new lint rule please fix' - oh, did I mention that? lint rules do not match between local, review and deploy?
- repeat from step 1 until you quit your job (which will happen in a few weeks)

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...)

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 😓

Just rebase a merge conflicts with LFS enable. What a fucking nightmare. And bitbucket, please eat a dick you useless cunt.

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?