-
Notifications
You must be signed in to change notification settings - Fork 72
Suggested Git Workflow
git allows for many different workflows... here's the one that I use, and that should give you the minimum of trouble when creating pull requests and keeping your code up to date. It consists of four main activities:
Reading those links will give you the background you need. GitHub has excellent documentation for all things git and GitHub. Read it!
My suggested workflow has two key principles:
- Don't commit to master
- Create a new topic branch for each day
The following shows a mostly-commands summary of the GitHub documentation + my principles:
Fork the RubySteps/21-day-challenge repository using GitHub interface.
Next, clone your repository to your machine, add the upstream as an origin, and set the --ff-only merge option for the master branch:
git clone [email protected]:USERNAME/21-day-challenge.git
cd 21-day-challenge
git remote add upstream [email protected]:RubySteps/21-day-challenge.git
git config branch.master.mergeoptions "--ff-only"The --ff-only merge option means that when you pull from upstream master, git will refuse to update your local master you have any unique commits. It allows fast-forwards only.
Pulling the latest updates in to your master branch is easy, and with the ff-only option set you ensure that your local master matches upstream master.
git checkout master
git pull upstream masterCreate a topic branch off of master for each day's work.
git checkout -b day01 master
# commit, commit, commit
git push -u origin day01The -u flag tells git to track this branch after pushing it to your remote. From now on, you can push new commits to your remote branch with a simple git push.
By all means, go for it. Use whatever makes sense to you. This workflow works very well for me and minimizes confusion and headaches - for me. If something works better for you, use it.
The proof is in the pull requests :) As long as you submit a well-formed pull request you're good to go. If your pull request isn't well-formed, I'll ask you to modify it so that it is.
This is the simplest way I know of to create well-formed pull requests for this project, every time. I'm always looking for ways to improve, so if you know a better way then please let me know!
Nope! It's generally a good idea, but not required... and definitely not in this project.
In fact, being "up to date" is mostly theoretical. If you update your master and create a new branch, and I merge new work in to master, you're already out of date!
On a truly collaborative project, where you're modifying the same files as others, it's helpful to update your master so you can minimize the chance of merge conflicts, and address any conflicts early on.
In this project, where you only modify your own files, you shouldn't ever have any merge conflicts (unless you create them for yourself, by modifying the same file from two different branches).
If you've followed the workflow and pushed your branch with a git push -u, then you can simply git push after that and the pull request will get updated with the new commits.
You should submit another pull request. You can submit multiple pull requests for the same day if I've already merged your work for that day, and you want to add on to it.
Follow the workflow :)
A beautiful thing about git is that you can have multiple branches in parallel, especially if they don't depend on one another. Each of our day's work in this project is independent of previous work.
You should have a pull request for each day. If I haven't merged the previous day's work yet, don't worry. It will make it in when I merge.
git checkout -b day01 master
# commit commit commit
git push -u origin day01
git checkout -b day02 master
# commit commit commit
git push -u origin day02Your day02 branch won't include the day01 work, because it's branched off of master. However, the next time you do a git pull upstream master to pull the latest commits, it will include anything that's been merged in since your last pull. This might include your day01 and day02 work, or not. It just depends on whether I've gotten to it or not. Welcome to the magic of git :)
It's a little trickier, but not much. You have three options:
git checkout -b day02 day01
# commit commit commit
git push -u origin day02You'll now have two branches, with the day02 branch including all of the commits from day01. You should submit a pull request for each branch.
Assuming that the day01 pull request is well-formed, you shouldn't have any problems. When I merge it in to upstream master, day02 remains intact because it has the same commits from day01.
If day01 wasn't well-formed and you have to do some work on it, it gets a bit messier. Feel free to open an issue if you need some help.
For this reason, it's probably easier to just...
This isn't how you would ordinarily use git, but it works well for our purposes. You can think of every day's work as creating a new entry in a journal. It's perfectly fine to copy yesterday's work to today and continue on.
git checkout day01
cp -Rp 2_adventures/001/USERNAME/01 2_adventures/001/USERNAME/02
git checkout -b day02 master
git add 2_adventures/001/USERNAME/02Checking out the day01 branch gets you access to your day01 work - even if it hasn't been merged upstream yet. From there, you copy the work folder with cp -Rp (copy directory & preserve attributes).
At this point, git will not be tracking your 02 directory. You can create a new branch off of master. commit your work, and push.
The day01 branch will contain only the 01 directory, and the day02 branch will contain only the 02 directory. Convenient, huh?
See the information on long-running projects for how to do this.