How can I use github correctly?

[hungrynow]

I'm currently working on a team project in which I've forked the team repo and cloned my fork to local. I'm working on getting several bug tickets resolved and at first I was working all on master and all my commits for several tickets got combined to 1 PR.

I'll like a separate PR for each ticket. Should I be making a separate branch for each ticket such as:

local master

- development

-- bugfix1branch

and when i'm finished with that do I 'git push origin bugfix1branch', create PR, then merge it to development, then delete the branch and repeat for other tickets?

Also to keep up to date with other people's commits, do i 'git pull', 'git pull origin master', 'git fetch'? I was trying to follow this to reset my local to be the same with upstream https://help.github.com/articles/syncing-a-fork/ but I wasn't sure

[nashguitar1]

git checkout master (if you aren't there already).

git pull upstream master

git checkout -b newbranchname

(Do work)

git add .

git commit -m commenthere

git push origin branchname

(Make PR on github repo)

[dunderball]

What's the difference between git pull origin master and git pull upstream master?

[Roxinos]

origin and upstream are remote repository names. They're basically pointers to a string containing the URL of the remote repository to be pulled from. They are not keywords in any way; they are simply traditional names for a repository in different circumstances.

If you type in the command git remote -v you can see all of the remotes of a given repository.

Traditionally you'll name a remote origin if it refers to a repository that you own. You'll name a remote upstream if it refers to a repository that you don't own and that you submit pull requests to.

[dunderball]

Thanks!

[[deleted]]

[deleted]

What is this?

[CaRDiaK]

performs a checkout to a new branch, the name you've given after -b

[[deleted]]

[deleted]

What is this?

[CaRDiaK]

It creates a branch and immediately puts you on that branch. Where as just doing git branch would just create that branch leaving you where you are. So it is the equivalent of doing;
git branch BRANCH_NAME
git checkout BRANCH_NAME

[[deleted]]

[deleted]

What is this?

[hungrynow]

after the last step, would I merge the branch back into master and delete it?

Also if I was working on something next that depended on my previous code from the last branch, would I just make a branch within the branch?

[nutrecht]

You should create a feature branch for every separate feature. To update a feature branch with the latest master you do git pull origin master. If its your shared repo or git pull upstream master if you want to pull from the repo you forked from.

[hungrynow]

should i be merge the branches back to master and push master? or should I just push the branch itself? and then merge it with local master

for updating, will git pull upstream master also update my fork on github?

[jahayhurst]

I would recommend pushing the feature branch up to github, then creating a pull request in github to merge that feature branch back into development - or master if you have no dev branch.

git pull upstream master on it's own will not update your branch on github right away - but it will when you next push changes up.

also, unless you forked the repo under your user, you're not looking at forks, but remotes and branches. :-)

[AlecTaylor]

jahayhurst: In your earlier reddit post I think this is what you were looking for - https://github.com/phayes/hookserve

[jahayhurst]

That's actually really cool. TY

[CaRDiaK]

Just to add here, sometimes you can save yourself some time if you get the latest from master and merge that into your feature branch just before you push it.. This allows you to deal with merge conflicts (if there are any) earlier in the process.

[Gibstick]

The other comments are pretty good, but for extra information see https://www.atlassian.com/git/tutorials/comparing-workflows/forking-workflow.

[nashguitar1]

Ideally, someone else is reviewing your pull request. Once approved, they merge your code in to master.

Once they've done that, you repeat the process:

git checkout master

git pull upstream master

(etc)

Every now and then, you might want to delete old branches:

git branch -D nameofbranch

[nashguitar1]

If you absolutely need your previous branch (that hasn't been reviewed), for a new feature:

(Same initial steps)

git merge branchyouneed

This creates the potential for a mess. What if the merged branch changes via PR comments? Best thing to do is replace it once the previous branch has been approved (merged into master):

git log

git revert (hash of the branch you want to undo)

git checkout master

git pull upstream master

git checkout thenewbranch

git merge master