Collaborative Development with Git

 Collaborative Development with Git

GitHub

Right now, GitHub is the most popular repository site for collaborative development.  

Let's go through the steps of setting up and using a repository on GitHub.  Keep in mind that while the Git process is often used for collaborative development, you can also create private repositories to help organize projects you are working on alone.  In fact, PyCharm and other IDEs can create a Git repository right on your computer.

We will be using GitHub in this class to submit assignments.  Our process will not include all of the steps below, since we are not working collaboratively.  We will not make branches, so we don't need to worry about things like "Check-out" and "Merge."

"Repos"

The first step to working collaboratively with Git is to create a repository or "repo", or to work on a repo that has already been created. In GitHub, a repo includes space to store and manage your source code files. GitHub provides an issue tracker, to-do list, wiki for documentation, and other tools to help develop your code.  Creating a repo also creates a main branch of your project.  The main branch should generally contain a stable, working copy of your project.

Cloning

If you are joining a repo that has already been created, then you will clone the repo onto your computer.  Cloning copies the entire state of the repo...the current filesystem, all branches, and the history of changes.  That sounds like a lot of data, but because of the way that change tracking works, it's usually not that bad and it gives you the ability to work on any branch or revert to any point in the history of the project.

Branches

When you want to edit code, the next step is usually to create a branch.  You can work right on the main branch, but creating another branch can allow you to play with changes that may break your code while leaving a stable copy available to use.  

Check-out

If you want to work on a branch that has already been created by you or somebody else, you "check-out" the branch.  Remember that in the cloning process your downloaded information about every branch, so checking-out doesn't actually download anything, it just sets your environment and filesystem up to work on a particular branch.

Commit

After you make some changes, you can commit those changes.  This is basically saving the changes you made to your branch.  When you commit, you will be given an opportunity to create a commit message that you can use to record a summary of the changes that you made since the last commit, and perhaps why you made them.  The actual changes you made are recorded automatically.  It's a quick process to write a commit message, and it's good to get into this practice.  

You can commit changes as often as you like, they are only saved to your local repository (usually on your computer).  It's a good idea to commit often so that you don't lose any work, and you can easily roll back anything that you don't like.  

The commit process may trigger some automated testing to verify that your code functions well and is formatted correctly.  

Pull Before you Push

If you and others are working collaboratively on a branch, it is important to try to minimize code conflicts when you merge.  For this reason developers are often advised to "pull before they push."  This means that after you make changes on your local computer, go back to the remote repository to make sure you are dealing with the latest version of your branch.  If there have been updates since you checked out the branch, fetch and merge those updates with your own code to make sure the changes you have made are compatible with the current state of the branch.  Once you are confident that everything will work well together, go ahead and push to the branch.

Push

After you have made some progress, you can push your commits to GitHub (or whatever server you are using).  All of your commits, including your commit messages, will be uploaded from your computer to your branch on GitHub,  This keeps the branch up-to-date.

Pull Request

When you are ready to combine your changes into the main branch, you create a "pull request."  This vocabulary always seems backwards to me, but you are asking for your new code that was committed and pushed to be "pulled in" to the main branch, creating a new version of the main branch.  Usually this is done when you have made some stable improvements to the code.  If you are working on a large  project, there will be one more core developers who are responsible for verifying that your branch is a stable improvement to the main branch.  If you are working alone, you can approve your own pull requests

Merge

The final step in the process, after the pull request is accepted, is to "merge" your branch back into the main branch.  Merging means that your changes become a permanent part of the main branch of the project.  Congratulations!