Don't make this Git mistake | Conflicts!

[@marcialcabrera9016]

Easier “gif pull -rebase origin master” also helps fix merge conflicts

[@privatesocialhandle]

I just admit, I am not a git "master" but typically in most businesses if not all, this doesn't work because they would define a branch policy to block pushing directly to main/master. So, the merge doesn't take place locally (from your local branch to your local main) but from your remote branch to remote main. So, the workflow would be to: 1. Pull/fetch (however you need) into your local feature branch. 2. Push your local feature branch to remote feature branch. 3. Create a pull request from remote feature branch into remote master branch. 4. The PR gets reviewed by code reviewers and approved/rejected accordingly. 5. You complete the merge (if approved) and delete the feature branches (local and remote if you're done with the FR) or make more changes and repeat.

[@asian1nvasion]

I don't think he's pushing directly to master. He refreshes his test branch from master and then pushing to his test branch. But yeah I agree with you that is how most places work.

[@andrei_lazarev]

you should better commit locally and then rebase on just pulled origin master. so you won't get a merge commit

[@cuongphung-5089]

Right! Rebase make life easy on PR

[@JaredM990]

I prefer to squash the pr before merging back to master. I have way worse silent regressions when rebasing than merging.

[@sebastianbraun2473]

Rebase requires force push and only works if you‘re the only one committing.

[@adtc]

And then freak out when you get a merge conflict. LOL

[@FERnandezJjuan]

I just run: git pull origin master on my branch and I get same results

[@jon1867]

--no-ff

[@oswin4715]

You can but you’ll probably need to pull origin master on your local master branch to at some point

[@DhavalAhir10]

At the end you are doing the same. Suppose I am in test-2 branch. Now I ran git pull origin master. All latest changes from remote master comes and merge with test-2 branch. It is similar to first switch master and git pull origin master then come to test-2 and run git merge master.

[@vancheloChanel]

git fetch git rebase origin/master ... resolve conflicts if any Profit! And you don't need to switch between branches

[@adtc]

BETTER WAY: Pull daily and rebase over master. Fix conflicts before continuing work.

[@NoProblem76]

nah, just `git pull origin master --rebase` from the branch you're working on

[@comptvlee]

Don't forget --autostash just in case you're not done yet

[@H4KnSL4K]

1. A week or two!? You should be updating your branch more often than that (maybe daily) to detect conflicts and deal with them early. 2. You don't need to actually checkout the master (or main) branch. Do a 'git fetch --all' and then 'git rebase origin/master'. 3. It is often cleaner and preferable to rebase instead of merge. If you haven't pushed your [feature] branch yet, rebasing it off of the latest makes it look like all of your changes are simply off the latest version, and there aren't messy merges all over the place. e.g. 'rebase -i origin/master'. The merge conflicts will still be there, but the git history will be cleaner. You can also combine many small commits into larger more logical ones, so that it's easier to review.

[@adtc]

Honestly, pull daily and rebase over master. Fix conflicts before continuing work.

[@victorlongon]

You dont even to rebase as everyone is saying. Just do git merge origin/master, fix possible conflicts if any and push. When you merge use squash so you only have on commit going into master/main. I think rebase very often as unnecessary ands complexity.

[@cyrilgeorge7818]

Can't we use "git pull origin master" directly on the feature branch, or is there a differents ?

[@flodderr]

this video is stupid. you can but its a different command. git fetch origin main:main. Main already replaced master a long time ago as the naming convention btw

[@Red-vw7rw]

@@flodderrstfu liberal, we will continue to use MASTER branch btw

[@guuridev]

Just work from master branch, some self confidence dude, you doing great, and deploy on Fridays 🚀

[@adtc]

I'd totally deploy on Fridays. It's the best day to deploy on.

[@serb1146]

git pull --rebase first. You will merge your changes on top of the actual master. Then push staff. Also, to put changes on company develop, we usually do it over PR + review + TeamCity quality tests + E2E Tests + integration Tests + SonarQube test coverage.

[@m4rt_]

Just push to a separate branch, then make a Pull Request, and fix all merge conflicts.

[@EconomicsDomain]

git switch is the recommended way to change branches

[@scriptkeeper8243]

Merge to develop, then test on staging via a release of several branches. Once complete then merge the release to master.Gitflow baby

[@SpeedingFlare]

I usually stay in my feature branch, do git fetch to get the latest origin master, then do git rebase origin/master

[@dmytrosokolovsky8959]

I just usually go with one "git pull -rebase origin " command

[@xO_ADX_Ox]

Question for people that work in real word projects companies: how often do you usually have to commit or push?

[@JaskierRezzo]

There aren't any hard set rules for it. Some companies enforce pre-commit hooks but otherwise, you generally wanna commit often and push whenever you want to save it to the github/gitlab repo

[@dxvfdfx]

In this case we recommend use git rebase instead of merge because it’s feature branch you will make you commit more clearly

[@khoanhn]

Now you realize you have to spend an hour to resolve all conflicts at the end of the day. If the user story is independant enough, I think getting changes from main only when there are some I need and rebase when the brach is completed is a better approach.

[@velho6298]

You can use switch to SWITCH between branches.

[@mav474]

Bad message for the folks! Always rebase and squash the commits for inspection!

[@TheCodeTinkerer]

I learned this the hard way

[@murataht]

How bout rebase ? However this might be easier to understand

[@mondo1926]

rebase is the GOAT

[@aspirinemaga]

you've not mentioned the most interesting part... merge conflicts hah... anyway, in big companies, we do "rebase" instead with squashed commits once a Pull Request is validated to keep commit history on main/dev branch on point

[@TravisMedia]

Ha, yeah rebase is important, but intimidating for new devs or those still new-ish to Git. My thought is that you don't need it until you realize you do 😀

[@adtc]

@@TravisMedia All the "Git teachers" have gotten it upside down. Teach Git concepts, not Git commands. Rebase should be the default for a beginner, because once you understand it, it makes a LOT of sense. Merge is a shortcut you do because you don't want to understand. And NOBODY should do "git add --all". It should be BANNED from beginner vocabulary. Every beginner should be taught how to stage their changes properly and commit only related changes together with a proper commit message.

[@EnglishRain]

Also remember to use the --no-ff flag to retain development branch commit history

[@stosyst]

How do get your CLI auto complete please

[@Pedriniist]

Two weeks without merging? Trunk Based Development and Short-lived Feature Branches FTW

[@abdullahejaz5406]

what if just pull from master in test. 🤔🤔🤔

[@mexi_nation552]

what are you using in order to have vscode provide suggestions for you in the terminal?

[@tntg5]

rebase... always rebase master

[@flodderr]

Or if you work in a team and squash the pr anyways you can just merge master

[@tntg5]

@@flodderr the purpose of a rebase is to apply previous commits in the right order. Merge works best for 2 branches you have been working on. In large teams, rebase is the recommended way

[@flodderr]

@@tntg5 But that doesnt matter if you squash the pr commits tho. When im a lead and I look at our main branch. I just want to see commits that say the ticket and a general description of what it solves. I dont care about the 30 commits you had to make to get there, or commits like "fix linting" etc. which would happen if you rebase your branch onto master. Source: I work in a large team

[@tntg5]

@@flodderr yes, squash goes hand in hand with rebase. If a developer makes many commit in a given branch, he must squash them all together in one commit with a useful comment. Now, that same dev will submit a PR. But there are other PRs waiting in line. Say you have 3, A, B, and C. A is more urgent than B which more urgent than C. What you want to do is first include A. Now the dev who has published B, has to rebase (master + A) before applying B. And make sure his code doesn't undo what A has done as it is now approved.. And so on

[@flodderr]

@@tntg5 well actually you dont really. Also if you squash, you dont have to rebase. Your history will look the same with merging. But about the A B and C. If you hace cicd pipelines set up, as you should in a company, the PR pipeline will just tell you if there is a conflict it can not solve on its own. Only then you will have to merge master or rebase if you want. If pipelines succeed, you can just merge in A B or C in any order you want to really

[@amansarma417]

What if somebody has changed in master branch something that you also changed in test branch and you try to merge both won't it cause conflict?

[@meherprudhvi9368]

Now how to resolve conflicts

[@Yamas258]

Okay so we have our own main/master on our own computer

[@kaustubhkale6598]

Which extention you used for terminal suggestion

[@TravisMedia]

I use the zsh terminal and the zsh-autosuggestions plugin.

[@Smallwood-pw1mm]

Then 105 merge conflicts show up

[@chetandhongade6464]

I use git rebase

[@carcedopro7285]

I always have this fear with me that in the time i pull the latest changes and merge my branch to the master someone changes the code im merging and results in conflicts :(

[@hugodsa89]

What about rebase flow?

[@jonasg3672]

Rebase.

[@ami6packs]

git rebase master is better

[@AndreasKempe]

NEVER work directly on the master. NEVER EVER!

[@AndreasKempe]

@@mktatyt thanks for explanation.