So far, we've been using git to save versions of our work, which is one of git's main purposes. The other main purpose has been ignored until now, and that is team collaboration. There are a few different ways to collaborate with a group of people using git/Github.
We'll be focusing our time on the Forking Workflow. We've actually been using this workflow all along to a lesser degree, when submitting assignments.
A forking workflow looks something like this. The idea is that...
- One person acts as the git manager and creates the main repo. They also manage the code that's merged into the repo.
- Everyone else forks the main repo so that they have a copy of it.
- In the forks, work may be done in branches known as feature branches until the feature is finished, or you can edit directly in your forked repo. It it recommended that the git manager always work in feature branches before merging into the main branch.
- For the folks working on forks, once a feature is finished, you'll want to do what's called an upstream pull. This will allow any changes from the main repo to be reflected in your fork. Assuming everyone works in separate branches, this should not create any merge conflicts.
- Once the upstream pull is finished, you can push your changes to the Github fork, and then create a pull request. This will allow the git manager to merge the changes. Make sure to notify them so they can merge your changes right away.
- Finally, once a pull request has been merged, all non-git-managers shoud immediately pull from the upstream so the latest changes are in the fork*. Again, this shouldn't cause any issues if no one deletes or re-arranges files, and if no one works on the same file at the same time.
Let's practice this.
- Choose one person to be the git manager
- This person should create a new repository. Let's call it
forking-test - Once the repository is created, clone it to your computer
- This person should create a new repository. Let's call it
- Once the repo is created by the git manager, the other group members should get a link to the new repo and fork it.
- Each group member should clone their forked repo to your computer
Try running git remote -v. This will be a list of remote repositories. By default, origin is the remote of your fork on Github. We're going to add another remote to reference the main repo, so if there are any changes, they can be pulled from the main repo into the fork.
- All group members except the git manager should follow these steps
- Go back to the main repo (not the fork) and copy the HTTP link
cdinto your cloned fork- Add the remote by running in the terminal (pasting the HTTP link in lieu of the one provided):
git remote add upstream [email protected]:gitmanagerusername/forking-test.git
- Testing the upstreams
- Git Manager: create a change in the main repo on the
mainbranch. Add the change, commit it, and push it to Github. - Once the git manager has pushed changes, group members should try running
git pull upstream main
- Git Manager: create a change in the main repo on the
If successful, group members should receive the change in their forks.
Work in your project groups.
- Git Manager:
- Create a new react app.
npx creat-react-app fiking-flow-test - Edit the App component so it shows your team name.
- Create a new github repo for the project.
- Add, commit, and push to this new repo.
- Create a new react app.
- Non-manager members:
- Fork and clone the main repo.
- Set the upstream to be your Manager's main repo.
git remote add upstream <manager's repo http> - Add a component to the /src folder titled with your name. The component should render your name and a photo of you (or a placeholder photo).
- When you've finished writing your component, commit your changes, push to your fork, and make a pull request.
- Git Manager:
- Review and merge each pull request.
- Pull down the newly merged code to your local repo
git pull origin main. - Add a component to the /src folder titled with your name. The component should render your name and a photo of you (or a placeholder photo).
- Edit App.js to render all the new components underneath your team name. Commit and push to the main remote repo.
- When you're finished merging and editting, notify you're teammates!
- Non-manager members: When your Manager tells you it's ready, pull from the upstream to get the new changes!
If done correctly, eveyone's local repo will now be the same!
A detailed explaination of this workflow can be found here
- Everyone:
- Create a feature branch to work on new code in.
git checkout -b <your name> - Add a short bio into your component (the one with your name).
- Add, comment, and push these changes to your branch
git push origin <your name>
- Create a feature branch to work on new code in.
- Non-manager members:
- Create a pull request from the branch to the main repo and notify the git manager.
- Git Manager
- After merging changes send out a notification to everyone on the team to pull down the new changes.
- Pull down the new changes to your own local.
git pull origin main
- Non-manager members:
- Switch back into the main brain
git checkout main - When the managers tells you to, pull down the changes from the main repo to your local main branch
git pull upstream main - Update your fork on github (push the changes that you just pulled down up to your fork)
git push origin main - Clean up! aka delete your feature branch (both locally and remotely)
git push --delete origin <branch name>
- Switch back into the main brain
The forking repo is one of the widely used git workflows available. It's used to contribute to open source projects, as well as internally by some companies.
You may come across problems when working with git, such as merge conflicts and changes not appearing where you think they should be. Keep in mind that while you have the tools available to solve these problems, the biggest challenge is to figure out how!
Indeed, it may take a whole lifetime to become a git pro, but the only true way to wrangle git flows into your bones is to use it. Here are some resources if you need help, or would like to learn about advanced tools beyond branching and rebasing.