First time using GitHub to collaborate with your team in software projects? This is one of many ways to collaborate on a project using GitHub. But it’s one I would suggest if you’re just starting out working with a team and haven’t established a git flow yet or know where to start in establishing one.
In this final article explores collaboration of software teams projects in GitHub, especially for working in teams, making it all the more efficient, productive and, most importantly, fun! Here’s how you collaborate on GitHub.
Step 1: Initialize a new project
Create a new project/directory from the command line:
‘$ rails new github_guide’
Go to GitHub and click the ‘+’ button in the top right corner and select ‘New Repository’. Then fill out the Repository name and the Description fields. Keep it public, and do not “Initialize this repository with a README”. Don’t change anything else. Click “Create repository”.
Next you’ll see the setup page. These are instructions for connecting Repo you just created in GitHub (Remote) to the directory you created in your terminal (Local).
Paste the lines in the red box line by line starting with “echo…” into the terminal while you’re cd’ed into the directory you just created locally. Your terminal should look like this when you’re done:
This adds a ‘.git’ folder to your repo, connects you to your remote GitHub Repo and also gives you a ‘.gitignore’ file.
And of you go to your GitHub Repo page, you’ll see the ReadMe that you initialized with and the reference to the first commit you made.
Now let’s get this Repo up to date. Go back to your terminal and git add, git commit, and git push:
Now check out your repo. It should have all the files you created your local directory with along with a new commit id (9c2e2f6):
You’re initialized and ready to start working!
Step 2: Setup Your Team
You’re a team player, so you’re going to need to add your team to your repo so they can collaborate. Once your team is added as collaborators they’ll be able to push, merge, and a ton of other destructive things so make sure you’re only adding your teammates.
Click on the “Settings” tab of your rep, then “Collaborators” then search for GitHub users and add them by clicking “Add Collaborator”:
They’ll receive an email letting them know you added them and will be listed as a collaborator.
And now you’re ready to collaborate!
Step 3: Collaborating
When you’re using git to work on the same project with multiple people, there’s one central rule you must follow:
The master branch should always be deployable. The way to keep Master deployable is to create new branches for new features and merge them into Master when they’re completed. Here’s how that works.
To start, branches should always represent features. For example, if you want to add the ability for a user to login you should probably create a branch called “user_authentication” and in that branch you should only update what you need to enable a user to login.
So let’s say you want to create the User model. In your terminal create a new branch:
“co” is short for “checkout” which is used to switch between branches. Adding the “-b” and a name at the end creates a new branch and then moves into that new branch for us. You should be able to verify this with the command:
Which should produce:
You’re now in your new branch and can start coding away.
Determining your Git Flow is a huge part of working in a team, but here’s one Git Flow you could adopt for now:
First, determine who’s going to be in charge of handling merging. The less people acting independently on merging the better so for a team of 4 it would probably behoove you to have one official “Reviewer” or “Merge Master”.
Next, have everyone git push their branches:
Now go to the GitHub Repo page. You should see the branch you pushed up in a yellow bar at the top of the page with a button to “Compare & pull request”.
Click “Compare & pull request”. This will take you to the “Open a pull request” page. From here, you should write a brief description of what you actually changed. And you should click the “Reviewers” tab and select whoever your team decided would be the “Merge Master”. When you’re done, click “Create pull request”.
Go ahead and click the “Add your review” button
This will take you to the Pull Request page. How you move forward from here is up to you and your team. If you’re working remotely, this will be your main tool for letting the requester know if they need to make changes or if you’re going to merge their request.
When you click “Submit review” on the “Review changes” drop-down your review will now exist as a comment on the pull request thread.
When you’re satisfied with the pull request, go to the bottom of the pull request and click “Merge pull request”.
You’ll then see a “Pull request successfully merged and closed” message and a button to “Delete branch” which you should click.
Step 4: Rinse, Repeat
And that’s pretty much it. Keep doing the rinse and repeat by adding new branches for new features and then coming together as a team to merge them into master. Keep the master clean and deployable and don’t try to merge more than one branch at a time and you should be good to go.
Summary
Feel free to make a pull request if there’s anything you want to change or if you just want to test out your pull request skills using this repo.
I’d love to hear from you about how GitHub has benefitted you as a team. If you’re just getting started with GitHub, check out our previous posts of our series – Getting Started with GitHub – Hello World, Free vs Paid Accounts and Tips and Tricks, and learn more about GitHub.
