Hello! My name is James Koch, Solutions Architect for Quilmont, an Automation firm based out of Myrtle Beach, South Carolina and Atlanta, Georgia. We have recently started using GitHub to manage our Mobile Application Development for Xcode and Android Studios, Continuous Integration processes using Jenkins, and Automated Testing practices using Appium and the Selenium Grid. I find GitHub to be an excellent tool to share and work on projects with your team or other stakeholders. With a familiarity to SVN I have drawn some comparisons but have explored limitations for both platforms. While SVN is more straight forward, GitHub’s plugin-ability makes it the top tool for team collaboration when it comes to managing a development project. In this tutorial I will demonstrate a few basic steps and rules to implement a GitHub strategy with your team. Through this approach we take test-driven development to the next level!
Eclipse or whichever IDE you wish to use, and a GitHub Account.
Let’s Get Started….
Say you are creating a Maven Project with a Page Object Model structure used to test your application. You are in charge of pages 1-5 while Malcolm-from-the-cubical-down is responsible for pages 6-10, and it’s Debby’s job to run the suite for assurance. With GitHub, no problem!
Begin by creating a new Repository in GitHub:
Name it, and click create (no need to add anything else unless you wish to add something project specific.) Now we are ready to commit your project to the repo you created.
- From Terminal, change the current working directory to your local project.
- Initialize the local directory as a Git repository with the command:
This stages them for the first commit by adding the files in your new local repository:
git add .
- Commit the files that you’ve staged in your local repository and pass it a string value as a comment:
git commit -m “First commit”
- Back in GitHub copy the path to your repo, then in Terminal, add the URL for the remote repository where your local repository will be pushed.
git remote add origin https://github.com/*/*
git remote -v
- Lastly, push the changes in your local repository to GitHub:
git push origin master
When you go back into Github you should be able to see the new commit and your files appear. Now you and Malcolm-from-the-cubical-down can work with this project dynamically and make changes in the same file thus being able to collaborate in the same project. Here’s how…
We are assuming you are holding the master copy of this file and managing it as an eclipse project. The first thing we must do if not already installed is make sure you have the EGit Plugin. If you do not, download it through the Eclipse Market Place.
After Eclipse restarts you are ready to import the project down from Github:
- File-> Import-> Git->Projects From Git-> Next-> Clone URI
- Paste the path to your repo as earlier
- Handle any Authentications
- Select the Branch
- Follow the screen prompts to your configuration and press Finish!
Committing and Pushing Code to GitHub
GitHub gives you the ability to commit code to your local repo as well as Commit and Push to the server. This is very important to know when we are working with our team on code, as this is how we are going to make sure our project stays in-tact when we merge.
- In the file in your already pulled down project, make an update.
- Right click your project-> Team-> Commit
- Add a comment and select “Commit and Push” if you wish to Commit those changes to the GitHub Repo or just “Commit” to your local.
In order to not create conflict with your team, here are a few tips and scenarios to avoid running into issues merging your projects. I will be demonstrating two users working in the same repo; one on Mac, one on PC. In this scenario, you commit your code to the repo for Debby to run the suite of automated tests before communicating with Malcolm the changes you made to the one of the Java files in your project.
5 minutes later Malcolm is ready to commit hit changes but hits a non-fast-forward error because you have already committed your changes:
His first step is to do a local commit of his changes by going through the commit process but just selecting “Commit” not “Commit and Push.” This will commit his changes to his local repository.
Because he was second to commit his work, he must “Pull” your changes into his copy before he “Commits and Pushes” the new code to GitHub.
Now on the Repo both team member’s changes should be ready for Debby to “Pull” down the working project and execute her tests. But let’s see one more possible error in team collaboration. Say Debby “Pulls” the changes into her existing project that she’s been using as a playground or she tries to pull both developers changes but they have a merge conflict. Things have moved and when she goes to pull in any new changes she sees a merge error:
This is JK’s Line
This is MC’s Line
Debby’s next step would be to manually adjust the merged changes and do a Team–> Add to Index
Now that the changes are made she must “Commit and Push” the updated merged changes to GitHub creating the updated master copy of their test suite.
GitHub is a very useful tool when it comes to code sharing and collaborating with teammates. My biggest advice is to communicate with stakeholders a solid workflow so everyone’s changes are easily combined with yours and others. GitHub makes a great one-stop-shop to which your code can be submitted. It eliminates the dangling preposition. Through GitHub’s plugin-ability we are able to work with our code and development practices in ways that were not always available. GitHub provides a professional repo to share your code with customers, and strives on security and ease of use. Again, communication is key when collaborating on projects in this fashion. These are three scenarios one might run into while setting GitHub up for the first time with your team. By following these steps and processes you and your team should be able to nail down the workflow that works best for you. Cheers, and Happy Collaborating!