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

Follow these instructions to create a branch:

1. Make your new branch with: git checkout -b first_new_branch

2. List your branches to see that you have indeed swapped (use the above commands)

3. Make another change to the first.txt file

4. Try to push your changes to the server using the commands you learnt in the Make your first commit section

5. The above step should have given you the following error:

   fatal: The current branch first_new_branch has no upstream branch. This means that the branch you tried to make a change on doesn't exist on the server yet which makes sense because we only created it on our local machine.

6. To fix this, we need to add a copy of our branch on the server and link them up so git knows that this new branch maps to a corresponding branch on the server. This command will do that:

   git push -u origin first_new_branch

Note: The final step only needs to be done for the first time you try to push using a new branch. After you have run this once, you should go back to simply using git push

Merging

Merging branches is used to combine the work done on two different branches and is where git's magic really comes in. Git will compare the changes done on both branches and decide (based on what changes were done to what sections of the file and when) what to keep. Merges are most often done when a feature branch is complete and ready to be integrated with the master branch.

Since we have finished all that we are going to do (and believe there are no bugs) on our first_new_branch we can merge it back into master.

NOTE: It is strongly recommended, both in this course and in general, to always ensure the code on the master branch works correctly and is free of bugs. This is not always easy to achieve, but you should endeavour to keep master as stable as possible.

Another recommendation is to merge master into your branch before merging your branch into master as this will ensure that any merge into master will go smoothly.

In general, merges are done by:

git merge [target] # Merge the target branch into the current 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:

1. Switch back to the master branch using one of the commands from the above section

2. Merge in the changes you made in the other branch

   git merge first_new_branch

3. 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:

1. Add a line to the top of the first.txt file (on master branch)
2. Add, commit and push your changes
3. Switch to your first_new_branch
4. Add a different line to the top of the first.txt file
5. Add, commit and push your changes
6. Merge master into your current branch
7. This sequence of steps should made a merge conflict at the top of the first.txt with the following output Auto-merging first.txt CONFLICT (content): Merge conflict in first.txt Automatic 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

This above example could be solved in many ways, one way would be to just use the changes made on the target branch and delete those made on the current branch. Once we have decided on this we just need to remove the syntax. The resolved file would be as follows

This line could be merged automatically.
There was no change here either
Merges are easy. This change was made on the 'merged' branch
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:

1. Open the first.txt file and decide which change you want to keep
2. Remove the merge conflict syntax
3. 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.