This page describes a very simple git workflow that can be used with most projects.

Clone the repository
git clone [email protected]:some-user/some-repo.git

Create a branch
git checkout -b branch_name
-Name your branch something descriptive: test-sampler, add-ga-comments

Update from the remote master
(Do this often if you're working on a branch for a while)
git fetch
git rebase origin/master

Committing your changes
git add filenames.c
git commit

In case you forgot to add something to your commit
git add filenames.c
git commit –amend

Submit a pull request on github
git push origin branch name
- Go to the github repository, click on 'branches', and click on “new pull request”
- Have someone review your code. If new changes need to be made, make them.
- Click on 'squash and merge'

Switch back to the master branch and update
git checkout master
git fetch
git rebase origin/master

git clone - Clone a repository into a new directory. Details
git fetch - Download objects and refs from another repository. details
git rebase - Reapply commits on top of another base tip. Details
git add - Add file contents to the index Details
git commit - Record changes to the repository. Details
git push - Update remote refs along with associated objects. Details

[0] Read the git output - it's normally pretty useful and will tell you what to do. If you get stuck in a state where you have no idea what is happening, try to think about what you did last and how that affects the git data model. If all fails, ask a teammate.

[1] We use rebasing to keep the history linear and clean. By doing this, we can make sure that every commit is well documented; this also has the added advantage of making code reviews easier as well.

[2] Branching, especially if you're only working on a one or two person team, is not really necessary. As long as you manually communicate with everyone then it's fine. However, on bigger teams you often will need branches to keep things organized and to do proper code reviews.

[3] Pull requests, a github specific term, give us a mechanism that allows us to easily review code. Other systems (such as Gerrit Code review) also impose different workflows on top of git.

Git Basics provides a fantastic technical explanation of how git works in the back.

Contributing authors:

Created by kluong on 2016/09/16 19:17.