6. Git#
Embracing Diversity in Our Collaboration Sphere
The silhouette of our logo captures the spirit of our team at Hopkins and beyond. The hub-and-spoke model encapsulates how every branch, every individual, converges towards a unified purpose. This design resonates with the essence of our work — where collaboration and individual brilliance merge to further the frontiers of research.
No Hierarchy, Just Convergence
True to the hub-and-spoke model, our ethos is rooted in equality. Whether one’s at the periphery or closer to the hub, every voice is pivotal. Seasoned academicians, budding researchers, and every spoke in between, drive us forward.
Git: Our Collaboration Hub
Our “hub,” in many respects, is Git. Just as every spoke feeds into the central hub, Git’s version control prowess ensures that every contribution weaves seamlessly into our collective tapestry, without overriding or lost fragments.
Branching Out and Converging
Every spoke on our logo signifies freedom — the freedom to branch out and innovate (see video below for step-by-step guide). With Git, these branches allow us to experiment without disturbing the core. Yet, they always have a path back to the hub, ensuring harmonious integration.
Circles of Safety
Mistakes, like branches, are inevitable. Yet, with Git’s meticulous versioning, they’re never a dead-end. We can always trace back to a version that resonated well, safeguarding the sanctity of our work.
Inviting Every Spoke
From students to experts, every “spoke” or contributor brings a unique perspective. As our logo suggests, diversity isn’t just welcomed; it’s integral. This richness in perspectives propels our research towards unparalleled breakthroughs.
Envisioning Tomorrow
To raise clinical research standards, we’re integrating the hub-and-spoke philosophy with tools like Git. This synergy promises work that’s not only of supreme quality but also of profound impact.
In Conclusion
Our logo isn’t just a design; it’s a testament to our beliefs and our approach to research. By marrying the hub-and-spoke model with Git, we’re ready to chart new territories in clinical research. Forward, together. 🌍📚🔬🚀
Quiz: 1
Folking, Cloning, or Merging?
What are we dealing with in the Git workflow below?
Forking
Cloning
Editing
Pulling (Main) & Pushing (Fork)
Merging
Here’s a step-by-step guide on what is going on:
Step 1: Committing Your Changes Locally
If you haven’t already, make sure all your local changes are committed.
git add .
git commit -m "Overhauled backend structure"
Step 2: Push the Changes to Your Fork
Push these commits to your fork (username/repo) on GitHub.
git push origin main
Step 3: Delete Old Folders and Files from username/repo
If you’ve completely overhauled the backend and renamed directories/files, and you’ve committed these changes, then the old folders and files should already be removed from the repository once you’ve pushed the changes.
However, if you want to make sure, you can manually delete specific files and directories.
git rm -r old_folder/
git commit -m "Remove old_folder"
git push origin main
Step 4: Syncing Your Fork with the Original (username/home)
Before merging changes, it’s a good practice to sync your fork (username/repo) with the original repository (username/home).
First, add the original repository as a remote:
git remote add upstream https://github.com/username/home.git
Fetch the changes:
git fetch upstream
Merge them into your local repository:
git merge upstream/main
Finally, push these changes to your fork:
git push origin main
Step 5: Creating a Pull Request
Now that your fork is updated and includes your new structural changes, go to GitHub and create a pull request from username/repo to username/home.
Navigate to your fork (
username/repo) on GitHub.Click on “Pull Requests.”
Click on “New Pull Request.”
In the “base repository,” choose
username/home, and in “compare,” choose your repository (username/repo).
Review the changes and submit the pull request. This will notify the maintainers of username/home to review your changes.
Once approved, the changes can be merged into the username/home repository.
Final Note
Remember to communicate with the maintainers of the original repository and ensure you have the correct permissions to make these changes. It’s always good to document your changes well to make it easier for maintainers to understand what you’ve done, why you’ve done it, and how it benefits the project.
Quiz: 2
Pushing or Pulling?
What are we dealing with in the Git workflow below?
Forking
Cloning
Editing
Pulling (Main) & Pushing (Fork)
Merging
Reviewing a pull request involves examining the changes made in the request and providing feedback, approval, or requests for changes. Here’s how you can review a pull request on GitHub:
Step 1: Navigate to the Pull Request
Go to the repository where the pull request has been submitted.
Click on the “Pull requests” tab.
Click on the pull request you want to review.
Step 2: Examine the Changes
You will see an “Files changed” tab, which will display all the changes made in the pull request.
You can view changes side by side or inline, and toggle between “Showing changes” and “Hide whitespace changes” to make it easier to see what’s been modified.
You can also use the “Review changes” drop-down to jump to specific changes.
Step 3: Leave Comments (Optional)
If you find areas that require attention or clarification, hover over the line of code and click the blue plus icon that appears.
This will allow you to leave a comment. Type your comment and either save it for later or start a review.
Step 4: Start Your Review
Click the “Review changes” button in the top right of the “Files changed” tab.
Choose one of the following options:
Comment: To leave general comments without approving or requesting additional changes.
Approve: To accept the changes as they are.
Request changes: To ask for modifications before the pull request can be merged.
Add additional comments in the text box.
Click “Submit review”.
Step 5: Follow Up
If you’ve requested changes, keep an eye on the pull request to see if the author pushes the requested changes.
If you’ve approved the pull request, it’s up to the repository maintainers to merge it. You may also be able to merge it yourself, depending on your permissions.
Additional Points to Consider
Check for code quality, functionality, and whether the changes align with the project’s goals.
Make sure that all tests pass if the project has automated testing integrated.
That’s a high-level overview. The exact steps may differ slightly based on your specific permissions and the repository settings.