In Git, you always commit before you merge. The idea is to never have any modified files in the workspace when you merge. This is one of the main features over SVN: In Subversion, your uncommitted changes would be merged with work by someone else. The result of that is sometimes unpredictable. The most predictable thing is that it's always a lot of work to sort out the mess which svn update
leaves behind.
In Git, a branch is very, very cheap. It's so cheap in fact that you hardly notice when you create one.
So you always commit everything. Then you say "I want to merge with that commit over there" (usually by giving Git the name of the branch which contains the commit).
Something goes wrong? No problem, Git can restore the previous state without fail (unlike Subversion) since the previous state was committed to the repository.
Now there are people who believe that linear history is so valuable that they feel they have to sacrifice this feature. This is usually not true or causes more problems that it solves. It's especially dangerous to do when you're starting with Git. rebase
is a complex and sometimes dangerous operation and not for beginners.
That's why I suggest to start with a simple workflow:
- Commit your work.
- Pull (which will automatically merge)
- If something goes wrong: Undo (see below)
- Run your tests
- When everything looks good, push
Related: