In this assignment, you'll have the chance to practice what you've just learned by using Git to step through a typical workflow. You'll set up a simple repository, push it up to Github, make changes, work with branches, and handle a merge conflict. All-in-all, a good day's work.
Refer to the previous lesson for the commands that you'll need to use. Try to think through conceptually what you're doing before just copy-pasting commands.
When you're creating a brand new project, you'll typically go through the same steps. Get some practice by following these instructions. Can you remember the commands that correspond to them?
testand go into it.
That's enough warmup.
README.txtin your text editor (from the command line!). Handy trick: you can pass your text editor a directory instead of just a filename to open the whole thing.
git add .and
git commit -minto one line, use
$ git commit -am "your message". Just remember that, if you've deleted files, they won't be pulled in (this is the shortfall of
git add .vs
git add -A, which includes everything).
Now it's time to play around with getting your repo up to Github and making changes to it directly on Github. Of course, if you do that, you'll need to bring the two back into alignment...
(Again, don't worry if yours uses
https: instead of
README.md(a different text format that sort of combines HTML and text) will be displayed by default on your Github repo's page.
originrepo on Github can get ahead of your local one. You can see the changes reflected on the Github README and also in the list of commits (reached by clicking the "commits" link at the top of the repo on Github):
Note that I've got a couple extra meaningless commits in there so don't worry that you don't have them
Now you'll get the chance to see branches in action and merge them together.
knock-knock. Check your status and you'll see that everything is the same. Any changes we make from here will be saved to this specific branch and won't show up in
masteruntil we merge it back in.
knock-knockbranch is one commit ahead of your
masterbranch. Verify this by checking your git log and then switching back over to the
masterbranch and also checking the log. You can also see, when you switch back to
master, that the new line isn't included in the file yet. It's like you never typed it. That comes in handy when you're working on code for a feature and it all goes to hell and you just want to blow it away completely -- you can erase the feature branch like it never existed.
master, merge your
master. Verify via the log and in your text editor that the next line of the joke is now a part of
Now we'll walk through solving a merge conflict. They don't happen often, but they can panic newbies because you feel stuck in the middle. It's not a big deal, you'll see.
masterbranch, add the final line "Git on with the assignment!", stage, and commit with the message "finish the joke".
knock-knockbranch. Verify that the joke has NOT been completed yet on this branch.
masterbranch. Although we could just merge
masterlike we did before, it's actually conventional to do the opposite -- merge
knock-knockand, once all conflicts are resolved, merge
master(which won't have any conflicts anymore). This is best practice because you don't really want to be fixing a bunch of merge conflicts on your
masterbranch if you're working with other developers or with a big code base. Anything you merge into
mastershould already be up-to-date and clean. So that's what we'll do here. Let's get the conflicts started -- merge
HEADending to our joke (
HEADis the branch we're currently sitting in) is on top and the ending coming in from
masterbranch is below it. To resolve this, simply delete the line you want to get rid of and delete all three merge markers. Once there are no merge markers left, save and quit the file, stage it and commit the result. Your merge is now complete. Pretty painless, right?
knock-knockbranch is up-to-date with
master, jump back over to
masterand merge in your
knock-knockbranch. It should go through without any issue -- your most recent commit that resolved the merge tells Git that everything's been taken care of.
masterbranch up to Github and view the result:
We did a lot of different things in this assignment and covered just about every situation you're likely to face with Git in the next several months. If you're still really unsure of what's going on, try doing it again from scratch. Again, though, you'll get so familiar with this stuff that it'll become second nature. This stuff will be particularly relevant again in the upcoming mini-course on Coding.
You've probably got a few lingering questions which are outside the scope of this particular assignment, so check out the Resources tab for more explanation.
See the lesson on Git for a comprehensive list of resources.
fetching your remote branches down onto your local machine and then
mergeing them into your current branch. It takes a minute to understand, but it's a pretty nifty process. Atlassian's tutorials cover fetching and pulling.
There's an alternative to manually opening up each conflicting file to remove the conflict markers -- you could try using the Git mergetool. Consider it an intermediate alternative for sure (I wouldn't dabble with it right away) but it's really helpful for larger merges where you've got several files that have conflicts.
The mergetool basically cycles through each conflicting file and opens it up in your text editor for you so you don't need to go digging for them yourself. You'll need to set up its configuration to use your preferred text editor (otherwise you might get stuck in Vim) and to not keep a bunch of backup files lying around, but after that it's a timesaver.
To fire up the mergetool when you're in the middle of a conflicted merge, just type
$ git mergetool and it'll bring up the first conflict:
ENTER to open the file up in your text editor and do exactly what you did before -- remove the merge markers and fix any offending lines of code. As soon as you save and close the file, the mergetool will bring up the next conflict for you to check out. Once you've gotten rid of any conflicts, do the normal stage-and-commit and you're good to move on.
NOTE: You'll want to set your editor to be your mergetool's default text editor (otherwise you'll be stuck in Vim land again). To do so, search "set YOUR_EDITOR as git mergetool".
Another helpful configuration is to remove the messy merge files that otherwise get leftover during a merge. To do so, use:
git config --global mergetool.keepBackup false
You can set Sublime Text 2 to be your default merge tool editor by visiting this Coderwall snippet, which has you do some quick command line config:
git config --global mergetool.sublime.cmd "subl -w \$MERGED" git config --global mergetool.sublime.trustExitCode false git config --global merge.tool sublime