Git for when shit happens

Do you know those things you don't know exist until you need them, or don't you know you need them until you learn?

Well, these are the things I’m going to talk about in this article, if you’ve been in trouble in the life of a programmer and got help, you know the value of the almost anonymous friend of the community or the ** StackOverflow **, or even the support of your colleague on the side, you have your growth… Anyway, I'm here to try to be that friend in times of anguish today, I was inspired by several requests for help from co-workers and friends from the programming world to write this article, to help you when * it sucks at Git *.

Affs, the solution is nothing like that

$ git checkout -- .

This discards everything you've done so far and hasn't committed.

I want to merge just that, not everything from branch!

Use:

$ git cherry-pick hash_do_commit

When you're checked at the branch you want to send to.

But WARNING this will be like a new commit on the branch, not a merge.

I even sent what I shouldn't have…

Starting with the first mistake that is usually made, sending a generated file, a library, or something like that, and saying "puts, that was to be ignored", but then you go all happy in the .gitignore and put a line with * .exe (assuming it is an executable), then you will notice that if it is generated again, git will continue versioning, then you might think, did I not ask this train to be ignored?

Well, what happens is that once added Git will continue versioning until you delete this file and push this deletion, thus solving this problem.

I forgot to send something at the last commit, now what?

When you forget to add a file or modification to the last commit and you don't want to mess up the thank you with a comment like "fix: stop I forgot to send" you can simply give the following command:

$ git add forgotten_filename

$ git commit --amend --no-edit

Then it will add the guy you forgot in the last commit without having to edit the comment or make another commit.

I commit what I shouldn't have done, now what?

This is one of the shit breakers that I like the most, because it seems like time travel to correct shits from the past, when you look at your commit and say "gee, it wasn't supposed to commit that", in which case you can rewrite the local graph using command:

$ git reset --mixed HEAD ~ 1

This command will return the last commit to the unstaged phase, this will allow you to correct what you need and commit again as if the previous commit never happened.

But ATTENTION, here are two points that you need to note there are variations of this command, for example, instead of --mixed it is possible to use --soft to return the files to staged or --hard to disappear with them, another thing is that when the problem is a commit a little behind the others or you want to summarize several commits with a comment you can only use:

$ git reset --mixed hashõ_commit_anterior_ao_que_voce_quer

This will make you time travel on the project timeline at the time of that commit.

I pushed what I shouldn't have, and now?

This is basically the same problem as the previous topic, but more critical because you sent and broke the pipeline, in this case you only add to the commands previously taught:

$ git push -f

This will force sending the new graph.

Here you have other points of attention, as this will make you force the reconstruction of the last facts in the graph you need to pay attention to some things:

Make sure nobody committed in front of you, if you did, change your strategy.

Make sure this has not been released, that is, do not have a version tag at this time, because this procedure will make you lose that tag so that you can no longer use it unless you delete it.

Graphic without mess!

Always pull before the commit, this is for when you have more than one person working on the same branch, this will make you resolve possible conflicts and ensure your commit is up to date. If you don't, git will try to do it and the result is kind of weird to see.

Always rebase the branch where you are going to send it before the merge, if you do not do this, you will possibly have conflicts in the merge or it will be divided between 2 o merge at the end of the graph and your changes lost somewhere in the middle of it.

Separating monolithic repositories without losing history

This one is really cool, but I think it's the most difficult so I left it for last.

It works like this, assuming it is in a repository that has:

Server: Containing only back-end code;

ClientDesktop: Containing the app code for pc;

Web Client: Containing the web app code;

ClientMobile: Containing the code of the mobile app;

All in the same crazy cake, but you want to separate this, because this mess causes a lot of conflicts, errors in production, difficulty finding a change made, among other things, so the boss says "it's been like this since time immemorial and it works, so let it quiet, otherwise ... ", because show him that you are a beast!

Make a copy of the repository locally before you begin (just in case).

In your terminal, clone the repository that will be divided (For example, the Server):

$ git clone --no-hardlinks C: / Git / Server C: / Git / ServerClone

Run the git filter-branch command with the name of the folder you want to transform into another repository (For example, WebClient):

$ git filter-branch --prune-empty --subdirectory-filter Web Client

Create on your Github or the repository manager of your choice a repository with the name you want, then change the remote URL of your repository (in my case ClientWeb):

$ git remote set-url origin http://github.com/ClienteWeb.git

Push your new repository:

$ git push

Note: Note that if you access the cloned repository (Clone Server) that the ClientWeb repository has been filtered and is now at the root and that all git history has been kept just for it.

Now repeat this process for all other repositories you want!

Conclusion

Last but not least, give preference to working with a pattern that works and has already been tested by the market, this will generally save you time and some hair, do not try to reinvent the wheel, to learn more about one of these patterns that I am talking take a look at this article on Gitflow.

If you have any more difficulties that you have overcome or that still have not found a solution speak here in the comments and we will try to solve them together.

If you made it this far, congratulations! Don't stop, go to the comments and/or next article and have fun.