Menu
We started using Mercurial a several weeks ago. Most developers follow this workflow:
Today, one of our developer suggested that we do:
That way, we have a lot less "Merge" changesets in the log.
Some of us think it's just a matter preference. Some of us think one is better than the other. We don't have much experience and don't want to live the downsides of misusing the tool. So if one approach is more advisable then the other, please let me know why.
374
Commits are done locally. Push - pushing sends the recent commit history from your local repository up to GitHub. If you're the only one working on a repository, pushing is fairly simple. If there are others accessing the repository, you may need to pull before you can push.
git commit : Append a new commit (last commit + staged modifications) to the local repository. (Commits are stored in folder /. git .) git push , git pull : Sync the local repository with its associated remote repository. push - apply changes from local into remote, pull - apply changes from remote into local.
Basics. – Pushing comes after committing. Git commit records and tracks changes to the repository with each commit points to a tree object that captures the state of the repository at that moment the commit was performed, all in one complete snapshot.
Whats the difference between push , commit & fetch ,merge. Git commit basically “records changes to the local repository” while git push “updates remote refs along with associated objects”.
I like your original procedure more, but reasonable people can certainly disagree. I consider merging an actual piece of software development work and like having it be a first class citizen in our process.
In your second/suggested procedure the risk is that the pull does some stuff you really don't want and then you have a very hard time separating it from the work you've already done.
For people who just can't stand branchy history the usual preferred workflow is:
where the --rebase option appears on pull after you enable the rebase extension. I'm not a fan of rebase because it's technically rewriting history which is antithetical to how mercurial is supposed to work, but I'm in a rapidly shrinking minority on that point.
Bottom line, if you really don't want a branchy history use rebase -- don't update into uncommitted changes as it's hard to undo.
83
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
