working with git

mikha
mikha used Ask the Experts™
on
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?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
IT Business Systems Analyst / Software Developer
Top Expert 2015
Commented:
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.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial