Branches, merging and conflicts

Why branches

The main branch (older repositories call it master) should always hold working, reviewed code. Each new piece of work happens on its own branch, for example fix/overtime-rounding. You can commit to it as often as you like, test it, and throw it away if the idea does not work. Nothing reaches main until it is merged.

$ git switch -c fix/overtime-rounding     # create the branch and move to it
  (edit, add, commit as usual)
$ git push -u origin fix/overtime-rounding # publish it the first time
$ git switch main
$ git pull
$ git merge fix/overtime-rounding

git switch -c NAME creates a branch and moves to it. Older guides use git checkout -b NAME, which does the same. git branch lists your branches and marks the current one with *. origin is the default name Git gives the remote repository you cloned from.

fetch versus pull

git fetch downloads new commits from the remote but changes none of your files, so you can look before you take them. git pull is a fetch followed by a merge into your current branch.

When a merge conflicts

Git merges automatically when the two branches changed different parts of the files. If both changed the *same* lines, it cannot know which version is right. It stops, marks the file, and leaves the choice to you.

<<<<<<< HEAD
           COMPUTE WS-OT-PAY ROUNDED = WS-HOURS * WS-RATE * 1.5
=======
           COMPUTE WS-OT-PAY = WS-HOURS * WS-RATE * WS-OT-FACTOR
>>>>>>> fix/overtime-factor

1. Open the file. Everything between <<<<<<< and ======= is your current branch; everything between ======= and >>>>>>> is the branch being merged in.
2. Edit it into the version that is actually correct. Here that is probably both changes: ROUNDED and WS-OT-FACTOR.
3. Delete all three marker lines.
4. Stage the file with git add, then finish with git commit.