When you want to add a new feature to your project, you should first develop it in a branch. A branch is a named copy of the deltas that comprise your codebase up to a certain point. By adding commits to this copy, you won't interfere with other people trying to do their own thing. Note that a branch can be created from any other branch, including master.

Eventually, you will want to merge your commits with the original branch. This can be done in two ways: git merge or git rebase. Here is a discussion on which is better. You should probably read it at some point. In this lab we will be focusing on git rebase since it is more interactive and provides many functionalities that you will need when trying to get your changes accepted by the maintainer / reviewer.

The feature that you'll want to add to your project is a command line argument parser that will accept an optional -t, --token [TOKEN]. We suggest that you use argparse. In absence of this token, you will fall back to fetching it from the environment variable.

# first, create a new branch from HEAD
$ git branch feature
 
# next, switch to the feature branch
$ git checkout branch
 
# check that the branch you are is actually feature and not master
$ git branch
  * feature
    master
 
# edit and test your script
# argparse should add a default '--help' option
 
# commit changes and push them to the remote feature branch
# first push means that the branch needs to be created (follow the command's hints)
$ git add ${BOT_SCRIPT}
$ git commit -s
$ git push

At this point, you have created a separate feature branch, added a (hopefully) working CLI argument parser, and pushed the newly created branch to your remote. When working with other people, now would be a good time to create a Pull Request (PR). This is a request to the maintainer of the project to pull your feature branch, check that everything is working, and give feedback if changes need be made. If changes are indeed requested, all you have to do is address them in a new commit which you'll push into your feature branch. The PR will be updated automatically. Once the reviewer gives his ok, your changes will be applied to the master branch.

Since this is your repository and you have to deal with integrating the changes, let's use git rebase to do just that.

# switch back to the master branch
$ git checkout master
 
# apply the extra commits from feature onto master
$ git rebase feature
Successfully rebased and updated refs/heads/master.
 
# remember to push the newly integrated changes to remote
$ git push

“Wait. That's it?” Well… yeah. Luckily, you did not have any conflicts with master. If you did, git rebase would have told you exactly where those conflicts were located. Moreover, it would have modified your files to look something like this:

<<<<<<< HEAD
Changes made to master since branch.
=======
Changes made to feature since branch.
>>>>>>> feature

In order to resolve the conflicts, you would have to remove the lines with "<<<", "===", ">>>" and rewrite the conflicting code so that it incorporates both your changes, and those already pushed to master. Finally, mark the conflicts as resolved by re-adding the files, and continue your rebase.

# re-add files with solved conflicts
$ git add ${CONFLICTING_FILES}
 
# continue the rebase process
$ git rebase --continue
 
# alternatively, you can just give up and go back to how things were (no harm done)
$ git rebase --abort

This part is now optional, but it would be nice to clean up and delete the feature branch both locally and remotely. All changes that feature held are not part of master, so what's it good for?

# delete feature branch on remote (origin)
$ git push -d origin feature
 
# delete feature branch locally
$ git branch -d feature