101–110 of 140 posts
I used to like tabbing over to terminal to run my git commands and do my diffs.
Now I use the git flow plugin and do my full process including amends, push, etc interactively.
Much of it can be done by keyboard and the closeness to the auto linting and reformatting has caught many small errors, left behind little items and generally improved code quality greatly.
While I agree with the spirit of this comment, in practice I do this:
1. Update:
git pull --rebase
git rebase -i HEAD~X
git push origin BRANCH -f
Works pretty well for me. That being said, I would love to be able to take care of 2 and 3 within GitHub for branches that are already updated to the parent branch.
I use almost exactly this workflow with rclone. This bit resonated particularly: begin quote Never merge with GitHub! There’s a button GitHub that says “rebase and merge” that could theoretically be used for merging pull requests. I never use that (and if I could, I’d disable/hide it). The reasons are simply: I don’t feel that I have the proper control of the commit message(s) I can’t select to squash a subset of the…
Earlier quoted context omitted.
Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.
You can allow rebase merging [1] while disabling other PR options, and require linear commit history [2] if desired. [1]: https://docs.github.com/en/free-pro-team@latest/github/admin... [2]: https://docs.github.com/en/free-pro-team@latest/github/admin...
o-o-o o-o-o o-o
/ \ / \ / \
o-------o-------o-----o
o-o-o--o-o-o--o-oEarlier quoted context omitted.
Does anyone know how to make this "cactus" workflow work better on github? We use it in our organization and between us we know to always manually rebase before merging. However, when we receive an external PR from someone else it's a pain. It's also easy to accidentally forget to rebase before merging.
I always go into each new repo I create and turn off the ability to merge and require commits to be up to date with master, I think this might get what you want?
>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…
I’d be willing to bet they sometimes, even if rarely, use stash when as you say it’s the right tool to use.
I think the point is not stashing meaningful amounts of changes, as if they can be recalled later. Sounds like solid advice that requires some discipline
>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…
git add . git commit -m "wip" when you're back git reset HEAD^ Keeps working changes nice and tidy in the branch they belong to, you can push them, and they are easily recoverable from the ref log, unlike stashes. Also, god help you when a stash fails to apply.
Earlier quoted context omitted.
I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I realize this isn't a best practice for config files but it is what I need to do for my particular mountain of technical debt. This works particularly well since the config files rarely change in a permanent way. I will only do it short term, though. For me, Stash is a tool I use sparingly as a conveni…
> I use them to stash changes to config files that remain fairly stable across branches but require local paths, etc. I had to resort to git's assume-unchanged[O] to keep these changes out of commits made in the heat of battle. > this isn't a best practice for config files Have had great results (in dotnet land) with MS' Secrets Manager[1]. [0] https://www.git-scm.com/docs/git-update-index [1] https://docs.microsoft.…
>Never stash Er, no. Right tool for the right job. Whilst I agree that the idea of putting differing lines of work into different branches is great, that's not what stash is for. That's what checkout is for. Stash is used to record the current state of the working directory and index while also returning to a clean working state. I guess for the author, stash is used to preserve changes when pulling in upstream chang…
only related by "git" but while I believe i'm fairly proficient in git I'm not sure how to go about explaining to an inexperienced person how to fix a merge conflict. It feels like not a simple thing to explain. As an example someone sent me a PR with 15 commits. github claims only 1 file has changed and it's a new file so no conflicts (which AFAIK is correct) but git complains that somewhere around commit 4 there's…
That sounds like a rebase merge, which might be the setting in the repo. A normal merge wouldn't attempt commit by commit.