Suppose I make a small change on a file on branch A and want to migrate this change into branch B. Do I have to first check-in (push in git) this change on branch A before I merge it into branch B ? Next, maybe a stupid question --- what if I don't check-in the change on branch A, can I still merge branch A into branch B, and I assume the change will be on local of branch B, then I check-in (push) to branch B and make the change available to others using branch B ? I don't think it works this way but just confirm.
1) I've been branching and merging for decades, mostly in Clearcase and Perforce
2) Once you get used to branching and merging you'll wonder how you got along without it
3) I've never branched / merged in git.
In my experience yes, you have to check in a file to correctly merge branch A into branch B. Why branch? Because a branch is typically more than 1 file, and your bugfix / new feature / system update / whatever is typically more than 1 file. Why check it in? Because your VCS (Version Control System) doesn't know about your changes until they get checked in.
But the fix only takes 1 file? Even then it's better to branch, call the new branch something like bug1492, feature3278, linux4.16.stable, whatever (yes, I've merged entire Linux kernels into local projects in my career). Get everything working, check it in, then merge your branch to the main branch. Why? It's just cleaner that way. QA wants to know how you fixed that bug? Diff the branch with the trunk you merged from (easy in the tools I've used).
Jim's theory of branch management. You have a main trunk. Every bugfix, every feature request, every 3rd party update generates a new branch off the main trunk. You get it all working. Then, and this is important, you merge the trunk head into your branch. Why? Because bug1324 might interfere with your fix and Jill got her bugfix checked in before you. Test this. Now do it again, remerge trunk onto your branch. Did any files get merged? If yes do it again. When no files change during the merge then you merge your branch back to the trunk.
Now it's time to release version 1.3 of your code and start work on version 1.4 plus bugfixes. Wat do? You branch the trunk with version 1.3 onto a new trunk called 1.4. 1.3 gets nothing but bug fixes, those bug fixes are also merged to trunk 1.4 (and 1.5, and 1.6 as needed). All new work goes onto the 1.4 trunk.
What all this does is make it (relatively) easy to see which bugfixes and feature enhancements went where, and give you a fighting chance when a 2 year old bug shows up in your latest release. It also makes it easier for customers to pay for features. They paid for feature foo? Merge the foo branch onto the trunk. They didn't pay for feature foo? Don't merge.
what if I don't check-in the change on branch A, can I still merge branch A into branch B, and I assume the change will be on local of branch B, then I check-in (push) to branch B
I'd be surprised if git works that way. If you don't check the change in then branch A doesn't know about it, so the change will not show up on branch B. Neither locally nor anywhere else. The change will not be local on branch B, as branch A didn't know anything about it then branch B won't either.
Note you quite possibly will still have a modified copy of Foo.java in your local directory that gets built and tested, but that the VCS has no knowledge of. This is A Very Bad Thing (tm). It's also quite possible the merge will overwrite your local file, losing your changes. This is A Bad Thing For You, but probably Good For The Project As A Whole (tm).
Branching and merging can get to be very interesting, especially when you find yourself in the position of architecting various branches of a large project.
Be careful when following the masses, sometimes the m is silent.
Can you shoot lasers out of your eyes? Don't look at this tiny ad: