0

While there's plenty of information on how Git works, I find there's not much on how it should be used. When should a commit be made? When should a push be made? Currently I'm only coding by myself.

Part of the reason why I use Github is as a backup encase my hard drive dies. This seems to suggest to push as often as possible. Also, I'm in the situation right now where I fixed a bug but there's another and the feature still isn't working. Is now a good time to push to remote repo?

I don't really see the point of committing to a local repo. I guess the point is to track changes while the code isn't good enough to be pushed remotely?

Community
  • 1
  • 1
Celeritas
  • 14,489
  • 36
  • 113
  • 194

3 Answers3

2

There's plenty of workflows available, each defining different ways of using the git remote and local repos.

To name a few:

  • centralized workflow,
  • feature branch workflow,
  • gitflow workflow,
  • forking workflow.

Generally, remember that whatever's in your local repo, it is yours to experiment with. Once it's on the remote - even if it's just a feature branch - people may depend upon, hence you may not rewrite commit history as easily.

See details here.

Celeritas
  • 14,489
  • 36
  • 113
  • 194
hauron
  • 4,550
  • 5
  • 35
  • 52
0

Ideally these should be the steps:

  1. A separate branch should be created.
  2. Push your local changes to this repository.
  3. Once you are done with all your changes, you should pull the master and merge it with your branch.
  4. After that you should commit your changes.
  5. Then you should push the changes to remote.
  6. Finally your branch should be merged and pushed in the master.

I feel this is a very good answer and you can refer this as well.

Community
  • 1
  • 1
Pritam Banerjee
  • 17,953
  • 10
  • 93
  • 108
0

There are several use cases for keeping some commits locally and never pushing them out. Without writing a book about it (as there are many more), here are the two biggest ones I find myself using on a daily basis:

  1. Experimentation work that you don't want to share with anyone else. This doesn't really apply if you're working alone, because if no one but you can see the remote it makes no difference whether it is just in the local, or both the remote and local. However, if you include more devs in the future, or plan to include more, it might be a good idea to get into the habit of keeping some of your work local only.
  2. Say you're working on a relatively large feature, and it took you 100 commits to get it done. Instead of pushing out a stack of 100 messy commits (things like "fixed a typo", "fixed failing unit test", "fixed merge conflicts", "refactored class X to accept optional parameters"), it might be better to squash your work to one commit, and then push it out. That way your git history generally cleaner, and is easier to manage and look back on. This can be especially useful if you want to deliver some features to one customer/user, but not to another. Note that squashing can obliterate history though, use with caution.
Matt Messersmith
  • 12,939
  • 6
  • 51
  • 52