GitHub Workflow

[00:00:00]
>> Nina Zakharenko: Here we have the most common workflow. Triangular workflow. Common when you are contributing to open source projects. You fetch from upstream to keep your local repo up to date. You push changes to your fork, aka the origin, and then you put post changes to the upstream repository via pull request.

[00:00:25]
>> Nina Zakharenko: Does anyone have any questions about the triangular workflow. Does this makes sense? This is crucial to understanding how the usual GitHub workflow works.
>> Nina Zakharenko: What's a tracking branch? Sometimes you'll see this word when you're using Git. To track a branch, you wanna tie it to an upstream branch.

[00:00:50]
As a bonus, you can push and pull with no arguments. If you wanna check out a remote branch with tracking you can use git checkout -t. You specify which remote you want to track from, and which branch you're looking to check out. If you're pushing a branch to remote for the first time, you can git push -u.

[00:01:13]
And that's going to set up tracking and push that branch back up to the remote.
>> Nina Zakharenko: By default, Git doesn't really show you any interesting information about what upstream branches we're tracking. So a command that I find very, very useful is git branch -vv. When you run it, it will show you which upstream or remote branch you're tracking on your local branch.

[00:01:44]
Very useful information. Another thing is, it will show you how many commits you are ahead, or behind. In this case I made a fork a long time ago, I never fetched from upstream, and so my fork is 124 commits behind master, very sad.
>> Nina Zakharenko: If I want to get information from the server, without merging or pulling, I can use git fetch.

[00:02:15]
It's important for keeping your local repository up to date with a remote, and it pulls down all the changes that happen on the server. But it's not going to change your local repository, so don't worry. If I pull, it's gonna do fetch and then a merge. So git pull under the hood is just doing a fetch first and then a merge.

[00:02:39]
It's gonna pull down all those changes from the remote repository to your local repository, merge them with the local branch. If any changes happen upstream, Git will create a merge commit. Otherwise, it's just going to fast forward. When I push, I'm sending my changes up to the remote repository.

[00:02:56]
Git will only let me push if it's not going to cause a conflict. So, if any changes happen to the remote repository, I will have to pull first, update my local copy and then I'll be able to push. Git pull --rebase is very helpful. It's a git pull with a rebase built in.

[00:03:18]
It's gonna fetch, update your local branch to copy the upstream branch that you specified. And it's gonna replay any commits that you made by a rebase. When you open a pull request using the strategy, there aren't gonna be any unsightly merge commits.
>> Nina Zakharenko: So a quick example, a Git Pull versus a Git Pull Rebase.

[00:03:38]
If we have this sort of setup here, we made a feature branch. And we branched off from one commit behind where master is at now. If we just git pull, origin master, we're gonna have a merged commit, that extra purple merge commit. If we wanna keep our history cleaner, we can do git pull origin/master --rebase.

[00:04:06]
And now that new commit on master, is sandwiched between the changes we had on master and our feature branch.
>> Nina Zakharenko: Don't use git pull --rebase on a branch that has local merge commits, it doesn't work very well. It works best in this kind of setup where you are just kind of branching off master or working on a feature.

[00:04:34]
I use this all the time and just apply my commits neatly on top. Quick note about tags. Git doesn't automatically push local tags to a remote repository. You have to manually merge them. Either by saying git push with a tagname or git push --tags. Some guidelines on contributing to open source projects with pull request.

[00:04:56]
Before opening a pull request, keep your commit history clean and neat. You should rebase if you need to. Run any tests that the project might have. Pull in upstream changes. In this case, preferably via rebase to avoid any merge commits. Check for a file called contributing.md or .txt in the project route.

[00:05:16]
That's going to be the guidelines for how to contribute to this project. After you open a pull request, explain your changes very thoroughly in the pull request body. You should link to any open issues, any bugs that you might be fixing. And check back frequently for comments from the maintainers.

[00:05:35]
>> Nina Zakharenko: Advice, I always encourage developers to work on their own forks of a repository. Even if you have push access to, let's say you have a work project and you have push access to it. Instead of pushing directly to it, just make a fork if you can. You're a lot less likely to make mistakes if you're not pushing changes to the source of truth.

[00:05:59]
You can always rebase and force push freely to your own origin, your own fork, as long as no one else is cloning your branch.
>> Nina Zakharenko: Now, rule of thumb when you're proposing or pushing, merging changes back to remote, try to rebase your commits. Merge those feature branches back to the origin.

[00:06:21]
So, your local history has been rebased, but there's a clear merge commit in master. These were the features that I was working on. When a pull request is accepted, the owner of the repository has a few options. You can squash, you can merge, rebase. And if you squash or rebase, you'll lose the context.

[00:06:48]
It's harder to debug. I much prefer to merge when accepting a pull request.