Git startups
Branching
Branches are a vital part of git and allow people to work on separate parts of the codebase and not interfere with one another, or risk breaking a product that is visible to the client. Breaking something on one branch does not have an impact on any other.
Good use of git will involve separating distinct features of the project that can be worked on separately and having them in their own branch. These branches can then be merged when they are ready.
Useful commands for branches:
$ git checkout -b [new_branch_name] # Create a new branch and switch to it
$ git branch # List all current branches
$ git checkout [branch_name] # Switch to an existing branch
Note: A successful merge automatically uses the commits from the source branch. This means that the commits have already been made, you just need to push these to the server (git push)
To merge your changes from above:
-
Switch back to the
masterbranch using one of the commands from the above section -
Merge in the changes you made in the other branch
git merge first_new_branch -
Push the successful merge to the server to update the master branch on the server
Merge conflicts
Merge conflicts are the one necessary downside to git. Luckily, they can be avoided most of the time through good use of techniques like branches, regular commits, pushing and pulling. They happen when git cannot work out which particular change to a file you really want.
For this step we will engineer one so you can get a taste of what they are, how they occur and how to fix them. This will be the LAST time you will want one. The process may seem involved but it is quite common when multiple people are working at a time.
Follow these steps:
- Add a line to the top of the
first.txtfile (on master branch) - Add, commit and push your changes
- Switch to your
first_new_branch - Add a different line to the top of the
first.txtfile - Add, commit and push your changes
- Merge master into your current branch
- This sequence of steps should made a merge conflict at the top of the
first.txtwith the following outputAuto-merging first.txtCONFLICT (content): Merge conflict in first.txtAutomatic merge failed; fix conflicts and then commit the result.
Resolving a merge conflict
Resolving a merge conflict is as simple as editing the file normally, choosing what you want to have in the places git wasn't sure.
A merge conflict is physically shown in the file in which it occurs. <<<<<<< marks the beginning of the conflicting changes made on the current (merged into) branch. ======= marks the beginning of the conflicting changes made on the target (merged) branch. >>>>>>> marks the end of the conflict zone.
E.g.
This line could be merged automatically.
There was no change here either
<<<<<<< current:sample.txt
Merges are too hard. This change was on the 'merged into' branch
=======
Merges are easy. This change was made on the 'merged' branch
>>>>>>> target:sample.txt
This is another line that could be merged automatically
We would then just commit the resolved file and the merge conflict is finished!
To fix the conflict you created:
- Open the
first.txtfile and decide which change you want to keep - Remove the merge conflict syntax
- Add, commit and push the resolved merge conflict
Testing
Checkout master and merge first_new_branch back into it. You can now run ./test_git.sh to check whether you have done the git exercises.
Accepting Course Merge Requests
Throughout the course, when course staff need to make updates to your work (e.g. make corrections, clarifications), they will do so by pushing new commits to your repository.
Often, these commits made by course staff will need to be manually merged by you. You can tell if you have a pending merge request if there is a number other than 0 on the sidebar for merge requests.

Once you're on the page of the merge request, you can click the red or green button that says Merge.

If automatic merging can't be done, and you need to resolve a merge conflict, please follow the instructions gitlab provides.