working with git

I just started learning git using source Tree.

I used mercurial hg workbench before and was quite comfortable with it. I usually created new feature/bug/ticket branch from the main branch to work on something. and if there were any updates to the main branch, I would pull the changes and merge the master branch into my local branch, to resolve any conflicts locally.

I imagine I can do similar in git using sourcetree. I am new to git and still reading about all the terminology around it, fetch, rebase, stash and so forth.

How would one usually achieve this in a team environment while using git.

say I'm working on a feature branch, and there is update to master branch, the one you know which will have lot of conflicts. so my idea is to do a pull on to my master branch. then merge that master branch into my local and resolve the conflicts locally .

how would i achieve this in git. do i do a pull, or fetch?
if i have uncomitted changes, do i stash my changes?
mikhaAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

mccarlIT Business Systems Analyst / Software DeveloperCommented:
Yep, you are on the right track with what you said above.

But just to be clear about some of the terms, I will elaborate here...

fetch - just copies all new objects (commits, etc) from the remote repository to your local copy of the repository. It will also update a special branch in your local repo, called a Remote Tracking branch usually called "remotes/origin/master" with the commit that the main repo master branch is at.
merge (to your master branch) - the next step is to merge the remote tracking master branch to your local copy of "master" branch. If you don't commit any changes directly to your master branch then this should always succeed (with what is called a "fast-forward" merge)
pull - is just a term/shortcut for the combination of the above two operations.

merge/rebase (to your feature branch) - then you have a choice about how to get the new updates on master across to your feature branch, merge or rebase. Merge keeps a track of th 2 commits that came together to be merged, whereas rebase tries to make it look like performed your "feature" commits based off the more recent "master" commit, rather than the one you originally branched from. They both will require you to resolve local conflicts in the normal manner, but just show the history differently. Rebase can have issues if you "share" this feature branch with other people/repositories as the operation modifies history, so you usually only use it for local/private branches, but it does generally look cleaner.

To do this last merge/rebase, yes I believe you either need to commit, stash or revert any local uncommitted changes, before you can proceed.


Hopefully, that helps your understanding of Git somewhat.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Version Control

From novice to tech pro — start learning today.