This is a series of posts about using Git. You can read the previous entries at:

Tracing Our Steps (Part 1)
Tracing Our Steps (Part 2)
Tracing Our Steps (Part 3)
Tracing Our Steps (Part 4)

Embracing Branches

Imagine branches as parallel universes for your code. When you created your repo on Github, it defaults to a branch named main (older git repositories used master as the primary branch). You can create a new branch, make changes there, and your original universe remains unaffected until you decide to merge them. Branching allows us to isolate changes, test them, and only incorporate them when we're satisfied with their performance.

For sysadmins, branches can serve many purposes. You might create a branch to test a new script or update a configuration file, troubleshoot a tricky issue, or even document processes. For example, let's say you're working on automating a server backup process with a script. You already have a functioning script but want to improve it. Problem is, you'll need to rewrite large sections to do what you want. Without branches, you might do something like comment out all of the sections you need to rewrite and script around that section. This leads to a lot of clutter and can be confusing while you're writing.

Keep this scenario in mind as you go through the steps below. A branch allows you to work without risking the currently-functioning script in your main branch.

Branching Out

1. Pull new changes: Again, we're forming good habits! git pull in your terminal.

2. Create a branch: Now, type git branch improve-backup-script to create a new branch named improve-backup-script. This name serves as a clear indicator of the work happening in this branch.

3. Switch to your new branch: To move into this new "parallel universe", you need to "checkout" the branch. Simply type git checkout improve-backup-script, and you're now working in the improve-backup-script branch. Changes you make here will not affect your main branch.

4. Confirm the branch switch: You can always verify the branch you're currently working on by typing git branch. The terminal will highlight or mark with an asterisk the branch you're on.

5. Make changes and commit: Feel free to modify, create or delete files in this branch. When you're ready, stage and commit your changes as you've learned before (`git add file`, git commit file, git push). Remember, these changes are exclusive to your improve-backup-script branch.

6. Switch back to the main branch: When you want to go back to your 'main' branch, type git checkout main. You'll see your 'main' branch remains as you left it, unaffected by the changes made in 'improve-backup-script'.

7. Merge changes: Merging is the process of taking changes from one branch (`improve-backup-script`) and integrating them into another (`main`). If your backup script works as intended and you want to incorporate it into your main configurations, you'll 'merge' the branches. While in the 'main' branch (remember git checkout main), type git merge improve-backup-script and the changes will be integrated.

Playing Nice With Others

So we've got branches to isolate changes which means that each person or team can be working in a branch to avoid butting heads. But what happens when things inevitably get crossed? Once there are multiple people working on a project, we're bound to make changes that step on the toes of someone else's changes. Let's chat about merge conflicts.

Merge conflicts occur when the same part of a file has been changed in two branches and git can't figure out which version to use. This might sound intimidating, but git is actually pretty good at helping us solve these conflicts. Let's see this in action.

Demonstrating a Merge Conflict

1. Setup a new branch: Start by making a new branch off your main branch. Use git checkout -b merge-demo to create and switch to this new branch in one command. This is the equivalent of git branch merge-demo & git checkout merge-demo. This branch will serve as our staging ground for inducing a merge conflict.

2. Modify a file: Open your README file and add a line of text at the top. Something like, "This line added in merge-demo branch."

3. Commit the change: Stage the change with git add README.md, and then commit it using git commit -m "Modified README in merge-demo branch." 

4. Switch back to the main branch: Now, switch back to your main branch with git checkout main.

5. Modify the same file: Open the same README file and add a different line of text at the top. Maybe, "This line added in the main branch."

6. Commit the change: Again, stage the change with git add README.md and commit it using git commit -m "Modified README in main branch." 

Here, you're stepping on your own toes. The same line in the README file has been changed in both branches, so git will need your help to decide which change should prevail.

Resolving a Merge Conflict

1. Attempt the merge: From the main branch, try to merge the changes from merge-demo using git merge merge-demo. Git will tell you there's a conflict.

2. Open the conflict file: Open your README file. You'll see git has marked the area where the conflict occurred, something like this:

    <<<<<<< HEAD
    This line added in the main branch.
    =======
    This line added in merge-demo branch.
    >>>>>>> merge-demo

3. Resolve the conflict: Edit the file to how you want it to look. Maybe you decide you want both lines, or none, or a completely different line. Make your changes and save the file.

4. Commit the resolved conflict: Stage the change with git add README.md, and then commit it using git commit -m "Resolved merge conflict in README." 

And just like that, you've resolved your first merge conflict! Though they can be a bit daunting at first, merge conflicts are simply a part of collaborating and managing changes. With a bit of practice, you'll be able to navigate these conflicts with ease.

Next time, we'll put all these skills together and demonstrate how git staging, commits, branches, and merging would come together to save you time and headache!

Keep learning and keep growing!

Darrell