Friday Sept 27 by Midnight.

This week we are going to practice using git to manage multiple simultaneous changes in a single project, and use git merges. To do this we'll continue to add some features to our 0.1 repos. This lab will help you practice the following:

• creating multiple branches to work on new features and fix bugs
• working on multiple code changes in parallel on separate topic branches
• adding features to existing code
• using git merge to do fast-forward and three-way-recursive merges
• fixing merge conflicts
• how to find and identify commits on GitHub

You are going to make changes to your own 0.1 repo (i.e., you can work on your own code this week). Pick 2 of the following features to add to your project. In your project's GitHub repo, file Issues for each of the two features you want to add, and discuss the changes you will make in the Issue's descriptions. Make sure the Issues are complete and detailed.

Add a --verbose or -v flag that prints detailed progress information to stderr as the tool processes files.

tool-name . --verbose
# Outputs: "Processing directory: src/", "Reading file: main.js", etc.

Add a --line-numbers or -l flag that includes line numbers in the file content output.

### File: src/main.js
```javascript
1: const helper = require('./utils/helper');
2: 
3: function main() {
4:   console.log('Hello World');
5: }

Enhance the file headers to show file sizes alongside filenames.

### File: src/main.js (247 bytes)
```javascript
const helper = require('./utils/helper');

Add file modification timestamps to each file header in the output.

### File: src/main.js (Modified: 2024-01-15 14:30:22)
```javascript
const helper = require('./utils/helper');

Add a --dirs-only or -d flag that shows only the directory structure without file contents.

tool-name . --dirs-only
# Shows structure tree but skips the "File Contents" section

Add a --separator option to customize the separator between files in the output.

tool-name . --separator "==="
# Uses === instead of the default separator between files

Expand the summary section to include more detailed statistics like file types breakdown, largest files, etc.

## Summary
- Total files: 15
- Total lines: 342
- File types: .js (8), .md (3), .json (2), .css (2)
- Largest file: src/main.js (89 lines)

Add a --preview flag that shows only the first N lines of each file instead of full content.

tool-name . --preview 5
# Shows only first 5 lines of each file with "... (truncated)" note

Add a --grep option that only includes files containing a specific pattern.

tool-name . --grep "TODO"
# Only includes files that contain the word "TODO"

Add a --skip-minified flag that automatically detects and skips minified files (very long lines, no whitespace).

tool-name . --skip-minified
# Skips files like bundle.min.js, style.min.css automatically

Add a --exclude-pattern option that accepts regex patterns for more advanced file exclusion.

tool-name . --exclude-pattern "test.*\.js$"
# Excludes files matching the regex pattern

For each of your chosen features, create a new, separate topic branch. For example, if you filed Issue #10 and Issue #11 you need to create 2 new topic branches off of main:

$ git checkout main
$ git checkout -b issue-10
$ git checkout -b issue-11

All work for Issue #10 should happen on the issue-10 branch. All work for Issue #11 should happen on the issue-11 branch. None of your work should happen on main (we'll only merge there). All work should be done on one of the topic branches you just made.

NOTE: you switch between your branches using git checkout issue-10 or git checkout issue-11 (use your branch names). You can only switch branches if your working directory is clean (i.e., you committed any changes).

Throughout the week work on your two features. You are free to discuss strategies and ideas with your classmates, but you must do your own work in the respective branches you created above (no pull requests this time, sorry!).

Your two features will likely involve modifying the same files and/or functions. This is fine and to be expected. Resist the desire to share any code between branches! Keep all work for each feature in its own topic branch, and touch as little code as possible in each branch. The less code you change, the easier it will be to merge everything later.

You can work on the features one after the other, or in parallel, but you may not merge until both are done! With software, it's common and often helpful to do more than one thing at a time: if you get stuck on one, you can switch to the other.

One of git's powers is to allow you to have many different versions of the same code all in existence at the same time. This lets you quickly move back and forth between different projects on the same repository, without having to worry about losing your work.

Remember to git add and git commit as you go, and put all your commits on the correct branch. Every change for Issue #10 goes on the issue-10 branch, etc.

When you have completed both features, and each branch contains the necessary code, it's time to merge.

We merge into a branch, so start by switching to your default branch (i.e., main) and merge the first feature branch (e.g., issue-10):

$ git checkout main
$ git merge issue-10

This merge should go smoothly, and assuming you haven't changed anything on main since you created your topic branches, git will do a fast-forward merge. Confirm that it did, using git log. If it didn't, determine why not.

After you've merged your first branch, it's time to merge the second (e.g., issue-11):

$ git checkout main
$ git merge issue-11

This merge will likely require a three-way recursive merge, since git can't fast-forward your main branch. You may also need to deal with merge conflicts.

Make sure you fix any/all merge conflicts before you complete the merge. If you need help, ask on Teams.

When you're done, the main branch should contain the code for both feature branches, and both features should be working. Make sure your merges didn't break anything!

Test, test, test, and test again. Is the main branch still working? Do you need to fix anything before going to the next step? If so, commit to main to correct the problem(s). Keep track of this, and discuss in your blog below.

Push your fully merged and tested main branch to GitHub:

$ git push origin main

Close your original issues, and provide a link in the comments to the merge commit on GitHub that closes the feature. On GitHub the URL for a commit follows this format:

https://github.com/username/project-name/commit/commit-sha

For example, the 11a9e21d73df8cbd67db7163b42b30e052fbcca0 commit (which we can shorten to 11a9e21) for this repo is at:

https://github.com/Seneca-CDOT/topics-in-open-source-2021/commit/11a9e21d73df8cbd67db7163b42b30e052fbcca0

When you close your issue, add a comment like this:

Closed by https://github.com/Seneca-CDOT/topics-in-open-source-2021/commit/11a9e21d73df8cbd67db7163b42b30e052fbcca0

Write a blog post about the process of working in parallel branches in your project. In your post, include links to everything you discuss (e.g., the project repo, your issues, your merge commits).

Discuss what you did, the changes you made for your features, and the process of doing your merges. What problems did you have? What did you learn? What would you do differently next time?

When you have completed all the requirements above, please add your details to the table below.