Pushing
suggest changeIntroduction
After changing, staging, and committing code with Git, pushing is required to make your changes available to others and transfers your local changes to the repository server. This topic will cover how to properly push code using Git.
Syntax
- git push [-f | –force] [-v | –verbose] [<remote> [<refspec>…]]
Parameters
Parameter | Details | ——— | —–– | –force | Overwrites the remote ref to match your local ref. Can cause the remote repository to lose commits, so use with care. | –verbose | Run verbosely. | <remote> | The remote repository that is destination of the push operation. | <refspec>… | Specify what remote ref to update with what local ref or object. |
Remarks
Upstream & Downstream
In terms of source control, you’re “downstream” when you copy (clone, checkout, etc) from a repository. Information flowed “downstream” to you.
When you make changes, you usually want to send them back “upstream” > so they make it into that repository so that everyone pulling from the > same source is working with all the same changes. This is mostly a > social issue of how everyone can coordinate their work rather than a > technical requirement of source control. You want to get your changes > into the main project so you’re not tracking divergent lines of > development.
Sometimes you’ll read about package or release managers (the people, > not the tool) talking about submitting changes to “upstream”. That > usually means they had to adjust the original sources so they could > create a package for their system. They don’t want to keep making > those changes, so if they send them “upstream” to the original source, > they shouldn’t have to deal with the same issue in the next release.
(Source)