-
Notifications
You must be signed in to change notification settings - Fork 14
Instructions for pushing your changes
So you've made some changes to your local repository, and now you want to push them up. How do you do this?
NOTE: You close an issue with a commit by adding closes #N or fixes #N to your commit message where the N represents the issue number.
When you're making changes to the master branch, usually someone else has pushed something up to it before you're done with what you're working on. If you want to merge your code back in, a rebase is usually the best option. Rebase will roll your changes back, do a clean pull down from the branch, and then apply your changes on top of that. This will usually result in some conflicts, but they are usually pretty simple to handle.
So after you've made all of your commits, we'll start with:
git pull --rebase origin <branch>
Usually after this, you'll have some conflicts, so we'll want to fix them. Let's run a quick git status.
You should see something like:
modified: app/views/welcome/index.html.erb
This is sometimes in red text if your terminal is set up for color. This indicates that the file app/views/welcome/index.html.erb had something changed to it, and you also made changes to that file. If we look at the file, you should see something like:
<<<<<<< HEAD
I am what was on the repository
=======
I am the local changes you made
>>>>>>> commit ID
This shows where your file and the current repository differ. Delete the lines <<<<<<< HEAD, =======, >>>>>>> commit ID, and keep the changes you want. You might keep only what was on the repository, only what changes you made, or some combination of the two.
Once you've done this, run the command git add <file>, or in this case:
git add app/views/welcome/index.html.erb
Once we've added our changes, we can continue with the rebase.
git rebase --continue
Repeat these steps until there are no more conflicts. Once successful, we can now easily push our changes up to the repository.
git push origin <branch>
New branches are usually for features. If you're working on a different branch, and have committed and completed your work and want to merge your changes back in, do this to merge your changes back into master.
git checkout master
git merge <branch>
If you don't have any conflicts, huzzah!
If at this point you do run into conflicts, follow these steps to clean things up:
If you run git status, you'll see something like:
modified: app/views/welcome/index.html.erb
This is sometimes in red text if your terminal is set up for color. This indicates that the file app/views/welcome/index.html.erb had something changed to it, and you also made changes to that file. If we look at the file, you should see something like:
<<<<<<< HEAD
I am what was on the repository
=======
I am the local changes you made
>>>>>>> commit ID
This shows where your file and the current repository differ. Delete the lines <<<<<<< HEAD, =======, >>>>>>> commit ID, and keep the changes you want. You might keep only what was on the repository, only what changes you made, or some combination of the two.
Once you've done this, run the command git add <file>, or in this case:
git add app/views/welcome/index.html.erb
Once we've added our changes, we can commit them.
git commit
This will create the default commit message: merge branch <branch> into origin/master
or something like that. This sounds fine if your branch name is like login, but if it's something more ambiguous, you may want to refine the commit message some more: merge updates to welcome#index into master
Now we are ready to push!
git push origin master
A nice image showing a typical git flow is near the top of this webpage.