Please sign in to comment.
Turning off syntax highlight until I can figure out a color blind fri…
…endly theme for pygment
- Loading branch information...
Showing with 62 additions and 22 deletions.
|@@ -0,0 +1,38 @@|
|+On git push --force|
|+v1.0, Tue Feb 19 PST 2013|
|+`git push --force` can be a pretty scary command to execute for some, as it should be. The worst case scenario is that history is rewritten on a remote repository, and people lose valuable work. It is also bypassing the integrity that git provides. To quote the `git push` man page:|
|+ -f, --force|
|+ Usually, the command refuses to update a remote ref that is not an ancestor of the local ref used to overwrite it.|
|+ This flag disables the check. This can cause the remote repository to lose commits; use it with care.|
|+So what does it mean to "use it with care"? This article is meant to quickly list a few use cases where I consider `git push --force` to be reasonable to utilize.|
|+== Personal Code|
|+First would be repositories where the author has sole access to both local and remote repositories (self-hosted). The author may decide that a few commits produce a messy log and wish to clean them up with `git rebase` after having pushed them to a remote repository. They could also do something more simplistic with `git commit --amend` after again, having pushed to a remote repository. This can be either a complete mistake (typo in the commit message), or intentional after looking over a few commits later. In essence, it becomes more of a convenience for them.|
|+== Personal Code Forks|
|+Somewhat like personal code, but potentially available to other users to have access to the code. These are generally forks of other repositories in order to generate pull requests of some sort. Personally I have an exclusive fork of RVM that I use to make contributions to the project. In this case rebasing and amendments may be requested by upstream developers after they have had a chance to review contributions. This is popular process on code sharing sites such as GitHub to cleanup commits before they are integrated to a larger audience. Like personal code repositories, this is another case where history rewrites carry less risk, though it should be noted that users can at some point interact with the repository. In this case the developer should consider whether or not they want to affect that user's history. An example of this is having 10 users forking the personal code fork (stale upstream for example). In such cases I would recommend against using `git push --force`.|
|+== Emergencies *With Communication*|
|+Examples of what can be considered an emergency would be issues such as passwords and credit cards getting pushed. If it's something such as credit cards, the developer may have to bite the bullet and overwrite history, communicating to other users of the repository regarding the issue. This is much easier to deal with for internal repositories, but public facing repositories are a bigger pain. In cases of public repositories, you will have to deal with potential user fallout, as well as the fact that someone may have a copy of the repository backed up before the push happened. There is not a universal answer to this, and should be weighed on a case-per-case basis as with other emergencies. Just remember to communicate these changes so that users understand that the lack of integrity between local and remote repositories is intended and not unauthorized access.|
|+To conclude, here are some basic rules regarding using `git push --force`:|
|+* In general, don't push unless your local repository is in a state that should be pushed out to the repository to avoid these situations|
|+* If there are other users of the repository, don't do it, using `git revert` if really necessary (emergencies should be weighed accordingly)|
|+* For repositories with sole authors, there is less risk and `git push --force` is reasonable to utilize|
|+* When in doubt, communicate|