A workflow is a set of procedures one follows using Git as a tool to accomplish the task of making productive commits to the project. Please be bold in editing this with your suggestions since we're all basically Git newbies here. The style of this page should be in terms people clearly understand, not necessarily the official git way of describing everything.
If you don't have any uncommitted changes lying around, just perform:
git pull origin master
But if you do, probably the easiest way to get up to speed is:
git stash
git pull origin master
git pop
This will make a temporary commit with all modified files in your git repo, update the repo to the latest version on the server, and then try to apply your changes on top of the latest version. This tends to go well if your changes don't conflict with someone else's changes. If they do, then you have to [[GitWorkflow#Manual-Merging|manually merge the changes]].
Another way to deal with this problem is simply finish up whatever changes you are trying to make and perform the pull later. This is arguably the "right way" to do things. You will only have to deal with merging once when you're done with your work rather than throughout the process (if you want to keep your repo updated).
Use this command to see a list of changes you've made from the last commit:
git diff
Type this command to see the log of commits:
git log
To undo changes to a single file (and restore it back to what it was for the last commit), do:
git checkout <file>
To undo all of the modifications that were made since the last commit, do:
git reset --hard HEAD
If you have performed enough work so that the changes you made can be pushed into the repository and no part of the site will break, then it's probably time to make a commit. You should make commits early and often because you can always merge them later. Generally you want to add any new files that are not already in the repo like this:
git add <file>
Then if you want to commit all the files you've modified since the last commit, do:
git commit -a -m "Some commit message."
If you do not want to commit every file you've changed, manually add each file you want to commit:
git add <file1>
git add <file2>
git commit -m "Some commit message."
Note that the -a flag is left out.
If you don't even want to commit every change in a particular file, you can use the -p flag (which stands for patch). This can be useful when you realized you've made a whole bunch of unrelated changes to the file and want to make it so each commit represents a single atomic bug fix or feature.
git add -p <files/directories>
git commit -m "Some commit message."
Git will show you each change in each file you specify and you can answer "y" to commit the change or "n" not to.
If you want to write a commit message with multiple lines, leave out the -m "Some commit message" part.
First make sure everything you want to share is already committed before performing a git pull or anything else. Then do:
git pull origin master
You may be prompted to resolve [[GitWorkflow#Manual-Merging|merge conflicts]] at this point. After those are resolved and committed (if there were any), perform:
git push origin master
That should be all. The push will succeed unless somebody else pushed in between the time you did your pull and your push. If there was an error during the push, do @git pull@ again (and resolve any merge conflicts) and then git push again.
Sometimes you've made a bunch of commits while working on something without pushing. Those commits may be have been basically backups of your progress and many of which don't really affect a single bug fix or feature. Sometimes they might have nonsensical commit messages because you had just been testing various fixes. Sometimes those commit messages have swear words in them. In these cases, it might be beneficial to combine a bunch of commits into a single commit and change the commit message into something decent.
First, decide how far back you want to modify the commits. You can use something like HEAD~5 to indicate the last five commits (You can use git log to help figure out how far back you want to go) or you can say origin/master to indicate that you want to edit all commits since your last pull. Then, issue the following command:
git rebase -i <HEAD~5 or origin/master or something>
An editor will come up and you can specify which commits you want to merge together by putting the word squash in the first field of the lines specifying those commits, replacing the word pick. Except do not squash the first commit you want to merge with the others. That will be the commit all the others will be merged onto. After this command is executed, git will give you an opportunity to edit the commit message for all of those commits squashed together.
After all of this is done, you can push the result.
Technically, we're supposed to use them for every new feature we want to add since they're easy and light-weight. It could be a useful organizational tool, but we haven't used it much here. It's probably not necessary for the way we work and think about working, but that's definitely open to change.
This is a gigantic pain in the ass and generally we try to avoid it by not working on the same files at the same time, or work on entirely different portions of the file if we do. However, it sometimes is necessary. One lazy way to handle it is to just pick someone's version and go with it, discarding the other person's version. Usually you'll pick someone else's version over yours if you decide your own changes are minor and can be redone later. Suppose file source:www/css/layout.css has a merge conflict. You can discard your own version (and going with the version that had previously been submitted to the repo) with the following:
git checkout HEAD -- www/css/layout.css
The hard way is to open up each file that has a conflict, looking for markers like <<<<<< and >>>>>>. Those delineate which lines are from your version and which lines are from the other version. Figure out what best to put there instead and get rid of the <<<<<, >>>>> and ------.
After you have resolved the conflicts in every file that was conflicting, commit your work with git commit and push.
You can generally reset the state of your repo back to what the server thinks it is with the following command:
git reset --hard origin/master
This will wipe out any files you've changed, so you might want to back those up first.