I work on several systems, a desktop and laptop being my primary two development stations. I want to be able to use my github to keep my codebase up to date while switching between systems; however, sometimes features are not complete and to me at least, it seems like an inappropriate strategy to make a commit without it being a finalized feature/change (please correct me if this is a wrong way of thinking).

I am curious though, how would I push that to my remote/branch without it being in a commit? What is the appropriate method for what I am trying to accomplish?

CodePudding user response：

The short answer to your question is, no. Git maintains history of changes where each commit is related to its parent. You cannot push changes without having them committed.

[...] sometimes features are not complete and to me at least, it seems like an inappropriate strategy to make a commit without it being a finalized feature/change (please correct me if this is a wrong way of thinking)

This is not the correct way of thinking when it comes to git. It might be the correct when discussing central systems, but distributed ones like git are different. What you're wanting is to be able to share work in progress (WIP) across systems. You can do this in a few ways:

Developing locally then pushing when done

Locally, you can do whatever you want to the history without impacting others (avoiding commits that have already been pushed). You can create a new branch off of main/master, make as many WIP/broken commits as you want and then rebase to combine commits together before pushing. The downside is all of this has to be done on one system, and during that time it won't be visible to your other systems during development.

Pushing WIP changes so others can see

First, you should create a branch whose name clearly indicates WIP. For example, let's say you add a WIP prefix to each of your feature branches. Make sure anyone you're working with is aware that branches with this prefix are unstable and likely to have their history rewritten.

On these branches, you should do your development in small commits. One big commit at the end is something no one wants to have to sit through and review, especially if it's a large feature. You can push freely since you're on a separate branch from others. You can also rebase your branch onto origin/master to stay up to date and also to squash some of your commits into larger ones if needed. When you're ready to push again, you can do git push --force-with-lease origin your_branch_name to overwrite remote with your newly rebased changes.

If you switch to another system one day and want to ensure your local copy is up to date, you can simply switch to that branch and do git pull --rebase. This will perform a rebase instead of a merge, which will ensure your history stays linear. When you're done with development, you can rename the branch so others know it's stable. To do that, you need to rename the branch locally and delete the remote copy. This can be done by switching to the branch and running git branch -m new_name to rename the branch. You can delete the remote copy with git push --delete origin old_branch, and finally you can push the new branch name to remote with git push -u origin new_name.

CodePudding user response：

Ôrel provided a reasonable answer.

Prefixing commits with WIP and then amending them later.