This content originally appeared on DEV Community and was authored by Ivy Chen
I’m a month into the bootcamp at Appworks School and just wrapped up my first week on a class project. I’m learning a lot and liking it so far! Our frontend instructor is really thorough with checking our work and patient with my questions.
Every morning, we start off with a 1-hour recap of what we worked on yesterday and next steps. Usually, there are guided discussion questions based around our approaches to the task the day before and we break into small groups to share. Sometimes, we’re given some things to research on our own in our free time, such as what is/how to rebase in git. Then, we’re off to work on our task for the day.
Last week, our recap sessions have primarily been focused on github workflow for collaboration and CSS approaches to unconventional design (I finally can understand why it’s empathetic to not set random pixel numbers and have wacky UI). I’m really glad that we get to experience what it’s like to “collab” using git and github so early on in the bootcamp and learn about best practices. For this class project, we’re not actually collabing with others but rather mimicking the process of collabing by making a pull request, getting our work reviewed (merging), and pulling the latest updates (including all the other students’ work) into our local repo.
A pull request is a request made to the upstream repo (original repo where you forked from) to see if you could “merge” your work into it. Merging is usually done by the person who owns and maintains the upstream repo and an action that cannot (?) be reversed.
I also learned a bit more about branches. It’s best to use branches that stem from your main and make one every time you want to work on a new feature (or experiment with something). Usually, one branch is used for one PR (?), and after the PR has been merged, you can dispose that branch. There are naming conventions for these branches, usually something like feature/what-you-work-on (eg: feature/w0-p2). From what I understand, a branch contains all the content you have in main and is like a copy, or a “snapshot” to work from. It is a good idea to frequently check which branch you’re on to make sure you’re working in the right one (git branch).
My current workflow look like this:
- switch into main
git checkout main, sync fork (sync your main to the newest updates from upstream), switch into main,git pull origin main(so your local main have the latest update from remote main), create and checkout new branchgit checkout -b <branch-name>, start making progress, git add/git commit,git push origin <branch name>, make a PR (then back to the start).
This workflow also means that I can only start working on another PR after the last one is merged. But apparently there are some workarounds because reviewing PRs can take some time and you don’t want that to be a blocker for moving on to the next task. It is possible to make a new branch from the previous branch, but I don’t really understand how it works after that. Maybe I should look into what rebase it but I feel like it gets more complicated from there. The last thing I want it making irreversible changes.
This content originally appeared on DEV Community and was authored by Ivy Chen
Ivy Chen | Sciencx (2024-07-20T05:46:09+00:00) Appwork School – Week 0. Retrieved from https://www.scien.cx/2024/07/20/appwork-school-week-0/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.