- Create a Github account
- Set up Git
- Generating ssh keys
- Branch
- A version, or draft, of the code. `master` is the default branch.
- Pull
- Download code from another repository or from a branch
- Push
- Send your newly written code to another remote repository
- Remote
- A link to a git repository on another server. By default, “origin” is the remote created when you run `git clone`. “upstream” is the term used for the source, or original, repository’s remote.
- Repository
- Your code base. Can be thought of as the directory with all your code in it.
- Version control
- Application that stores code, allows multiple coders to work on the same code base and tracks the history of code changes.
See history of code changes
git log
See the current status of files. Tracked or staged files are ready to be committed. Untracked files will not be committed.
git status
Stage files, or tell git that you want this file to be included into the next commit
git add <FILE NAME>
Commit currently staged files
git commit
Note: by default, git will use vim as the text editor for commit messages Helpful vim commands:
- i - go into “edit mode” where you can type normally
- esc - exit edit mode
- :w - “write” or save the changes
- :q - quit the editor
- :q! - quit without saving
Push your changes to a remote repository
git push
#if it’s the first time you are pushing a branch
git push -u origin head
Pull changes from a remote repository
git pull <REMOTE NAME> <BRANCH NAME>
git pull origin master #pulls from my fork
git pull upstream master #pulls from source repo
#Use “rebase” instead of the default merge
git pull --rebase upstream master
Create a new branch
#short cut
git checkout -b <BRANCH NAME>
#long way
git branch <BRANCH NAME>
git checkout <BRANCH NAME>
Checkout or switch to a different branch
git checkout <BRANCH NAME>
#e.g.
git checkout master
Rebase puts your changes (from the repository you are in when you run the command) on top of changes that are pulled, regardless of when the changes were made.
Merge, on the other hand, tries to combine the commits in chronological order.
git pull —rebase <REMOTE NAME> <BRANCH NAME>
git pull —rebase upstream master
See the files with conflicts
git status
Fix the code in those files
You will see things like <<<<HEAD which indicate the sections that conflict between the two repositories
Once you’ve fixed the code
git add <FILE NAME>
git rebase --continue
DO NOT commit changes
This will rollback all code changes
git rebase --abort
[
]
You should be redirected to the fork on your Github account.
[
]
[
]
git clone [email protected]:rmw/django.git
You should see something like this
[
]
Go into the directory with the code and check the remotes created by git clone.
cd django
git remote -v
You should see something like this
[
]
This is the reference to the source, or original, repository.
git remote add upstream [email protected]:django/django.git
You should see something like this
[
]
- Follow set up instructions
- Install dependencies
- Run the code
- Run the tests
This may very well be the opportunity for your first pull request!
First, add a note on the issue/ticket saying that you are going to work on it so the maintainer and others know.
Create issue/ticket if one doesn’t exist.
git checkout -b <FEATURE NAME>
Follow any branch naming conventions outlined in the contributing docs
Write tests. Follow code style guides and code conventions you see in the code base.
Fix and commit one thing at a time. Write a clear, descriptive commit message.
git push -u origin head
Write a clear description in the pull request. Link to the issue/ticket in the pull request.
If don’t finish or not the maintainer is not using Github issues, post an update to the issue/ticket.
- How to get help
- How to search the internet
- How to write good code
- How to debug
- How to write a bug report
- Good commit messages
- Before you create a pull request
- How to do a code review
- Ask your peers
- Ask a mentor
- Ask the internet
- What version? How recent?
- Google
- Look at most recent results first
- StackOverflow
- Look at many answers
Pro tip: document your errors and solutions
- Follow coding standards that you see (naming, indentation, etc)
- Look at code style guide if its linked
- Self-documenting code - don’t be clever, be clear
- Get feedback
- Fix and commit ONE thing at a time
- Read the error message (if there is one)
- Isolate the error — find the exact line — using a debugger or print statements
- What is the input? What is the output? Is it what you expect it to be?
- Google the error message
- Delete things until the code works again.
- the exact error you are getting, including the error message
- detailed repeatable steps for the error
- what did you click on? did you click, tab, press enter, or hit another key?
- what page did you start on? what page did you end up on?
- details of where & what you are working on, including the version
- browser, operating system, device, language
- screenshots of the error
- Short summary for first line (50 chars)
- Word wrap (72-80 chars)
- One commit per change
- Answer:
- Why is this change necessary?
- How does it address the issue?
- What side effects does it have?
- Include link to issue/ticket and external sources
- Run ALL tests
- Get a Code Review
- Pull from upstream
- Read the issue/ticket
- Review contributing guidelines & code style guides
- Be thorough & give yourself time
- Focus on the code not the author
- Ask questions
- Run the Code
- Sign off & hi-five!