We are a small team (2 Developers, 1 Graphist) working on android studio projects and we are using GitLab. The Thing is we found that classic approach of adding feature by Branching & then Merge request not ideal for our circumstance. We tend to make changes on a daily basis and do it fast.
My colleague told me about a workflow which he had used in past, it's something like : you lock the part of code you want to work on, then no one can change it even if they don't know you have locked it and by the time they try to add/edit/delete something that is locked, they can't, and when you are finished, you can unlock it and now others can make changes.
You can always directly push to your main branch (usually "master"), then there is no need to create branches. However, I strongly recommend to let the rest of the team review your changes before pushing them to "master". This means that you need to create branches and merge requests. It might seem inconvenient at first but maybe you just need the right workflow.
Instead of checking out short-lived branches all the time you can always stay on the same local Git branch, committing early and often, but only push "good" commits.
Let's say your local branch contains 10 commits.
Then you can use git rebase -i
(or the faster alternative git revise -i
) to reorder your branch so the "good" commits come first. Then you can use this command to push them to a new branch on GitLab, which allows you to create a merge request:
git push origin HEAD~4 refs/heads/the-new-branch
This is roughly the workflow described in this blog post
If you want to take this even further, I have written a tool (currently) called git-branchless, which allows you to do the same, but you can push an arbitrary number of branches with commits from your local branch, without having to restack commits before every push.
These workflows are called patch-stack workflows, they make it easy to extract reviewable chunks of changes from a local branch. Other systems like Phabricator and Gerrit are designed for that workflow, but as described above it also works with GitLab/GitHub.
Technically, you asked for an alternative to Git. I interpreted your question as "how to do code review without too much overhead", which probably has similar solutions for other VCSs like Mercurial and Fossil, but with less support from mainstream sites like GitLab.