Re: [git-users] Updates were rejected because the tip of your current branch is behind its remote counterpart.
On Thursday, 31 August 2023 at 18:49:35 UTC+10 mag...@therning.org wrote: What you are trying to do is to rewrite history on the central git repo. While git allows doing that, it does require you to signal that you are completely sure you know what you are doing. Look at '--force' and related flags in 'git push --help'. If you are working on this repo by yourself you can pretty much do whatever you want, but if you work with others and they have based any of their work on the 'staging' branch after you merged in your 'feature-branch', then you should look at 'git revert --help' instead. Ok. This makes sense - I am working alone so I can force - if I was in a team, this would cause problems. So effectively, git has no easy "undo" option and requires manual removal of code There are at least a coupld of things you can do - invest in ways to test locally, then you don't have to push at all. - invest in ways to test on your 'feature-branch', then you don't have to merge into 'staging' (and push the merge) Testing changes has zero affect on business decisions deciding that changes previously requested are no longer viable. It is impossible to test a code base against the management teams inner thoughts and market forces! -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/85cff136-7745-464e-8113-c9f0ab52a8dbn%40googlegroups.com.
[git-users] Updates were rejected because the tip of your current branch is behind its remote counterpart.
I have a `*master*` branch which is in sync with our LIVE site I have a `*staging*` branch which was in sync with our STAGING site I created a new branch `*feature-branch*`, made some changes and merged it into `*staging*` branch for testing We have decided that we don't want these changes. So I performed a git reset on the staging branch: $ *git reset XX* (hash of last commit before the *feature-branch* merge) This left the branch with a load of files "not staged for commit" - So resetting the branch didn't actually achieve the desired result. So I performed a hard reset: $ *git reset --hard XX* (same hash of last commit before merge) This resulted in my working tree being clean - *perfect*. Exactly what I wanted. So I tried to push the branch to the remote server to "wipe the latest update" but I get this message: ! [rejected]staging -> staging (non-fast-forward) error: failed to push some refs to 'ssh://xxx.xxx.xxx.xxx:xxx/git/staging.xxx.xxx.xxx' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. If you want to integrate the remote changes, hint: use 'git pull' before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. Now, I would assume if I perform a `git pull` I'm just going to be in the same position I was in at the start, with a sh**load of files "not staged for commit" So, please help me understand. 1. How do I make the remote `staging` branch realise that my local branch is the correct branch and is up to date and not make me integrate remote changes which I have already removed. 2. How do I avoid this sh**show in the future so that when I want to just go back to a commit, just go back and move on? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/2b81956e-6095-41ad-9581-3b390786d48an%40googlegroups.com.
[git-users] Git keeps deleting files
This issue has occurred 4 times with the last 4 commits and I have no idea how to stop it and it is becoming increasingly frustrating. Composer files are being deleted from within my project within */vendor/composer* Each time I merge a branch, I go to check the application and get an error: Fatal error: require(): Failed opening required '\vendor\composer/autoload_static.php' (include_path='.;C:\php\pear') in \vendor\composer\autoload_real.php on line *33* In .gitignore I have the following lines so not sure why these files are ever being touched: */vendor/composer** So I then go to the live site, copy the files back into the */vendor/composer* folder and check the site is up and running again. Then I run `git status` which shows: *On branch masternothing to commit, working tree clean* Then I check out a new branch, make modifications, commit and merge the branch and I am back to square one... Fatal error: require(): Failed opening required '\vendor\composer/autoload_static.php' (include_path='.;C:\php\pear') in \vendor\composer\autoload_real.php on line *33* How can I tell git to ignore these files. Do not touch them and especially, NEVER delete them... I still manually apply changes to the live site using WinMerge with the git repo versus the LIVE site because I can't trust git -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/67fdeb75-e43c-4b8c-9e17-837873767941n%40googlegroups.com.
[git-users] Re: git --amend doesn't seem to work as I anticipated
I amended the commit and then re-merged and the amended commit did not merge On Thursday, 2 September 2021 at 19:02:01 UTC+10 philip...@iee.email wrote: > > Do amends not merge? > > In general, don't try to `--amend` a merge. It would produce an evil merge > (i.e. something in a notionally clean merge that wasn't actually present in > either branch). As best I remember, if you try to amend a merge you only > get an updated single parent commit, rather than a merge. (try a bit of > experimentation to check) > > If the merge was clean (make this easier), it's better to rewind/rollback > to just before the 'merge', apply the --amend to the branch, and then > remerge. (--amend is a squash for a single commit rebase ;-) > > The 'rerere' database (if enabled) can help with tricky merges (it > remembers the previous conflict resolutions!), but it's documentation is > horrendous/next to useless, despite it being real magic [sufficiently > advanced technology] > On Thursday, September 2, 2021 at 12:21:06 AM UTC+1 SJW wrote: > >> I have been working on a feature-branch - made a few commits and ready >> for testing. >> >> I `git checkout staging` branch, merge in feature-branch and then push it >> to the staging server. >> >> While testing in staging I realise I have left some logging on or >> something else minor. >> >> I checkout feature-branch again and remove the logging BUT this time when >> committing, instead of a brand new commit, I use `git commit --amend` >> >> I `git checkout staging` branch again, merge in feature-branch again and >> then push it to the staging server. BUT ... the last changes committed via >> `--amend` are not present. This isn't the first time this has happened so >> I am guessing it's not something I have done, it's actually a "feature" of >> git. Is this correct? >> >> Do amends not merge? >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/b4a20183-c010-44b8-bd08-451edb988d89n%40googlegroups.com.
[git-users] git --amend doesn't seem to work as I anticipated
I have been working on a feature-branch - made a few commits and ready for testing. I `git checkout staging` branch, merge in feature-branch and then push it to the staging server. While testing in staging I realise I have left some logging on or something else minor. I checkout feature-branch again and remove the logging BUT this time when committing, instead of a brand new commit, I use `git commit --amend` I `git checkout staging` branch again, merge in feature-branch again and then push it to the staging server. BUT ... the last changes committed via `--amend` are not present. This isn't the first time this has happened so I am guessing it's not something I have done, it's actually a "feature" of git. Is this correct? Do amends not merge? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/9bac56cf-348f-46b7-bb29-cbf61c32b06en%40googlegroups.com.
Re: [git-users] Change management practices
I am a lone developer so it is pretty straight forward to merge and rebase. Nobody touches git except me. Is there a benefit in rebasing over merging? e.g. working in feat-2 which I realise needs some code from feat-1 - I can rebase OR just merge. I guess I do merge all the time so I can anticipate and handle issues. My fear with rebase is probably just the unknown. rebase --squash - actually, that's why I thought it might be ok - not squashing everything in a merge but often will make a change, commit, and then in testing see an error - modify the bug (e.g. missing ; ) and commit again - those commits I would be happy to squash On Wednesday, 1 September 2021 at 23:43:58 UTC+10 philip...@iee.email wrote: > > > If you can avoid branching feat-2 from feat-1 then that is worthwhile if > if allows an independent feat-2 to be released while feat1 is still in > test. However if there is some shared code, then it's worth branching > earlier within feat-1 before the feature-1 visible changes show up. It is > there that a code move rebase may be valid (must end up 'treesame' to the > code in test), just so you gain that starting foothold. > > rebase --squash is useful for minor corrections and mistakes, but it (from > my perspective) is poor practice to simply squash everything into the > classic "big ball of mud" change - that's also a hang-over from drawing > office procedures, and legal wanting to avoid 'discovery' (which is why you > rebase early & often, but retain a clean history ;-). > > How is the team, management, and the servers organised? This can affect > how you can get the best workflow. Do you have independent forks on the > server, or does every one have commit privilege to the golden branch > (separation of concerns..)?. Is there a 'maintainer', who does that final > validation for the merges and tagging of releases? Is this an entirely > software product - is it GUI style, or hardware control or database > manipulation, etc. (who else has fingers in the pie who aren't > coders/devs). Is it a run fast and break things shop, or a steady as she > goes, no icebergs shop? > On Tuesday, August 31, 2021 at 12:09:06 AM UTC+1 SJW wrote: > >> Thanks to both of you for providing such detailed, in-depth responses. >> >> Your assumptions were correct. I branch per feature. I have actually >> branched a new branch (feature-branch-2) from another feature branch >> (feature-branch-1) once but then I wasn't sure if it was logically right >> because now, feature-branch-2 actually has 2 projects or features and it is >> entirely possible for feature-branch-2 to be approved for production before >> feature-branch-1. Not a major problem I guess because I can just leave it >> unpublished until they are both approved however, just wasn't sure if I was >> following good practice. >> >> And then, new changes to feature-branch-1 - I thought - do I just apply >> them into feature-branch-2 and make this the single release no longer >> requiring me to manage 2 branches... Your comments have given me some food >> for thought. I will do a bit more rebase research I think >> >> I did look at rebase --squash and thought it was an idea given the >> numerous commits I might have in a branch but, I was concerned about losing >> history and wasn't sure the benefit outweighed the detriment so your >> comments have solidified my thinking on this. >> >> There's a bit to unpack in the responses so I will get acquainted with >> these suggestions. >> >> Any recommendations on learning would be appreciated too - if you have a >> YT video or text or something else that covers the common usage patterns I >> am interested in learning. >> >> On Tuesday, 31 August 2021 at 02:32:26 UTC+10 Mikko Rantalainen wrote: >> >>> On Sun, Aug 29, 2021 at 3:51 AM SJW wrote: >>> >>>> I will regularly create feature branches for each new enhancement or >>>> fix. The problem rears its head when testing is delayed and the first >>>> feature (feature-branch-1) is still not approved for production and sits >>>> as >>>> a branch awaiting merge. >>>> >>>> Now, in my feature-branch-4 I am working In a similar area and really >>>> need to consider changes from feature-branch-1 and I usually just copy >>>> some >>>> of those changes over. >>>> >>>> Now this is not very efficient and I thought rebase would work great >>>> BUT that code is not approved and may actually change. >>>> >>>> I really just don't know what's the most efficient way to man
Re: [git-users] Change management practices
Thanks to both of you for providing such detailed, in-depth responses. Your assumptions were correct. I branch per feature. I have actually branched a new branch (feature-branch-2) from another feature branch (feature-branch-1) once but then I wasn't sure if it was logically right because now, feature-branch-2 actually has 2 projects or features and it is entirely possible for feature-branch-2 to be approved for production before feature-branch-1. Not a major problem I guess because I can just leave it unpublished until they are both approved however, just wasn't sure if I was following good practice. And then, new changes to feature-branch-1 - I thought - do I just apply them into feature-branch-2 and make this the single release no longer requiring me to manage 2 branches... Your comments have given me some food for thought. I will do a bit more rebase research I think I did look at rebase --squash and thought it was an idea given the numerous commits I might have in a branch but, I was concerned about losing history and wasn't sure the benefit outweighed the detriment so your comments have solidified my thinking on this. There's a bit to unpack in the responses so I will get acquainted with these suggestions. Any recommendations on learning would be appreciated too - if you have a YT video or text or something else that covers the common usage patterns I am interested in learning. On Tuesday, 31 August 2021 at 02:32:26 UTC+10 Mikko Rantalainen wrote: > On Sun, Aug 29, 2021 at 3:51 AM SJW wrote: > >> I will regularly create feature branches for each new enhancement or fix. >> The problem rears its head when testing is delayed and the first feature >> (feature-branch-1) is still not approved for production and sits as a >> branch awaiting merge. >> >> Now, in my feature-branch-4 I am working In a similar area and really >> need to consider changes from feature-branch-1 and I usually just copy some >> of those changes over. >> >> Now this is not very efficient and I thought rebase would work great BUT >> that code is not approved and may actually change. >> >> I really just don't know what's the most efficient way to manage >> situations like this without stopping development and waiting for testers >> to approve code but this approach results in 1-2 days of waste where I just >> twiddle my fingers waiting... >> > > I'm assuming you're already able to commit logical changes, not files. If > that's not true, learn that first. > > I'm also assuming you're doing real feature branches instead of having a > single branch per developer. > > The way I do it is to assume that whatever code my current branch depends > on is going to be blessed in the future. Or at least the internal APIs that > I use do not change and the problems are just in the implementation of > those APIs. So logically I just branch my next feature on top of the > non-blessed previous branch X. > > When testing/QA finds something wrong in branch X, it will be fixed as new > branch X' and I just rebase my branch from X onto X' (see "git rebase > --onto"). > > If you mix bug fixes and features in your feature branch, the simplest way > is to just "git rebase -i" your own branch and reorder/push all the bug fix > patches towards the already blessed commits (that is, make the > DAG/"history" appear like you did all the bug fixes first and all the > feature stuff after that). That would allow getting those included in the > blessed master(?) branch sooner (simple and minified bug fixes should be > obvious and easy to verify). Logically you would have an implicit branch > called bug-fixes that follows the blessed code and your feature branch then > builds on that implicit branch. > > Note that whenever you rebase or merge any code, all the testing done on > the old branch is of dubious value because of unforeseen interactions with > the combined code. That's why I prefer to do automated testing that's > included in the feature branch so that you can easily re-run the tests > after the merge/rebase. > > And never ever do squash merge/rebase, that just loses history. If you > want to make it easier to understand that some sequence of commits should > be considered an inseparable unit, do a "bypass" next to it with "git merge > --no-ff". That way your bypass commit will be equal to squash commit but it > will have a parallel line with all the original commit details. I prefer to > do such bypass merges only for the blessed/master version but if you want > to do it early, you will need to do "git rebase -p" from that point forward > which will make things more awkward. > > -- > Mikko > &g
[git-users] Change management practices
I have been Watching YouTube tutorials in order to expand my knowledge in git but there are now some questions that this has raised so I was hoping someone here could educate me on some best practices or philosophies I should consider. The main point is around rebase - I see great value in this but the whole philosophy was around bringing committed code into your feature branch. I will regularly create feature branches for each new enhancement or fix. The problem rears its head when testing is delayed and the first feature (feature-branch-1) is still not approved for production and sits as a branch awaiting merge. Now, in my feature-branch-4 I am working In a similar area and really need to consider changes from feature-branch-1 and I usually just copy some of those changes over. Now this is not very efficient and I thought rebase would work great BUT that code is not approved and may actually change. I really just don't know what's the most efficient way to manage situations like this without stopping development and waiting for testers to approve code but this approach results in 1-2 days of waste where I just twiddle my fingers waiting... Any advice or personal experience would be welcome. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/fa00ea44-d8ea-417b-8cdb-441f14cf99aan%40googlegroups.com.
[git-users] git amend wont merge
I had a bug in my code so I branched master to `bugfix-333` and I added a `var_dump();` in the code to debug. I then found the problem, fixed it, committed and merged `bugfix-333` into `staging` branch. I then realised that I'd left the `var_dump();` in the code so i checked out the `bugfix-333` again and deleted the `var_dump()` I again committed the code this time using `git commit --amend` Then I checked out `staging` and merged `bugfix-333` again BUT ... the var_dump() is still there in staging? I checked out `bugfix-333` and the code is gone. I tried again, checked out `staging` and ran `git merge bugfix-333` but now I get: Already up to date. But it's not??? Is this a bug or a "feature"? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/74e1b44e-2cf7-4f90-96d3-80d2ef178570n%40googlegroups.com.
[git-users] Trying to decipher what happened to git history
I had an issue which I am not sure how I got there (code modified and then reverted in a later revision) As I am not 100% sure if it is expected behaviour by git or something else happened, I just wanted to see if anyone here could enlighten me? I branched out master (feature-1) and made some changes to file1.php I branched out master (feature-2 : without changes to file1.php merged back) and made some other changes to file1.php Eventually, I merged feature-1 back to master. Then I merged feature-2 back to master. It appears that the merge in feature-2 has reverted the changes in feature-1. Is that possible? I thought git would be able to handle that? Not sure how it could happen -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/0bfb0388-25d4-4728-99f4-7940c6f19725n%40googlegroups.com.
Re: [git-users] How to track changes to db
On Thursday, 6 August 2020 at 06:59:28 UTC+10 Magnus Therning wrote: > > SJW writes: > > > I'm not sure I understand exactly what it is you are talling about > > As I mentioned, I'm not sure I understand your question... anyway, it > might be worthwhile looking into migrations since it sounds like you're > doing a lot of manual changes to DB schemas and trying to keep track of > them. > Example. I developed integration with a cloud storage service. I created a txt file for this feature and in it contained: 1. Instructions on how to generate the API key required to communicate with the cloud server 2. The new database tables created in dev that need to be replicated in staging and production 3. Limitations of the integration that may need to be addressed in the future. > > Here's what looks like a decent introduction to database migrations: > https://rollout.io/blog/database-migration/ > > I'm sure there's a library to do that in whatever language you are > comfortable with. Some examples: > > - Python: https://pypi.org/project/yoyo-migrations/ > - Ruby: https://github.com/winebarrel/ridgepole > - Java: https://github.com/liquibase/liquibase > - Go: https://github.com/golang-migrate/migrate > > and there are command line tools for it as well > > - https://github.com/golang-migrate/migrate > - https://github.com/aphel-bilisim-hizmetleri/pg-migrator > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: > twitter: magthe http://magnus.therning.org/ > > Reality is that which, when you stop believing in it, doesn't go away. > — Philip K. Dick > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/ef8ffcca-0e35-47aa-9fb9-fe7de0f28d75n%40googlegroups.com.
Re: [git-users] How to track changes to db
On Wednesday, 5 August 2020 at 23:15:49 UTC+10 rhkr...@gmail.com wrote: > On Tuesday, August 04, 2020 10:34:59 PM SJW wrote: > > I am trying to find a good way to track changes to the db but havn't got > it > > down pat yet. > > > > What I am doing > > > > ``` > > git branch feature > > git checkout feature > > ``` > > > > modify code and add/modify database tables > > ... > > create a txt file called feature.txt and list changes. e.g. DB ALTER > > statements etc. that I need to apply to staging and production db's > > Interesting puzzle ;-) > > Do you create one file named feature.txt, or do you create a different > file for > each feature with a unique name? > > (I'm trying to understand "all these text files" from below.) > > One thing I'd consider is just having one file named feature.txt, or > notes.txt > and modify that as appropriate and commit it with each change. > > Then when you checkout a feature branch, you get the notes (DB ALTER > statements) associated with that feature, and it stays associated with > that > feature branch. > > You could choose another name for the text file, perhaps: db_alter.txt > > I have a different file for each feature - problem is, when I merge the feature and delete the branch, the notes get merged so if I have 5 feature branchs, I end up with 5 rogue feature.txt files I started with just database.sql and I would export the structure on each environment and then just compare but when I started using git push, the compare became redundant > > > ... > > > > ``` > > git add . > > git commit -m "Message" > > git checkout staging > > git merge feature > > git checkout master > > git merge feature > > ``` > > > > Problem I have is that I have all these txt files that are just notes so > I > > delete them but they keep reappearing ( because I merged them into > master > > and then create new branch etc. ) > > > > I found this was a bit annoying so I stopped adding and committing the > txt > > files but now I have these txt files sitting in the unstaged changes > area > > of all projects - not a great idea either. > > > > Any suggestions on how to better manage these notes and somehow ensure > they > > remain linked to each feature branch? > > > > Thanks > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/dd9db861-ad67-4609-a9f3-7057cbc3afd1n%40googlegroups.com.
Re: [git-users] How to track changes to db
>> Can you please explain whet do you want to do with the feature.txt files? Do you want to versioncontol them or not at all or just separate them but somehow link them together with the repo? what's the purpose of these files? They are my notes - things that need to be considered when the feature goes live. Things outside of php files or even just things to be aware of of. On Wednesday, 5 August 2020 at 21:14:24 UTC+10 alexa...@gmail.com wrote: > Hey, > > Can you please explain whet do you want to do with the feature.txt files? > Do you want to versioncontol them or not at all or just separate them but > somehow link them together with the repo? what's the purpose of these > files? > > Best, > s > > On Wed, Aug 5, 2020, 13:02 SJW wrote: > >> I'm not sure I understand exactly what it is you are talling about >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/git-users/1b25b65b-a304-454f-a5e4-be08d6d1f506o%40googlegroups.com >> . >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/ae6791b9-1a9e-4826-91bc-03a1bc339f29n%40googlegroups.com.
Re: [git-users] How to track changes to db
I'm not sure I understand exactly what it is you are talling about -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/1b25b65b-a304-454f-a5e4-be08d6d1f506o%40googlegroups.com.
[git-users] How to track changes to db
I am trying to find a good way to track changes to the db but havn't got it down pat yet. What I am doing ``` git branch feature git checkout feature ``` modify code and add/modify database tables ... create a txt file called feature.txt and list changes. e.g. DB ALTER statements etc. that I need to apply to staging and production db's ... ``` git add . git commit -m "Message" git checkout staging git merge feature git checkout master git merge feature ``` Problem I have is that I have all these txt files that are just notes so I delete them but they keep reappearing ( because I merged them into master and then create new branch etc. ) I found this was a bit annoying so I stopped adding and committing the txt files but now I have these txt files sitting in the unstaged changes area of all projects - not a great idea either. Any suggestions on how to better manage these notes and somehow ensure they remain linked to each feature branch? Thanks -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/993de659-6727-4627-994c-0ee89e33e1d9n%40googlegroups.com.
Re: [git-users] Screwed up merge - wrong branch - now I'm lost
Thanks @Michael... When I was reading your reply, I was re-reading my quoted message ... and when I re-read "Updating b8a0e45..834dc62" I had a lights-on moment... That is the from *commit-id* and the to *commit-id* - I can use that... Much easier the next day after a good nights sleep - in the heat of the moment, when all that is running through head is "Oh Sh**... F*** , F***, F***, F***, F***" ... not so simple to comprehend as a beginner... Thanks On Saturday, 25 July 2020 at 10:43:27 UTC+10 Michael Gersten wrote: > > On 2020-07-24, at 1:26 AM, SJW wrote: > > > $ git checkout master > Switched to branch 'master' > > $ git merge staging > Updating b8a0e45..834dc62 > Fast-forward > > 23 files changed, 816 insertions(+), 550 deletions(-) > > ... lots of changes... Too many ... Oops! I meant to merge payments... > Wrong branch! > > > So if I understand correctly, you want to rewind "master" back to > "b8a0e45", and then re-merge payments? > > That should be > > git checkout master > git reset --hard b8a0e45 > git merge payments > > This is assuming no pushes or other other-person usage of your repository > since the oopsie. > > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/343665aa-0b8f-47fd-9ce4-204e875b6358n%40googlegroups.com.
[git-users] Screwed up merge - wrong branch - now I'm lost
1. master - stable base code
2. staging - code published on staging currently being tested
3. payments - a feature branch I was developing on.
I was working on some final touches to payments:
$ git add classes/class.payment.invoice.php invoice-prepare.php
$ git commit -m 'Added rand query string to logo to override caching'
[payments 906f797] Added rand query string to dealer logo to override
caching
2 files changed, 2 insertions(+), 2 deletions(-)
$ git checkout staging
Switched to branch 'staging'
# git merge payments
Merge made by the 'recursive' strategy.
classes/class.payment.invoice.php | 2 +-
invoice-prepare.php | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
$ git checkout master
Switched to branch 'master'
$ git merge staging
Updating b8a0e45..834dc62
Fast-forward
23 files changed, 816 insertions(+), 550 deletions(-)
... lots of changes... Too many ... Oops! I meant to merge payments...
Wrong branch!
So, I googled frantically and found this:
https://mijingo.com/blog/reverting-a-git-merge
and based on that, I tried to revert:
$ git revert HEAD
error: commit 834dc629a41cd762eda30a5ffa9df7b57471d770 is a merge but no -m
option was given.
fatal: revert failed
... Didn't work... So based on error I tried
$ git revert -m 1 834dc629a41cd762eda30a5ffa9df7b57471d770
[master b416de4] Revert "Merge branch 'payments' into staging"
2 files changed, 2 insertions(+), 2 deletions(-)
... That doesn't sound right - there were 23 file changes ...
Still on master - I try the correct merge now:
$ git merge payments
Already up to date.
Then I compared files with staging and they were identical and I can see
that the last 2 changes I made to payments were not in master ... It is
clear that master was not reverted and I reverted the payments commit ...
Now I am screwed and dont know how to get master back to the state it was
in prior to the bad merge...
$ git reflog
b416de4 (HEAD -> master) HEAD@{0}: checkout: moving from staging to master
834dc62 (staging/staging, staging) HEAD@{1}: checkout: moving from master
to staging
b416de4 (HEAD -> master) HEAD@{2}: checkout: moving from payments to master
906f797 (origin/payments, payments) HEAD@{3}: checkout: moving from master
to payments
b416de4 (HEAD -> master) HEAD@{4}: revert: Revert "Merge branch 'payments'
into staging"
834dc62 (staging/staging, staging) HEAD@{5}: merge staging: Fast-forward
b8a0e45 HEAD@{6}: checkout: moving from staging to master
834dc62 (staging/staging, staging) HEAD@{7}: merge payments: Merge made by
the 'recursive' strategy.
eac6d7b HEAD@{8}: checkout: moving from payments to staging
906f797 (origin/payments, payments) HEAD@{9}: commit: Added rand query
string to dealer logo to override caching
66b3e0b HEAD@{10}: checkout: moving from master to payments
It says "revert" - but I dont think it reverted what I wanted...
Help? How do I regain my sanity? (and my code)
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/387bf4ed-c8f2-404f-b0fe-2fc1aaa70dd4n%40googlegroups.com.
Re: [git-users] Trying to get git to play with a remote bare repo
>> Please refrain from such whining. >> First, is that you're venting on a communication venue which is used by >> unpaid folks to help other folks solve their problems with using Git. Please refrain from whining? And then you go on to whine about my post ... pot meet the kettle. I didn't even bother reading the rest because I'm not interested in anything else you have to say now. Have a good life -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/c9b9ad9b-100f-43c1-97b1-2fbbe89bcd7bo%40googlegroups.com.
[git-users] Trying to get git to play with a remote bare repo
I set up a remote git repo on my server for staging. Added a remote on local Created a new branch 'staging' Went to push staging repo to staging remote and got: remote: fatal: You are on a branch yet to be born So I googled and got the solution - I connected to the remote server and changed the HEAD to the 'staging' branch Then I tried to push again: git push staging staging Everything up-to-date .. No it's not ... So I try to force: git push -f staging staging Everything up-to-date .. No it's not ... Git is harder than actually programming -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/38ba0cbd-8989-489b-bc97-3419c752a549o%40googlegroups.com.
Re: [git-users] How to effectively use git
Getting QA Involved. Do you have a guide or process I could use to get QA involved? I've been thinking about this ... If they could go to GitLab and "deploy" a branch to staging for testing then that would work. Each time they test - go to GitLab -> select branch -> somehow deploy to stating server On Thursday, 9 July 2020 07:15:40 UTC+10, Magnus Therning wrote: > > > SJW > writes: > > > On Monday, 6 July 2020 22:22:49 UTC+10, Magnus Therning wrote: > >> > >> > >> SJW > writes: > >> > >> > I am still trying to get my head around the best possible way to use > git > >> > (and failing) > >> > > >> > Here is my normal process below - but I don't like it because it is > very > >> > difficult to manage repos and versions. Hoping someone can read this > and > >> > advise me on improvements or tell me that this is just how git > works... > >> > > >> > Code bases: > >> > - DEV (local PC - this is where local git repo is configured - and > >> origin > >> > is GitLab) > >> > - STAGING (server - I have a local folder synced with server) > >> > - LIVE (server - I have a local folder synced with server) > >> > > >> > Effectively I have 3 local folders with 3 codebases (STAGING and LIVE > >> are > >> > just syncd to server) > >> > > >> > 1. I create a branch - *new-branch-1* > >> > 2. I develop new branch > >> > 3. I use WinMerge to sync DEV changes with STAGING > >> > 4. I submit changes in *new-branch-1* to QA team to review and > approve > >> > > >> > 5. I create a branch - *new-branch-2* > >> > 6. Make more changes for a separate task/project > >> > 7. I use WinMerge to sync DEV changes with STAGING > >> > > >> > *ISSUE#1*: STAGING has all changes from *new-branch-1* so there are > lots > >> of > >> > files showing that I need to manually filter through and ignore and > try > >> and > >> > find the specific changes from new-branch-2 > >> > > >> > 8. I submit changes in *new-branch-2* to QA team to review and > approve - > >> We > >> > now have both branches in STAGING > >> > > >> > 9. QA come back with some changes or improvements for *new-branch-1* > >> > 10 I checkout *new-branch-1* and update the code with the > >> recommendations > >> > from QA > >> > 11. I use WinMerge to sync DEV changes with STAGING > >> > > >> > *ISSUE#2*: Same as issue#1 now I need to manually filter out the > changes > >> > from new-branch-2 > >> > > >> > 12. Repeat with *new-branch-3* - Meanwhile, someone else has added > >> > *new-branch-4* and *new-branch-5* to staging > >> > > >> > *ISSUE#3*: Now I am trying to sync DEV and STAGING with 5 code > branches > >> - > >> > it's starting to become very difficult to identify branch specific > code > >> in > >> > STAGING > >> > > >> > 13. QA approves *new-branch-2 *- I merge *new-branch-2* back to > master > >> > 14. Compare master with LIVE and update the LIVE code with all the > >> changes > >> > > >> > It just becomes very confusing and overwhelming when you start > getting > >> lots > >> > of branches so I end up halting development and waiting for QA but > this > >> is > >> > inefficient and slows development. > >> > Does anyone have any suggestions on how I can streamline this to > avoid > >> > delays in development? > >> > >> I think you've put your finger on the issue, QA is too slow. You can do > >> manner of fixes to tools and processes, but you'll always be hindered > by > >> QA being slow! > >> > >> A few things you can try in the meantime: > >> > >> - don't use git for deploy, instead use CI/CD > >> > > > > I did try that but wasn't comfortable having git update code without > > visually seeing the changes it was making - not that comfortable or > > trustworthy yet > > Maybe we're talking past each other, but I'm saying /don't use git for > deploy/. Use `git archive` to get the latest version on a branch into a > ZIP archive (or .tar.gz, or whatever) and then use some way of deploying > t
Re: [git-users] How to effectively use git
On Monday, 6 July 2020 22:22:49 UTC+10, Magnus Therning wrote: > > > SJW > writes: > > > I am still trying to get my head around the best possible way to use git > > (and failing) > > > > Here is my normal process below - but I don't like it because it is very > > difficult to manage repos and versions. Hoping someone can read this and > > advise me on improvements or tell me that this is just how git works... > > > > Code bases: > > - DEV (local PC - this is where local git repo is configured - and > origin > > is GitLab) > > - STAGING (server - I have a local folder synced with server) > > - LIVE (server - I have a local folder synced with server) > > > > Effectively I have 3 local folders with 3 codebases (STAGING and LIVE > are > > just syncd to server) > > > > 1. I create a branch - *new-branch-1* > > 2. I develop new branch > > 3. I use WinMerge to sync DEV changes with STAGING > > 4. I submit changes in *new-branch-1* to QA team to review and approve > > > > 5. I create a branch - *new-branch-2* > > 6. Make more changes for a separate task/project > > 7. I use WinMerge to sync DEV changes with STAGING > > > > *ISSUE#1*: STAGING has all changes from *new-branch-1* so there are lots > of > > files showing that I need to manually filter through and ignore and try > and > > find the specific changes from new-branch-2 > > > > 8. I submit changes in *new-branch-2* to QA team to review and approve - > We > > now have both branches in STAGING > > > > 9. QA come back with some changes or improvements for *new-branch-1* > > 10 I checkout *new-branch-1* and update the code with the > recommendations > > from QA > > 11. I use WinMerge to sync DEV changes with STAGING > > > > *ISSUE#2*: Same as issue#1 now I need to manually filter out the changes > > from new-branch-2 > > > > 12. Repeat with *new-branch-3* - Meanwhile, someone else has added > > *new-branch-4* and *new-branch-5* to staging > > > > *ISSUE#3*: Now I am trying to sync DEV and STAGING with 5 code branches > - > > it's starting to become very difficult to identify branch specific code > in > > STAGING > > > > 13. QA approves *new-branch-2 *- I merge *new-branch-2* back to master > > 14. Compare master with LIVE and update the LIVE code with all the > changes > > > > It just becomes very confusing and overwhelming when you start getting > lots > > of branches so I end up halting development and waiting for QA but this > is > > inefficient and slows development. > > Does anyone have any suggestions on how I can streamline this to avoid > > delays in development? > > I think you've put your finger on the issue, QA is too slow. You can do > manner of fixes to tools and processes, but you'll always be hindered by > QA being slow! > > A few things you can try in the meantime: > > - don't use git for deploy, instead use CI/CD > I did try that but wasn't comfortable having git update code without visually seeing the changes it was making - not that comfortable or trustworthy yet > - spin up one staging for each branch you develop on > That seems like a lot of effort for each branch. Would probably be ideal but ... > > In the end I think the only long-term solution is if QA is folded into > development, i.e. that you move the organisation to cross-functional > teams, including QA. > Cant see it happening - there is 4 of us - 2 separate companies doing this as a side project - so I get 1-2 days from them per week > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: mag...@therning.org > twitter: magthe http://magnus.therning.org/ > > You can't depend on your judgement when your imagination is out of focus. > — Mark Twain > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/73ec6d96-d619-4ec2-ac5c-d5e79bea7ef4o%40googlegroups.com.
[git-users] Re: How to effectively use git
On Monday, 6 July 2020 22:17:45 UTC+10, Philip Oakley wrote: > > This is some 20,000ft observations about how conflicting mental models and > processes may be causing trouble. > > A thought in the background: it's generally considered poor practice to > think of Git as a deployment system, so one has to be careful at the final > step of deployment that only the deployable files are actually deployed, > rather than having a full public-facing git repo available for cloning > (along with all the in development branches and ones with secret keys etc > etc). So that final step could be the pure sync of the checked out branch > alone. > > Elsewhere it sounds like you are not using the power of Git to keep you > branches separate right through the QA/Test process. In steps 7 & 11 you > say you are WinMerging part of your work into an *uncontrolled* folder > (if it was controlled & versioned it would use a git command!!). > Wanted to eventually get tot this but dont have enough experience or trust in git to allow it to modify the code without letting me see it. Preferred manual so I knew exactly what was going on. TBH - I have really struggled with git and am probably a long, long way off automating deployment. > > It maybe that the QA/Test haven't yet got the same mental model about how > the git checkout removes automatically any old or outdated files (like an > old fashioned slide viewer doing a 2-card trick), and swaps in the correct > files for the checkout. It's likely that you haven't trained the QA/TEST > folks how to add markup and commit their comments so that they are part of > the repo, such that the checkout happens cleanly (as opposed to say the > folder is dirty because their comments are hanging > unresolved/uncommitted...) It maybe that you get them to create a branch > *new-branch-1-QA* from the tip of your branch to add all that > 'crap^WCommentary' that you need to resolve the issues on *new-branch-1* > QA have never touched or even heard of git. So you're right, they definitely don't have the "same mental model". TBH I dont trust git so definitely wouldn't feel comfortable with them checking code in and out. > > *Use git all the way until the final deployment*. Don't let any issues > happen because you aren't using the tool's (Git) strengths (cheap easy > branching!). Avoid mixing tools (hammers, screwdrivers vs screws and nails) > Would love to be in a position where I trust git enough to be able to do this. > > Philip > > On Monday, July 6, 2020 at 2:28:01 AM UTC+1, SJW wrote: >> >> I am still trying to get my head around the best possible way to use git >> (and failing) >> >> Here is my normal process below - but I don't like it because it is very >> difficult to manage repos and versions. Hoping someone can read this and >> advise me on improvements or tell me that this is just how git works... >> >> Code bases: >> - DEV (local PC - this is where local git repo is configured - and origin >> is GitLab) >> - STAGING (server - I have a local folder synced with server) >> - LIVE (server - I have a local folder synced with server) >> >> Effectively I have 3 local folders with 3 codebases (STAGING and LIVE are >> just syncd to server) >> >> 1. I create a branch - *new-branch-1* >> 2. I develop new branch >> 3. I use WinMerge to sync DEV changes with STAGING >> 4. I submit changes in *new-branch-1* to QA team to review and approve >> >> 5. I create a branch - *new-branch-2* >> 6. Make more changes for a separate task/project >> 7. I use WinMerge to sync DEV changes with STAGING >> >> *ISSUE#1*: STAGING has all changes from *new-branch-1* so there are lots >> of files showing that I need to manually filter through and ignore and try >> and find the specific changes from new-branch-2 >> >> 8. I submit changes in *new-branch-2* to QA team to review and approve - >> We now have both branches in STAGING >> >> 9. QA come back with some changes or improvements for *new-branch-1* >> 10 I checkout *new-branch-1* and update the code with the >> recommendations from QA >> 11. I use WinMerge to sync DEV changes with STAGING >> >> *ISSUE#2*: Same as issue#1 now I need to manually filter out the changes >> from new-branch-2 >> >> 12. Repeat with *new-branch-3* - Meanwhile, someone else has added >> *new-branch-4* and *new-branch-5* to staging >> >> *ISSUE#3*: Now I am trying to sync DEV and STAGING with 5 code branches >> - it's starting to become very difficult to identify branch specific code >> in STAGING >> >> 13. QA
[git-users] How to effectively use git
I am still trying to get my head around the best possible way to use git (and failing) Here is my normal process below - but I don't like it because it is very difficult to manage repos and versions. Hoping someone can read this and advise me on improvements or tell me that this is just how git works... Code bases: - DEV (local PC - this is where local git repo is configured - and origin is GitLab) - STAGING (server - I have a local folder synced with server) - LIVE (server - I have a local folder synced with server) Effectively I have 3 local folders with 3 codebases (STAGING and LIVE are just syncd to server) 1. I create a branch - *new-branch-1* 2. I develop new branch 3. I use WinMerge to sync DEV changes with STAGING 4. I submit changes in *new-branch-1* to QA team to review and approve 5. I create a branch - *new-branch-2* 6. Make more changes for a separate task/project 7. I use WinMerge to sync DEV changes with STAGING *ISSUE#1*: STAGING has all changes from *new-branch-1* so there are lots of files showing that I need to manually filter through and ignore and try and find the specific changes from new-branch-2 8. I submit changes in *new-branch-2* to QA team to review and approve - We now have both branches in STAGING 9. QA come back with some changes or improvements for *new-branch-1* 10 I checkout *new-branch-1* and update the code with the recommendations from QA 11. I use WinMerge to sync DEV changes with STAGING *ISSUE#2*: Same as issue#1 now I need to manually filter out the changes from new-branch-2 12. Repeat with *new-branch-3* - Meanwhile, someone else has added *new-branch-4* and *new-branch-5* to staging *ISSUE#3*: Now I am trying to sync DEV and STAGING with 5 code branches - it's starting to become very difficult to identify branch specific code in STAGING 13. QA approves *new-branch-2 *- I merge *new-branch-2* back to master 14. Compare master with LIVE and update the LIVE code with all the changes It just becomes very confusing and overwhelming when you start getting lots of branches so I end up halting development and waiting for QA but this is inefficient and slows development. Does anyone have any suggestions on how I can streamline this to avoid delays in development? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/09f67ad3-71bb-4bfa-8f4d-0c396897bcbbo%40googlegroups.com.
[git-users] Re: Git completely thrown a curveball now...
I think I know what happened now after analysis. I followed the message I received when I pushed the branch to origin: remote: remote: To create a merge request for payment-gateway, visit: remote: https://gitlab.com/SJW/absee/-/merge_requests/new?merge_request%5Bsource_branch%5D=aftersales remote: I then realised that I should do be doing it on local machine so I cancelled and deleted the merge request BUT, looking at the GitLab history, it shows in the merge history so I am guessing that this was the problem... I found that it was only the one line that didn't get included which was the last change I made which lead me to the above assumption. So I manually added it to master an moved on On Monday, 18 May 2020 18:28:56 UTC+10, Philip Oakley wrote: > > Which way did you merge? did you merge the what was in master into > aftersales, or the other way around? > > Have you used a repository viewer like gitk which will show where the two > branches are pointing to and the changes that each commit / merge has? > > Can you show a small extract of you difficultly, such as a diff of one > erroneous file between master and aftersales, with a description of why it > is 'wrong'. > > > P. > > On Monday, May 18, 2020 at 3:06:04 AM UTC+1, SJW wrote: >> >> I have my `master` >> >> I created a branch `aftersales` >> >> Today I finalised `aftersales` and commenced a merge. There were a few >> conflicts which I worked through and fixed, committed and finished merge. >> >> When I published to my staging server, it wasn't working so I went back >> and checked the code... A part of the code was missing... So I checked out >> `aftersales` again to find out what happened... >> >> I checked and the code was there in the `aftersales` branch... I went >> back to `master` and the code wasn't there... How could this be? I merged a >> branch and there was code sitting on the branch but not in the `master` >> >> I tried to merge again ... >> >> $ git merge aftersales >> Already up-to-date. >> >> WTF? What do I do now? >> >> Biggest concern: How much other code was "ignored" in the merge... >> How do I get the code into master??? (Obviously I can make changes >> directly into master, copying the changes in but... I'm sure that is not >> the intended git process???) >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/67d1c241-848a-4713-941b-e3faf1df4df5%40googlegroups.com.
[git-users] Git completely thrown a curveball now...
I have my `master` I created a branch `aftersales` Today I finalised `aftersales` and commenced a merge. There were a few conflicts which I worked through and fixed, committed and finished merge. When I published to my staging server, it wasn't working so I went back and checked the code... A part of the code was missing... So I checked out `aftersales` again to find out what happened... I checked and the code was there in the `aftersales` branch... I went back to `master` and the code wasn't there... How could this be? I merged a branch and there was code sitting on the branch but not in the `master` I tried to merge again ... $ git merge aftersales Already up-to-date. WTF? What do I do now? Biggest concern: How much other code was "ignored" in the merge... How do I get the code into master??? (Obviously I can make changes directly into master, copying the changes in but... I'm sure that is not the intended git process???) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/f1c7946f-bd57-4f5f-a427-5e40097aa72b%40googlegroups.com.
Re: [git-users] Git workflow recommendations
On Thursday, 14 May 2020 15:54:31 UTC+10, Magnus Therning wrote: > > > SJW > writes: > > > New to Git and I'm using a basic workflow that I'm not sure is that good > so > > wanted to post it here for feedback, critique and suggestions if > possible. > > > > Dev = Local Win 7 PC > > Staging = Staging Server > > Production = Live Site > > > >1. Develop on a branch (new-feature) > >2. Add, Commit, Push to origin:GitLab > >3. Using WinMerge: Compare Dev Branch Code to Staging Code and > manually > >copy changes to local "staging" code > >4. FTP modified Staging files up to Staging server > >5. Dev on new branch (new-feature1) and do the same (steps 2-5) * > >6. Testing performed on branch (new-feature) and approved for > Production > >7. Merge approved branch (new-feature) into master > >8. Add, Commit, Push to origin:GitLab > >9. Using WinMerge: Compare Dev master to Production Code manually and > >copy changes to local "Production" code > >10. FTP modified Production files up to Production server > >11. Delete branch > > > > * This is where comparison is not great - because new branch doesn't > have > > previous branch changes and thus is highlighted in WinMerge as different > > files (and therefore, I need to check through and make sure changes are > > related to current branch and merge into Staging files). This can > sometimes > > be 3-4 different branches if Testing is slow and regularly, branch 4 > will > > be approved before branch 1. > > > > I think the issue at point 5 is what has me thinking this is not the > best > > way. > > Also, I don't know how to incorporate hot-fixes - I normally just make > > these changes straight to master > > > > I tried adding a remote for staging and production but of course - this > > didn't work because pushing changes to staging will remove the previous > > branch changes allowing for testing of only on branch at a time. > > I'd consider using two branches and then say that > > - `master` is what's deployed to staging > - `production` is what's deployd to production > > Then > > - skip step 3, you already know what should be in staging, it's what's > on `master` > - modify step 4 and use `git archive master` to get an archive of what > should be deployd, get that into staging somehow (I'd prefer `rsync`) > - skip steps 6-11, instead run tests agains `master` (what's in staging) > and when you are happy, fast-forward `production` branch to match > `master`, and > - deploy `production` in the same way you deployd to staging > > The next step after that would be to set up Gitlab CI so deploys to > staging happens automatically on merges/pushes to `master` and to > production on pushes to `production`. > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: mag...@therning.org > twitter: magthe http://magnus.therning.org/ > > It is better to keep your mouth shut and appear stupid than to open it > and remove all doubt. > — Mark Twain > I'm going to try this approach and see how I go. The only hurdle I can see is comparing master to production - If there are 4 branches merged into master that aren't in production yet and only 1 of those branches is approved for production, how do I merge only "some" of the master branch? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/4f6daddb-18bb-4a7a-a3db-c64ef5643b1a%40googlegroups.com.
[git-users] Git workflow recommendations
New to Git and I'm using a basic workflow that I'm not sure is that good so wanted to post it here for feedback, critique and suggestions if possible. Dev = Local Win 7 PC Staging = Staging Server Production = Live Site 1. Develop on a branch (new-feature) 2. Add, Commit, Push to origin:GitLab 3. Using WinMerge: Compare Dev Branch Code to Staging Code and manually copy changes to local "staging" code 4. FTP modified Staging files up to Staging server 5. Dev on new branch (new-feature1) and do the same (steps 2-5) * 6. Testing performed on branch (new-feature) and approved for Production 7. Merge approved branch (new-feature) into master 8. Add, Commit, Push to origin:GitLab 9. Using WinMerge: Compare Dev master to Production Code manually and copy changes to local "Production" code 10. FTP modified Production files up to Production server 11. Delete branch * This is where comparison is not great - because new branch doesn't have previous branch changes and thus is highlighted in WinMerge as different files (and therefore, I need to check through and make sure changes are related to current branch and merge into Staging files). This can sometimes be 3-4 different branches if Testing is slow and regularly, branch 4 will be approved before branch 1. I think the issue at point 5 is what has me thinking this is not the best way. Also, I don't know how to incorporate hot-fixes - I normally just make these changes straight to master I tried adding a remote for staging and production but of course - this didn't work because pushing changes to staging will remove the previous branch changes allowing for testing of only on branch at a time. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/498e2275-2592-4dbc-9c8a-eedecf13c102%40googlegroups.com.
[git-users] Re: How to make git work!
Thanks Philip. I have that mental model right. I get that bit, and for the most part, I can make basic updates and copy them to the server. I even incorporated my stating server as another remote where I would push to when something was ready for viewing but I didn't like the process and didn't think it fit the right process. I think all I wanted to do was not have a whole commit dedicated to removing a few comments - it really was a part of the same commit - just after the fact... Yes, forcing it sounds like what I should be doing. >From my understanding, it updated and committed locally without any issue - it just refused to do the same to the server. In the grand scheme of things - it probably doesn't matter but from a cleanliness point of view, I'd prefer to not have to commit comment changes... -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/0f85c399-ff94-4b92-a351-c16928e1541d%40googlegroups.com.
[git-users] Re: How to make git work!
Cant edit post. Here is the commit log - i was expecting/hoping for a single commit - instead I have 4 $ git log commit 0988bf8f5a165a6e213982cfcf0733ccb3452101 Author: XXX Date: Tue May 5 12:00:28 2020 +1000 Trying to fix the merge issues that were created from commit a32b8a94f3baef1264e7f17993fe79063a057736 Merge: 54c1612 0cc8698 Author: XXX Date: Tue May 5 11:28:58 2020 +1000 Merge branch 'master' of https://gitlab.com/SJWGL/project commit 54c1612be8c645fb14ca456bb56fa7b1979db9c7 Author: XXX Date: Tue May 5 10:16:30 2020 +1000 Updates... commit 0cc8698b634303b68e8a8568af503ed7576e3cc2 Author: XXX Date: Tue May 5 10:16:30 2020 +1000 Updates... -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/fadba795-f121-40bc-ae31-159975be4aee%40googlegroups.com.
[git-users] How to make git work!
git is doing my head in. I started using it thinking it would help but it
just seems to add extra time and headache to projects that wasn't there
before. Almost every time I try to update a repo, I get an error that
confueses the hell out of me... I have come to the conclusion that I am
clearly too stupid to use git but thought I would post here before writing
it off forever.
All I know of git is what I've learnt on YouTube videos.
Today I added 5-6 files that I had edited into the master branch
git add .
Then I committed and pushed to origin
git commit -m 'Updates...'
[master 0cc8698] Updates...
7 files changed, 673 insertions(+), 334 deletions(-)
create mode 100644 classes/class.email.php
git push origin master
Counting objects: 12, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (12/12), done.
Writing objects: 100% (12/12), 3.54 KiB | 0 bytes/s, done.
Total 12 (delta 10), reused 0 (delta 0)
To https://gitlab.com/SJWGL/project.git
9837efd..0cc8698 master -> master
Then, as I was closing all the files, I noticed some comments I had left in
a couple of files and wanted to just clean up which I did.
$ git status
On branch master
Changes not staged for commit:
(use "git add ..." to update what will be committed)
(use "git checkout -- ..." to discard changes in working directory)
modified: api/process.booking.php
modified: classes/class.logger.php
modified: configuration.php
no changes added to commit (use "git add" and/or "git commit -a")
I then tried to add the small changes to the previous commit as they dont
need their own commit.
$ git add .
$ git commit --amend
[master 54c1612] Updates...
Date: Tue May 5 10:16:30 2020 +1000
9 files changed, 681 insertions(+), 340 deletions(-)
create mode 100644 classes/class.email.php
$ git push origin master
To https://gitlab.com/SJWGL/project.git
! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 'https://gitlab.com/SJWGL/project.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
So I follow the instructions:
$ git pull origin master
>From https://gitlab.com/SJWGL/project
* branchmaster -> FETCH_HEAD
Auto-merging api/process.booking.php
CONFLICT (content): Merge conflict in api/process.booking.php
Automatic merge failed; fix conflicts and then commit the result.
Then I fumble my way through just to try and get the file into repo but
obviously there is a problem that I dont know how to manage...
$ git diff
diff --cc api/process.booking.php
index efd3e11,9e9eed8..000
--- a/api/process.booking.php
+++ b/api/process.booking.php
@@@ -79,7 -79,6 +79,10 @@@ else
endif;
++<<< HEAD
+// If no errors, send email
++===
++>>> 0cc8698b634303b68e8a8568af503ed7576e3cc2
if ($sendEmail) {
$email = new Email();
$email->setBookingData($booking->getBookingData());
$ git push origin master
To https://gitlab.com/SJWGL/project.git
! [rejected]master -> master (non-fast-forward)
error: failed to push some refs to 'https://gitlab.com/SJWGL/project.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
$ git status
On branch master
You have unmerged paths.
(fix conflicts and run "git commit")
(use "git merge --abort" to abort the merge)
Unmerged paths:
(use "git add ..." to mark resolution)
both modified: api/process.booking.php
no changes added to commit (use "git add" and/or "git commit -a")
$ git add .
$ git commit --amend
fatal: You are in the middle of a merge -- cannot amend.
$ git commit
[master a32b8a9] Merge branch 'master' of https://gitlab.com/SJWGL/project
$ git push origin master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (11/11), done.
Writing objects: 100% (11/11), 1.20 KiB | 0 bytes/s, done.
Total 11 (delta 9), reused 0 (delta 0)
To https://gitlab.com/SJWGL/project.git
0cc8698..a32b8a9 master -> master
I dont know that the f**k I'm doing???
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/13182e6f-3328-491a-aa44-1da01ff29cc2%40googlegroups.com.
[git-users] Re: Git keeps getting out of sync and I cant figure it out
Ok, I just went ahead and did a pull... It shows me the changes... I realised that on Friday I modified the README.md... It's way too hard to keep up... I think git is too complicated for me... thanks anyway On Monday, 27 April 2020 12:48:22 UTC+10, SJW wrote: > > I keep trying to learn and use git but I keep screwing up my work - > overwriting changes and creating duplicate efforts. > > I made some changes today, but was on the wrong branch - when trying to > change branch I screwed up > I made the changes again and then tried to push to master and I get this: > > $ git push origin master > To https://gitlab.com/SJWGitLab/absee.net.au.git > ! [rejected]master -> master (non-fast-forward) > error: failed to push some refs to ' > https://gitlab.com/SJWGitLab/absee.net.au.git' > hint: Updates were rejected because the tip of your current branch is > behind > hint: its remote counterpart. Integrate the remote changes (e.g. > hint: 'git pull ...') before pushing again. > hint: See the 'Note about fast-forwards' in 'git push --help' for details. > > > It says do a git pull BUT, my understanding is that doing a pull will > overwrite my code with the origin and delete my recent changes. > > I did a git diff but it gave me nothing... I dont want the origin to be > the master - my local is the master... > > I'm having a real hard time with git and dont understand how it is so > popular - it has added an extra layer of complexity and confusion on top of > managing code that is creating so much rework and recoding... What am I > missing? > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/1d3bbbca-ee74-4239-a1b9-0d188859a894%40googlegroups.com.
[git-users] Git keeps getting out of sync and I cant figure it out
I keep trying to learn and use git but I keep screwing up my work - overwriting changes and creating duplicate efforts. I made some changes today, but was on the wrong branch - when trying to change branch I screwed up I made the changes again and then tried to push to master and I get this: $ git push origin master To https://gitlab.com/SJWGitLab/absee.net.au.git ! [rejected]master -> master (non-fast-forward) error: failed to push some refs to 'https://gitlab.com/SJWGitLab/absee.net.au.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Integrate the remote changes (e.g. hint: 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. It says do a git pull BUT, my understanding is that doing a pull will overwrite my code with the origin and delete my recent changes. I did a git diff but it gave me nothing... I dont want the origin to be the master - my local is the master... I'm having a real hard time with git and dont understand how it is so popular - it has added an extra layer of complexity and confusion on top of managing code that is creating so much rework and recoding... What am I missing? -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/fcab0336-1174-44f7-955b-cd7ce84608e3%40googlegroups.com.
[git-users] Deploying git master to a live server
I am a beginner and have successfully setup git to track code, push to origin (gitlab) and push to my live server (a replicated version for testing) In my replicated version, I created a brand new empty subdomain then configured git to push to live [git push live master] and it worked perfectly - my entire website got pushed up and was working perfectly based on my tests. Now, I want to integrate this into my actual live server working domain. My question is - is this as easy as the replicated setup I configured? Given the replicated subdomain was empty, it meant that the push made both repositories identical and synced. On the live site, there are a few directories and files which are NOT part of the repo (/backup, /wp, etc.) Will this cause problems? The live server will have extra files and folders that aren't in the repo - is this going to make the live server return errors (e.g. out of sync) or will it try and add them? Or can I just push and we're golden? I am hesitant to just switch over because I dont want to break the live site and want to make sure I cover all possible bases... -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/8a8fb896-ae7e-451f-a743-8176176ef1cf%40googlegroups.com.
