Working with Upstream Remotes & Branches 🍴 🌴 🍴

❓ ❔ Why this approach..........

Well, personally I think this is a process that can really benefit your knowledge of how Git/Github works in a team environment. You have a primary repository, and you have been given a feature to develop. You don't want to mutate the original repository until you are absolutely certain it won't cause ☢️ nuclear damage!😆 Developing on a fork, and then subsequently a branch gives you as the developer layers of security....and then with a Pull Request that gets reviewed by your peers before merging into the main repository, you have multiple layers of security. 🔒

🧠 🤔 So, how do we do this? 🤔 🧠 Follow the steps below 👇 :

• First, you'll need to FORK the main repository onto your own GitHub account.
• Once you have the repo forked, you can either clone your new repo locally, or work on it directly in Gitpod. (If you do not know how to do this, don't stress 😄 post in the channel and we can go through this! 💬 )

Add the upstream remote: (these are terminal commands 😉 🧑‍💻 )

• git remote add upstream https://github.com/original-owner/repo-name.git
• Check to ensure the remote added correctly by running git remote -v

And your output should look like this:

$ git remote -v
> origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (fetch)
> origin    https://github.com/YOUR_USERNAME/YOUR_FORK.git (push)
> upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (fetch)
> upstream  https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (push)

We do this part so that we can have a relationship between your fork, and the main repository so we can do Pull Requests (<---- more on this later).

Work on a BRANCH 🌳 :

• Make sure to checkout into an appropriate branch. Never develop onto the master / main branch. This piece here not only give you vital exposure to more GIT , but also gives an extra layer of security when working in a team.

You might notice above we have mentioned " master / main ", this is because Github recently changed their naming convention for the primary branch and depending on how you define it, it could be called either 😃.

• git branch -a (view existing branches)
• git checkout -b new_branch_name (create new branch and move to it) <--- this will create the branch and automatically move you into the new branch!
• git checkout branch_name (go to an existing branch) <--- do this step if you already have the branch made, notice how the only difference here is the omission of the -b flag 😃.
• While on your branch of choice, DEVELOP! Create the feature, code & experiment! 👨‍💻 👩‍💻 🧪 🧪
• Commit and add your changes to the branch in your fork.
• When ready, go to https://github.com/original-user/repo-name and click on the "Pull Requests" Tab to open a PR, and then you will have an option to select your fork and branch! 😄 (there is a little more to this......but I'll get to this in the next post 😉 )

Side note: 📓 If you want to go from one branch to another, you should never directly bounce 🏀 from one branch to another. Couple of reasons for this, but firstly, before even considering it, commit your changes to the current branch before moving elsewhere, or you risk losing those changes! Instead, you should get into the habit of traversing back to the main / master branch first, and then going to the branch you want. So in relative order:

• git add . <--- add all modified files to the staging area
• git commit -m "meaningful message here" <--- commit them!
• At this stage, you can push them to the branch using git push or you can navigate to the main/master branch using git checkout main <-- change "main" to "master" to suit your forked repository setup.
• Then git checkout branch-name to traverse from the main/master branch to the new branch!

Simple right!? 😅 Don't worry, after a few times doing this, it becomes second nature.

---

- 🌴 - 🍴